Time synchronization operations in vehicle communications

Abstract

A method and system for performing time synchronization for a cellular vehicle-to-everything (C‑V2X) wireless interface of a vehicle is provided. In one example, a method includes: determining, by a vehicle UE, whether a global navigation satellite system (GNSS) receiver of the vehicle receives a GNSS signal including time information for a time synchronization operation of a local clock source of the vehicle; adjusting a local clock time of a local clock source of the vehicle based on the time information included in the GNSS signal or one of one or more wireless signals broadcast from a base station based on whether the GNSS receiver receives the GNSS signal including the time information; and adjusting at least one of a phase or a frequency of a clock signal provided to the C‑V2X wireless interface based on the adjusted local clock time.

Description

Background Art

[0001] Clock synchronization is essential for distributed network systems. It provides a common time frame between network nodes in distributed network systems to support various network functions, such as real-time and correctly ordered message transmission, channel scheduling, and resource sharing. Clock synchronization also enables secure connections, data consistency, and process coordination between network nodes in distributed network systems.

[0002] Accurate time is particularly important in network applications with high mobility, such as in vehicular networks, which may need to support vehicle-to-vehicle and vehicle-to-infrastructure communications. In such vehicular networks, at least some of the network nodes (e.g., vehicles) may move rapidly and communications may be established by forming networks in an ad hoc manner. Such ad hoc networks are typically very ephemeral and may depend on the speed of the vehicles. In such networks, it becomes even more important to provide network nodes with reliable and continuous access to accurate network-wide time.

[0003] Currently, vehicle networks, such as cellular vehicle-to-everything (C-V2X) networks, use global navigation satellite systems (GNSS) to perform time synchronization operations. GNSS satellites typically include atomic clocks that are monitored and controlled to be highly synchronized and traceable to national and international standards, such as Coordinated Universal Time (UTC). GNSS satellites may transmit time information in GNSS signals. Each vehicle in the vehicle network may include a GNSS receiver to receive GNSS signals from one or more GNSS satellites and synchronize its clock based on the time information included in the GNSS signals. As a result of each vehicle synchronizing its own clock with the same clock of the GNSS satellite, time synchronization (to the accuracy of an atomic clock) may be achieved in the vehicle network.

[0004] Although GNSS provides an accessible mechanism to provide time synchronization for vehicle networks, vehicles may be unable to receive time information included in GNSS signals. This may be due to, for example, the vehicle entering a location where there is no GNSS signal coverage or where the GNSS signal coverage is very weak. For example, the vehicle may be moving to a location that completely blocks GNSS signals (e.g., underground), or to a location where GNSS signals may be substantially blocked or attenuated by structures (e.g., mountains, tall buildings, etc.). In these situations, when the vehicle is out of GNSS coverage, the vehicle may be unable to perform time synchronization operations and cannot operate in the vehicle network. Summary of the invention

[0005] The technology described herein solves these and other problems by providing a hybrid mechanism to perform time synchronization operations for a C-V2X wireless interface of a vehicle. A vehicle may include a GNSS receiver and a vehicle user equipment (vehicle UE), the vehicle user equipment including a C-V2X wireless interface that supports C-V2X communications with other devices, such as base stations, infrastructure such as roadside units (RSUs), other vehicles, etc. The vehicle also includes a local clock source for providing timing information for the C-V2X wireless interface. The timing information may include a periodic clock signal provided to the wireless interface, a local clock time maintained at a local clock source, etc. The GNSS receiver and the local clock source may be part of the vehicle UE or external to the vehicle UE.

[0006] The vehicle UE may implement a hybrid mechanism to synchronize the operation of the local clock source and the C-V2X wireless interface with an external clock source in a time synchronization operation. Specifically, the vehicle UE may include a synchronization module. At the start of the time synchronization operation, the synchronization module may determine whether the GNSS receiver receives a GNSS signal including time information for the time synchronization operation. If the synchronization module determines that the GNSS receiver receives a GNSS signal including time information, the synchronization module may provide the time information included in the GNSS signal to the local clock source to perform the time synchronization operation. On the other hand, if the GNSS receiver does not receive a GNSS signal including time information, the synchronization module may determine to perform a time synchronization operation based on a wireless signal from a base station of a cellular network (e.g., LTE, 5G NR, etc.). The time synchronization operation may also include, for example, adjusting the local clock time maintained by the local clock source, adjusting the frequency and / or phase of the periodic clock signal provided to the C-V2X wireless interface, etc. In some examples, the synchronization module may continue to monitor the GNSS signal received by the GNSS receiver, and if a GNSS signal including time information for the time synchronization operation is received, it may switch back to using the GNSS signal for the time synchronization operation.

[0007] The synchronization module can determine in various ways whether the GNSS receives a GNSS signal that includes time information for time synchronization operations. In one example, the synchronization module can determine whether the GNSS signal (if any) received by the GNSS receiver has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal. In another example, the synchronization module can determine whether the GNSS signal includes time information. The GNSS receiver may not receive a GNSS signal that includes time information for time synchronization operations if, for example, the vehicle is in a location where GNSS signal reception is poor (e.g., underground), the GNSS receiver is faulty, the GNSS signal does not include time information, etc.

[0008] If the GNSS receiver does not receive a GNSS signal including time information, the synchronization module may perform a time synchronization operation based on one or more wireless signals broadcast by the base station. The wireless signal may be part of a message broadcast by the base station to help the vehicle UE select and register a cell managed by the base station. The wireless signal may include, for example, a system information block (SIB) message and a master information block (MIB) message. In one example, the vehicle UE may receive a SIB type 21 (SIB 21) message. SIB21 is a message that may be used to transmit configuration information, such as an RRC message, to support C-V2X side link communication. SIB21 is defined in, for example, the Third Generation Partnership Project, Technical Specification Group Radio Access Network, Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) Protocol Specification (3GPP TS 36.331 Version 15.8.0 Version 15). Based on receiving SIB21, the synchronization module may determine that the base station supports C-V2X communication. Based on such a determination, the synchronization module may perform a time synchronization operation with the base station to support C-V2X communication.

[0009] In some examples, the time synchronization operation can be based on information included in a master information block (MIB) message broadcast by the base station. For example, the master information block is defined in the LTE Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) protocol specification (3GPP TS 36.331 Version 10.1.0 Version 10). The base station can use a physical layer channel, such as a physical broadcast channel (PBCH), to periodically broadcast MIB messages, and the MIB messages include information such as system bandwidth, system frame number, etc. SFN can represent the local clock time of the base station. The range of SFN can be between 0 and 1023, and can be generated by a counter that updates the count value representing SFN at intervals of every 10 milliseconds (ms). When the counter reaches 1023, it can be reset back to zero. The synchronization module can also maintain and update the local system frame number based on the local clock. The synchronization module can compare the system frame number in the MIB with its local system frame number, and control the local clock source to adjust the local clock time based on the difference between the two system frame numbers.

[0010] In another example, the UE may receive a SIB type 16 (SIB 16) or SIB type 8 (SIB8) message. Both SIB type 16 and SIB type 8 are defined in the LTE Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) protocol specifications (3GPP TS 36.331 Version 11.5.0 Version 11). The SIB type 16 message contains information related to GPS time and Coordinated Universal Time (UTC). In addition, the SIB type 8 message contains information for inter-RAT cell reselection. The information includes the absolute time in the current cell. The synchronization module may obtain time information (e.g., UTC time, absolute time in the current cell, etc.) and forward the time information to a local clock source to update the local clock time. In some examples, based on determining that a SIB type 21 message is not received from a base station, the UE may use a SIB type 16 or SIB type 8 message to perform a time synchronization operation.

[0011] An example method for performing time synchronization for a wireless communication interface of a vehicle includes: determining, by a UE of the vehicle, whether a GNSS receiver of the vehicle receives a GNSS signal including time information for a time synchronization operation of a local clock source of the vehicle; and performing a time synchronization operation of a local clock source of the vehicle based on whether the GNSS receiver receives the GNSS signal including time information, based on one of the following: time information included in the GNSS signal or a wireless signal from a base station. The wireless signal may include, for example, a SIB type 8 message, a SIB type 16 message, a SIB type 21 message, a MIB message, etc.

[0012] Example devices, apparatuses, and non-transitory computer-readable media storing instructions for performing the above-described methods are also described. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 An exemplary C-V2X network is shown in which the disclosed techniques may be used.

[0014] Figure 2A and Figure 2B An example vehicle communication system is shown.

[0015] Figure 3A , Figure 3B , Figure 3C , Figure 3D , Figure 3E and Figure 3F An example of a hybrid time synchronization operation performed by a vehicle communication system is shown.

[0016] Figure 4 An example method for performing hybrid time synchronization operations for a C-V2X radio interface is shown.

[0017] Figure 5A and Figure 5B Shown is the method for implementing Figure 3A-Figure 4 An example of a system architecture of an example of a hybrid time synchronization mechanism.

[0018] Figure 6 is a block diagram of an embodiment of a mobile computer system.

[0019] According to some example implementations, the same reference symbols in the various drawings represent the same elements. In addition, multiple instances of an element can be indicated by following a letter or hyphen and a second digit after the first digit of the element. For example, multiple instances of element 110 can be indicated as 110-1, 110-2, 110-3, etc., or as 110-A, 110-B, 110-C, etc. When only the first digit is used to refer to such an element, any instance of the element should be understood (for example, the element 110 in the previous example will refer to elements 110-1, 110-2 and 110-3 or elements 110-A, 110-B and 110-C). DETAILED DESCRIPTION

[0020] Several illustrative embodiments will now be described with reference to the accompanying drawings, which form a part of this specification. Although specific embodiments are described below in which one or more aspects of the present disclosure may be implemented, other embodiments may be used and various modifications may be made without departing from the scope of the present disclosure or the spirit of the appended claims.

[0021] Clock synchronization is critical for distributed network systems, especially for network applications with high mobility, such as vehicular networks. An example of a vehicular network is Cellular Vehicle-to-Everything (C-V2X). Figure 1 An example of a vehicle network 100 formed based on wireless communication between vehicles 102 and 104 and infrastructure 105 (e.g., base stations, roadside units, etc.) is shown. In order to achieve wireless communication, the operation of the wireless interfaces of the vehicles 102 and 104 and the infrastructure 105 needs to be synchronized with a common time. For example, Figure 1 As shown, the vehicle 102 or the infrastructure 105 can send a plurality of subframes 106 of wireless data to the vehicle 104 at predetermined clock times. The vehicle 102 can send subframe 0 of wireless data between clock times T0 and T1, followed by subframe 1 between clock times T1 and T2, subframe 2 between clock times T2 and T3, subframe 3 between clock times T3 and T4, etc. Each subframe can include a different set of symbols and / or be modulated using a different set of carrier frequencies.

[0022] In order for the vehicle 104 to correctly process each subframe from the vehicle 102 / infrastructure 105 (e.g., use the correct set of carrier frequencies to demodulate the subframe wireless signal), the vehicle 104 may also need to track the received clock time of each subframe. For example, the vehicle 104 may determine that the wireless signal received between clock times T0 and T1 is subframe 0, the wireless signal received between clock times T1 and T2 is subframe 1, the wireless signal received between clock times T2 and T3 is subframe 2, and the wireless signal received between clock times T3 and T4 is subframe 3.

[0023] Correct processing of subframes by vehicle 104 may require that local clock times at vehicles 102 and 104 and infrastructure 105 are identical. For example, if local clock times T1 and T2 at vehicle 104 are aligned in time with local clock times T0 and T1 at vehicle 102, vehicle 104 may erroneously determine that a wireless signal received between clock times T1 and T2 at vehicle 104 is subframe 1, when in fact subframe 0 is transmitted between clock times T0 and T1 at vehicle 102. In addition, local clock times are typically maintained at a local clock source, from which a clock signal can be derived and provided to different components of the wireless interface. Maintaining the same clock time at the local clock sources of vehicles 102 and 104 and infrastructure 105 can ensure that the clock signals provided to the wireless interfaces of vehicles 102 and 104 and infrastructure 105 are synchronized and have a determined phase relationship. This can improve the consistency and reliability of network connections between vehicles 102 and 104 and infrastructure 105.

[0024] One way to maintain the same clock time at the local clocks of different vehicles is by performing periodic time synchronization operations with an external clock source, such as a Global Navigation Satellite System (GNSS). GNSS satellites typically include atomic clocks that are monitored and controlled to be highly synchronized and traceable to national and international standards, such as Coordinated Universal Time (UTC).

[0025] Figure 2A An example of time synchronization based on GNSS signals is shown. Figure 2AAs shown, the vehicle 200 may include a controller 202, a vehicle network wireless interface 206, a local clock source 208, a clock system 210, and a GNSS receiver 212, all of which may be part of a vehicle communication system 214, which may be a user equipment (UE). The controller 202 may coordinate and manage various operations of the wireless interface 206 and the local clock source 208. For example, the controller 202 may manage the transmission and processing of wireless signals at the wireless interface 206, as well as time synchronization operations of the local clock source 208. The wireless interface 206 may provide C-V2X communications with other vehicles and infrastructure. The local clock source 208 may include an oscillator that may generate a periodic clock signal, and digital logic circuits (e.g., a counter) that may update and store the local clock time based on the clock signal. As described above, the local clock time (in Figure 2A The winning bid is Time A and Time B ) may be sent to the wireless interface 206, for example, to enable the wireless interface 206 to determine the reception time of the subframes and identify each subframe based on the reception time. The local clock time may also be adjusted by the controller 202 in a time synchronization operation. The clock system 210 may derive a clock signal (or a clock signal from an oscillator) from the local clock time and provide the clock signal to the wireless interface 206 and other device modules of the vehicle 200. For example, the clock system 210 may receive a count value representing the local clock time from the local clock source 208, and generate a periodic clock signal of different frequencies based on dividing the count value.

[0026] In addition, GNSS receiver 212 may receive GNSS signal 220 from satellite 222. Satellite 222 may be part of a satellite positioning system (SPS), such as, for example, a global positioning system (GPS) signal, a global navigation satellite system (GLONASS) signal, a Galileo signal, a BeiDou signal, and / or other types of satellite positioning system signals. Satellite 222 may include an atomic clock that may maintain a local clock time Time B , which may be Coordinated Universal Time (UTC). Satellite 222 may transmit a signal including a local clock time Time A The GNSS receiver 212 can receive the GNSS signal 220 and extract the local clock time Time from the GNSS signal 220. A The controller 202 may then change the current local clock time stored in the local clock source 208 from Time A Update to Time B The clock system 210 may also update at least one of the phase or the frequency of the clock signal based on the adjusted local clock time.

[0027] After updating the current local clock time, the local clock source 208 can then continue to update the local clock time based on the periodic clock signal from the oscillator. Since the clock signal generated by the oscillator may drift due to random errors, a mismatch may occur again between the local clock times stored at the local clock source 208 and the satellite 222, and the mismatch may increase over time. In order to reduce the mismatch, a time synchronization operation may be performed periodically to realign the local clock times of the local clock source 208 and the satellite 222.

[0028] Figure 2A The time synchronization operation in the vehicle network can be performed by multiple vehicles and infrastructure of the vehicle network. Each vehicle and infrastructure of the vehicle network can include a GNSS receiver to receive the same GNSS signal including the same local clock time information from the same satellite (or the same satellite group). Each vehicle and infrastructure of the vehicle network can adjust its local clock time based on the local clock time received from the satellite, so that they can all synchronize their local clock time with the satellite. This can reduce the mismatch of the local clock time and the frequency and phase of the clock signal between the vehicle and the infrastructure, which can improve the robustness of the vehicle network.

[0029] Although GNSS provides an accessible mechanism to provide time synchronization, the vehicle 200 may not be able to receive the local clock information included in the GNSS signal 220, such as Figure 2B As shown. This may be caused by a variety of reasons. For example, the vehicle 200 may enter a location where there is no GNSS signal coverage or the GNSS signal coverage is very weak. For example, the vehicle 200 may be moving to a location that completely blocks the GNSS signal (e.g., underground), or to a location where the GNSS signal may be substantially blocked or attenuated by a structure (e.g., a mountain, a tall building, etc.). As another example, the GNSS receiver 212 is faulty and cannot extract local clock time information from the GNSS signal 220. As another example, the GNSS signal 220 transmitted by the satellite 222 does not include local clock time information. In all of these examples, the vehicle 200 cannot perform time synchronization operations and cannot adjust the local clock time of the local clock source 208. Due to the lack of time synchronization, the vehicle 200 may be unable to join the vehicle network and therefore cannot communicate with other vehicles and / or infrastructure in the vehicle network.

[0030] Figure 3A An example of a vehicle communication system that can solve some of the above problems is shown. Figure 3AAs shown, vehicle 300 may include controller 302, vehicle network wireless interface 206, local clock source 208, clock system 210, and GNSS receiver 212, all of which may be part of vehicle communication system 314, which may be a vehicle user equipment (vehicle UE). Figure 2A and Figure 2B As shown, the controller 302 can coordinate and manage various operations of the wireless interface 206 and the local clock source 208. The wireless interface 206 can provide C-V2X communication with other vehicles and base stations / eNodeBs 320 of cellular networks (e.g., LTE, 5GNR, etc.). The local clock source 208 may include an oscillator that can generate a periodic clock signal, and digital logic circuits (e.g., a counter) that can update and store the local clock time based on the clock signal. The clock system 210 can derive a clock signal (or a clock signal from an oscillator) from the local clock time and provide the clock signal to the wireless interface 206 and other components of the vehicle 300, as described above. Figure 2A and Figure 2B Described in .

[0031] In addition, the controller 302 may include a synchronization module 316. The synchronization module 316 may implement a hybrid mechanism to synchronize the local clock source 208 with an external clock source in a time synchronization operation. The external clock source may be one of the satellite 222 or the eNodeB 320. Specifically, at the start of the time synchronization operation, the synchronization module 316 may determine whether the GNSS receiver 212 has received a GNSS signal 220 including time information for the time synchronization operation. If the synchronization module 316 determines that the GNSS receiver 212 has received a GNSS signal including time information (e.g., Figure 2A GNSS signal 220), the synchronization module 316 can provide the time information included in the GNSS signal to the local clock source 208 to perform time synchronization (e.g., the local time Time A Adjust to Time B ),like Figure 2A On the other hand, if the GNSS receiver 212 does not receive a GNSS signal including time information, the synchronization module 316 may determine to perform a time synchronization operation based on the wireless signal 312 received from the base station 320 .

[0032] The synchronization module 316 can determine in various ways whether the GNSS receiver 212 receives a GNSS signal that includes time information for time synchronization operations. In one example, the synchronization module 316 can determine whether the GNSS signal (if any) received by the GNSS receiver 212 has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal. In another example, the synchronization module 316 can determine whether the GNSS signal includes time information. The GNSS receiver 212 may not receive a GNSS signal that includes time information for time synchronization operations if, for example, the vehicle 300 is in a location where GNSS signal reception is poor (e.g., underground), the GNSS receiver 212 is faulty, the GNSS signal does not include time information, etc.

[0033] If the synchronization module 316 determines that the GNSS receiver 212 does not receive a GNSS signal including time information, the synchronization module 316 may perform a time synchronization operation based on the wireless signal 312 broadcast by the base station 320. The wireless signal may be part of a message broadcast by the base station as part of a camping operation to help the vehicle UE select and register a cell managed by the base station. The wireless signal may include, for example, a system information block (SIB) message.

[0034] In one example, the vehicle 300 may receive a system information block type 21 (SIB21) message from the base station 320. SIB21 is a message, such as an RRC message, that may be used to transmit configuration information to support C-V2X sidelink communication. SIB 21 is defined in, for example, the Third Generation Partnership Project, Technical Specification Group Radio Access Network, Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) protocol specification (3GPP TS 36.331 Version 15.8.0 Version 15). Based on receiving SIB 21, the synchronization module 316 may determine that the base station 320 supports C-V2X communication. Based on such a determination, the synchronization module 316 may perform a time synchronization operation with the base station 320 to support C-V2X communication via the wireless interface 206.

[0035] In some examples, the time synchronization operation can be based on information included in a master information block (MIB) message broadcast by the base station 320. For example, the master information block is defined in the LTE Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) protocol specifications (3GPP TS 36.331 Version 10.1.0 Release 10). The base station 320 can use a physical layer channel, such as a physical broadcast channel (PBCH), to periodically broadcast the MIB message. Figure 3B An example of a MIB message is shown. Figure 3BAs shown, the MIB message may include information such as system bandwidth, system frame number (SFN) 330, etc. The SFN may represent the local clock time of the base station. The SFN may range from 0 to 1023 and may be generated by a counter that updates a count value representing the SFN at intervals of every 10 milliseconds (ms). When the counter reaches 1023, it may reset back to zero.

[0036] refer to Figure 3C The synchronization module 316 can also maintain and update the local system frame number (denoted as SFN) based on the local clock time. UE For example, the local system frame number may be based on counting the periodic clock signals generated by the oscillator of the local clock source 208. The synchronization module 316 may store the system frame number (denoted as SFN) in the MIB. BS ) is compared with the local system frame number to determine the SFN difference (labeled as ΔSFN) as follows:

[0037] ΔSFN=SFN BS –SFN UE (Equation 1)

[0038] The SFN difference ΔSFN can be a positive or negative number. In the case where ΔSFN is a positive number, the local clock time at the vehicle 300 is ahead of the local clock time at the base station 320, which will require adding a time offset to the local clock time at the vehicle 300 to make the two local clock times equal. In the case where ΔSFN is a negative number, the local clock time at the vehicle 300 is behind the local clock time at the base station 320, which will require subtracting the time offset from the local clock time at the vehicle 300 to make the two local clock times equal.

[0039] The synchronization module 316 can convert the SFN difference into a time offset (labeled as ΔTime). The time offset can be determined based on the time interval represented between consecutive SFNs. For example, as described above, the SFN is updated every 10 ms, and the time offset can be determined as follows:

[0040] ΔTime = ΔSFN × 10ms (Equation 2)

[0041] The synchronization module 316 can then provide the time offset ΔTime to the local clock source 208, and the local clock source 208 can adjust the local clock time based on adding the time offset to the current local clock time. For example, if the current local clock time is Time A , then the local clock source 208 can update the local clock time to Time as follows B :

[0042] Time B =TimeA +ΔTime (Formula 3)

[0043] In the case where ΔSFN and ΔTime are positive, a positive time offset can be added to the local clock time of the vehicle 300 to equal the local time of the base station 320. In the case where ΔSFN and ΔTime are negative, a time offset can be subtracted from the local clock time of the vehicle 300 to equal the local time of the base station 320. The clock system 210 ( Figure 3C 300 ) may also update at least one of the phase or frequency of a clock signal (provided to wireless interface 206 and other components of vehicle 300 ) based on the adjusted local clock time.

[0044] In the case where the vehicle 300 does not receive the SIB 21 message, the vehicle 300 may perform a time synchronization operation based on other information broadcast by the base station 320. For example, the vehicle 300 may receive a SIB type 16 (SIB 16) or SIB type 8 (SIB 8) message. Both SIB type 16 and SIB type 8 are defined in the LTE Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) protocol specifications (3GPP TS 36.331 Version 11.5.0 Version 11). Figure 3D An example of the content of SIB 16 is shown, and Figure 3E An example of the content of SIB 8 is shown. Figure 3D As shown, the SIB type 16 message includes a timeInfoUTC field 330. The timeInfoUTC field 330 may indicate the coordinated universal time (UTC time) corresponding to the SFN boundary at or immediately following the end boundary of the system information (SI) window of the transmission SystemInformationBlockType16. Figure 3E As shown, the SIB type 8 message contains information for inter-RAT cell reselection. The information includes a systemTimeInfo field 340, which may indicate the absolute time in the current cell.

[0045] refer to Figure 3F The synchronization module 316 may receive a clock time Time B SIB 8 message or SIB 16 message, the clock time Time B It can be UTC time (from SIB 16), absolute time in the cell (from SIB 8), etc. The synchronization module 316 can then provide the received clock time Time to the local clock source 208 B , the local clock source 208 can use the received clock time Time B Update the current local clock time TimeA . Clock system 210 ( Figure 3F 300 ) may also update at least one of the phase or frequency of a clock signal (provided to wireless interface 206 and other components of vehicle 300 ) based on the adjusted local clock time.

[0046] exist Figure 3A-Figure 3F In the example of FIG. 3 , the synchronization module 316 can continue to monitor the GNSS signals received by the GNSS receiver 212. If the GNSS receiver 212 receives a GNSS signal including time information for time synchronization operations due to, for example, the vehicle 300 has moved to a location with improved GNSS signal reception, the GNSS receiver 212 receives GNSS signals from different satellites, etc., the synchronization module 316 can switch back to using the GNSS signal for time synchronization operations.

[0047] Figure 4 A flow chart of an example method 400 for performing time synchronization for a C-V2X radio interface of a vehicle is shown. The C-V2X radio interface (e.g., radio interface 206) may be part of a vehicle UE that also includes a local clock source, such as local clock source 208, that provides timing information for the C-V2X radio interface.

[0048] Method 400 begins at step 410, where the vehicle UE (e.g., synchronization module 316) determines whether the vehicle's GNSS receiver receives a GNSS signal that includes time information for time synchronization operations of the vehicle's local clock source. The synchronization module can determine in various ways whether the GNSS receiver receives a GNSS signal that includes time information for time synchronization operations. In one example, the synchronization module can determine whether the GNSS signal (if any) received by the GNSS receiver has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal. In another example, the synchronization module can determine whether the GNSS signal includes time information. The GNSS receiver may not receive a GNSS signal that includes time information for time synchronization operations if, for example, the vehicle is in a location where GNSS signal reception is poor (e.g., underground), the GNSS receiver is faulty, the GNSS signal does not include time information, etc.

[0049] If the synchronization module 316 determines that the GNSS receiver receives a GNSS signal including time information (step 412), then at step 414, the synchronization module 316 may perform a time synchronization operation of the local clock source of the vehicle based on the time information included in the GNSS signal. The synchronization module may provide the time information included in the GNSS signal to the local clock source 208, and the local clock source 208 may adjust the local clock time based on the time information included in the GNSS signal as part of the time synchronization operation. Then, at step 416, the clock system 210 may update at least one of the phase or frequency of the clock signal provided to the C-V2X wireless interface based on the adjusted local clock time.

[0050] If the GNSS receiver does not receive a GNSS signal including time information (step 412), then in step 418, the synchronization module may perform a time synchronization operation based on one or more wireless signals broadcast by the base station. The one or more wireless signals may be part of a message broadcast by the base station to help the vehicle UE select and register a cell managed by the base station. The wireless signal may include, for example, a system information block (SIB) message and a master information block (MIB) message. In one example, the vehicle UE may receive a SIB type 21 (SIB 21) message indicating that the base station supports C-V2X communication. The vehicle UE may also receive a master information block (MIB) message including a system frame number (SFN) from the base station. Based on receiving the SIB21 message, the vehicle UE may perform a time synchronization operation based on the SFN of the MIB message. The synchronization module may also maintain and update the local system frame number based on the local clock. The synchronization module may compare the system frame number in the MIB with its local system frame number and control the local clock source to adjust the local clock time based on the difference between the two system frame numbers, as described in equations 1-3 above.

[0051] In another example, the UE may receive a SIB type 16 (SIB 16) or SIB type 8 (SIB8) message. The SIB type 16 message contains information related to GPS time and coordinated universal time (UTC). In addition, the SIB type 8 message contains information for inter-RAT cell reselection. The information includes the absolute time in the current cell. The synchronization module may obtain time information (e.g., UTC time, absolute time in the current cell, etc.) and forward the time information to the local clock source 208 to update the local clock time. In some examples, based on the absence of a SIB 21 message received from the base station, the UE may use SIB16 and / or SIB 8 to perform time synchronization operations.

[0052] After step 418, in step 416, the clock system 210 may also update at least one of the phase or frequency of the clock signal provided to the C-V2X wireless interface based on the adjusted local clock time.

[0053] In some examples, the above FIG. 3A to FIG. 4 The hybrid time synchronization mechanism described in can be implemented in the V2X application layer. Figure 5A An example of a V2X application client-server architecture 500 is shown. Figure 5A As shown, the V2X application client-server architecture 500 includes a V2X client 502 and a V2X server 504, which can communicate via a cellular network 506. The V2X client 502 can be a UE and can be part of a vehicle. For example, the synchronization module 316 can be implemented as the V2X client 502. On the other hand, the V2X server 504 can perform various functions to support the operation of the synchronization module 316, such as receiving and transmitting data, service configuration, providing data security, etc.

[0054] In some examples, the hybrid time synchronization mechanism can be implemented by having a functional architecture of VAL (Vertical Application Layer) and SEAL (Service Enabling Application Layer) as defined in the 3rd Generation Partnership Project (3GPP) Working Group SA6 and Technical Specifications (TS) 23.434 and TS 23.286. Figure 5B An example functional architecture diagram 510 of a V2X application layer functional model is shown. Figure 5B As shown, the V2X application layer functional entities for V2X UE and V2X application server are grouped into a V2X application specific layer and a VAE (V2X application enabling) layer. The VAE layer provides VAE functions for the V2X application specific layer. The VAE layer can be regarded as a VAL instance of the V2X service.

[0055] Figure 6 An embodiment of a mobile computer system 600 is shown, which may be used as described above. For example, the mobile computer system 600 may include a vehicle computer system for managing one or more systems related to vehicle navigation and / or autonomous driving and communicating with other vehicle systems and / or other transportation entities. The mobile computer system 600 may be used to perform Figure 4 One or more of the functions of the method 400 and may implement, for example, the functions of the synchronization module 316. It should be noted that Figure 6 It is intended only to provide a generalized description of the various components, any or all of which may be utilized as appropriate. It may be noted that in some cases, Figure 6 The components shown may be located in a single physical device and / or distributed among various networked devices that may be located at different physical locations on the vehicle.

[0056] Mobile computer system 600 is shown as including hardware elements that may be electrically coupled via bus 605 (or may communicate in other ways, as appropriate). The hardware elements may include a processing unit 610, which may include, but is not limited to, one or more general-purpose processors, one or more special-purpose processors (such as digital signal processing (DSP) chips, graphics acceleration processors, application-specific integrated circuits (ASICs), etc.), and / or other processing structures or device modules. Figure 6 As shown, some embodiments may have a separate digital signal processor (DSP) 620, depending on the desired functionality. Position determination and / or other determinations based on wireless communications may be provided in the processing unit 610 and / or the wireless communication interface 830 (discussed below). The mobile computer system 600 may also include one or more input devices 670, which may include devices associated with a user interface (e.g., a touch screen, a touch pad, a microphone, buttons, a dial, a switch, etc.) and / or devices associated with navigation, autonomous driving, etc. Similarly, one or more output devices 615 may be associated with user interaction (e.g., via a display, a light emitting diode (LED), a speaker, etc.), and / or may be devices associated with navigation, autonomous driving, etc.

[0057] The mobile computer system 600 may also include a wireless communication interface 630, which may include but is not limited to a modem, a network card, an infrared communication device, a wireless communication device and / or a chipset (such as a Bluetooth device, an IEEE 802.11 device, an IEEE 802.15.4 device, a WiFi device, a WiMax device, a WAN device and / or various cellular devices, etc.), etc., which may enable the mobile computer system 800 to communicate with other transportation entities (e.g., RSUs, other vehicles, etc.). The communication may be performed via one or more wireless communication antennas 832 that send and / or receive wireless signals 834. The wireless communication interface 830 may be Figure 2A and Figure 3A-Figure 3F Part of the wireless interface 206.

[0058] The mobile computer system 600 may also include a sensor 640. The sensor 840 may include, but is not limited to, one or more inertial sensors and / or other sensors (e.g., accelerometers, gyroscopes, cameras, magnetometers, altimeters, microphones, proximity sensors, light sensors, barometers, etc.). The sensor 840 may be used, for example, to determine certain real-time characteristics of the vehicle, such as position, speed, acceleration, etc.

[0059] Embodiments of the mobile computer system 600 may also include a GNSS receiver 680 capable of receiving signals 684 from one or more GNSS satellites using an antenna 682 (which may be the same as antenna 632). Positioning based on GNSS signal measurements may be used to determine the current location of the vehicle, which, as described above, may be used as a trigger to determine and / or send an ITM, as described herein. The GNSS receiver 680 may extract the location of the mobile computer system 600 from GNSS satellites of a GNSS system, such as a Global Positioning System (GPS) and / or similar systems, using conventional techniques. The GNSS receiver 680 may correspond to, for example, Figure 2A and Figure 3A-Figure 3F A GNSS receiver 212 is provided.

[0060] The mobile computer system 600 may also include and / or be in communication with memory 660. The memory 660 may include, but is not limited to, local and / or network accessible memory, disk drives, drive arrays, optical storage devices, solid-state storage devices such as random access memory (RAM) and / or read-only memory (ROM), which may be programmable, flash-updatable, etc. Such storage devices may be configured to implement any suitable data storage, including, but not limited to, various file systems, database structures, etc.

[0061] The memory 660 of the mobile computer system 600 may also include software components ( Figure 6 ), including an operating system, device drivers, executable libraries, and / or other code, such as one or more application programs, which may include computer programs provided by various embodiments, and / or may be designed to implement methods provided by other embodiments, and / or configure systems, as described herein. By way of example only, one or more processes described with respect to the above methods may be implemented as code and / or instructions in memory 660, which may be executed by mobile computer system 600 (and / or processing unit 610 or DSP 620 within mobile computer system 600). Then, in one aspect, such code and / or instructions may be used to configure and / or adjust a general purpose computer (or other device) to perform one or more operations according to the described methods.

[0062] It will be apparent to those skilled in the art that substantial changes may be made depending on specific requirements. For example, customized hardware may also be used, and / or specific elements may be implemented in hardware, software (including portable software, such as applets, etc.), or both. In addition, connections to other computing devices such as network input / output devices may be used.

[0063] With reference to the accompanying drawings, a component that may include a memory may include a non-transitory machine-readable medium. The terms "machine-readable medium" and "computer-readable medium" used herein refer to any storage medium that participates in providing data that enables a machine to operate in a particular manner. In the embodiments provided above, various machine-readable media may involve providing instructions / codes to a processing unit and / or other devices for execution. Additionally or alternatively, a machine-readable medium may be used to store and / or carry such instructions / codes. In many implementations, a computer-readable medium is a physical and / or tangible storage medium. Such a medium may take a variety of forms, including but not limited to non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example, magnetic and / or optical media, any other physical media with a hole pattern, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or box, a carrier described below, or any other medium from which a computer can read instructions and / or codes.

[0064] The methods, systems and devices discussed here are examples. Various embodiments may appropriately omit, replace or add various processes or components. For example, features described with respect to certain embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. The various components of the accompanying drawings provided here may be implemented with hardware and / or software. In addition, technology is developing, and therefore, many elements are examples, and the scope of this disclosure is not limited to those specific examples.

[0065] It sometimes proves convenient, primarily for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, reference numerals, and the like. It will be understood, however, that all of these or similar terms are associated with the appropriate physical quantities and are merely convenient labels. Unless otherwise stated, it will be apparent from the above discussion that it will be understood that throughout the discussion of this specification, terms such as "processing," "computing," "calculating," "determining," "determining," "identifying," "correlating," "measuring," "performing," and the like are used to refer to the actions or processes of a specific device, such as a special-purpose computer or similar special-purpose electronic computing device. Thus, in the context of this specification, a special-purpose computer or similar special-purpose electronic computing device is capable of manipulating or converting signals, typically represented as physical electronic, electrical, or magnetic quantities within a memory, register, or other information storage device, transmission device, or display device of the special-purpose computer or similar special-purpose electronic computing device.

[0066] The terms "and" and "or" as used herein may include multiple meanings, which are also expected to depend at least in part on the context in which the terms are used. Typically, "or", if used in association with a list, such as A, B, or C, is intended to mean A, B, and C, which are used in an inclusive sense here, and A, B, or C, which are used in an exclusive sense here. In addition, the term "one or more" as used herein may be used to describe any feature, structure, or characteristic in the singular, or may be used to describe a certain combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example, and the subject matter claimed is not limited to this example. In addition, the term "at least one", if used in association with a list, such as A, B, or C, may be interpreted to mean any combination of A, B, and / or C, such as A, AB, AA, AAB, AABBCCC, etc.

[0067] Several embodiments have been described, and various modifications, alternative configurations, and equivalents may be used without departing from the spirit of the present disclosure. For example, the above elements may be merely components of a larger system, where other rules may take precedence over or otherwise modify the application of the various embodiments. Furthermore, many steps may be taken before, during, or after considering the above elements. Therefore, the above description does not limit the scope of the present disclosure.

Claims

1. A method for performing time synchronization for a cellular vehicle-to-everything (C-V2X) wireless interface of a vehicle, the method include: determining, by the vehicle UE, whether a Global Navigation Satellite System (GNSS) receiver of the vehicle receives a GNSS signal including time information for a time synchronization operation of a local clock source of the vehicle; adjusting a local clock time of a local clock source of the vehicle based on whether the GNSS receiver receives a GNSS signal including time information, wherein if the GNSS receiver receives a GNSS signal including time information, the local clock time is adjusted based on the time information included in the GNSS signal, and if the GNSS receiver does not receive a GNSS signal including time information, the local clock time is adjusted based on one or more wireless signals broadcast from a base station, wherein the one or more wireless signals include a system information block (SIB) message; as well as Based on the adjusted local clock time, at least one of a phase or a frequency of a clock signal provided to the C-V2X radio interface is adjusted.

2. The method of claim 1, wherein the SIB message comprises a SIB type 21 message; wherein the one or more wireless signals further include a master information block MIB message including a system frame number SFN; and The local clock time is adjusted based on the SFN of the MIB message.

3. The method according to claim 2, further comprising: include: Based on receiving the SIB 21 message and determining that the GNSS receiver does not receive a GNSS signal including time information, a local clock time is adjusted based on the SFN of the MIB message.

4. The method according to claim 3, wherein the vehicle UE maintains a local SFN ； and The SFN adjustment of the local clock time based on the MIB message includes: Determine the SFN difference between the SFN in the SIB type 21 message and the local SFN; determining a clock offset based on the SFN difference; and The local clock time is adjusted based on adding the clock offset to the local clock time.

5. The method of claim 1 , wherein the SIB message comprises a SIB type 16 message including a Coordinated Universal Time (UTC) time; and Wherein adjusting the local clock time of the local clock source of the vehicle comprises replacing the local clock time with the UTC time included in the SIB Type 16 message.

6. The method according to claim 5, further comprising: include: determining whether a SIB type 21 message is received from a base station; as well as Based on determining that the SIB type 21 message is not received from the base station and the GNSS receiver does not receive the GNSS signal including the time information, the local clock time is adjusted based on the UTC time included in the SIB type 16 message.

7. The method of claim 1, wherein the SIB message comprises a SIB type 8 message including an absolute time of a cell managed by a base station; and Wherein adjusting the local clock time of the local clock source of the vehicle comprises replacing the local clock time with the absolute time included in the SIB Type 8 message.

8. The method according to claim 7, further comprising: include: determining whether a SIB type 21 message is received from a base station; as well as Based on determining that the SIB type 21 message is not received from the base station and the GNSS receiver does not receive the GNSS signal including time information, adjusting the local clock time based on the absolute time included in the SIB type 8 message.

9. The method of claim 1 , wherein determining whether the GNSS receiver receives a GNSS signal including time information for a time synchronization operation is based on at least one of: whether the GNSS receiver receives a GNSS signal, whether the GNSS signal has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal, or whether the GNSS signal includes time information.

10. A device, include: Cellular vehicle-to-everything C-V2X wireless interface; Global Navigation Satellite System GNSS receiver; A local clock source is configured to maintain the local clock time; a clock system configured to generate a clock signal based on a local clock time and provide the clock signal to the C-V2X wireless interface; Memory, storing instruction sets; and one or more processing units communicatively coupled to the memory, the local clock source, and the C-V2X wireless interface, wherein the one or more processing units are configured to execute the set of instructions to: determining whether the GNSS receiver receives a GNSS signal including time information for a time synchronization operation of the local clock source; adjusting a local clock time maintained by a local clock source based on whether the GNSS receiver receives a GNSS signal including time information, wherein if the GNSS receiver receives a GNSS signal including time information, the local clock time is based on the time information included in the GNSS signal, and if the GNSS receiver does not receive a GNSS signal including time information, the local clock time is adjusted based on one or more wireless signals broadcast from a base station, wherein the one or more wireless signals include a system information block (SIB) message; and The clock system is configured to adjust at least one of a phase or a frequency of a clock signal provided to the C-V2X wireless interface based on the adjusted local clock time.

11. The apparatus of claim 10, wherein the SIB message comprises a SIB type 21 message; wherein the one or more wireless signals further include a master information block MIB message including a system frame number SFN; and The local clock time is adjusted based on the SFN of the MIB message.

12. The device according to claim 11, further comprising: include: Based on receiving the SIB 21 message and determining that the GNSS receiver does not receive a GNSS signal including time information, a local clock time is adjusted based on the SFN of the MIB message.

13. The apparatus of claim 12, wherein the C-V2X wireless interface maintains a local SFN; and wherein the one or more processing units are configured to execute the set of instructions to adjust a local clock time based on a SFN of a MIB message based on: Determine the SFN difference between the SFN in the SIB type 21 message and the local SFN; determining a clock offset based on the SFN difference; as well as The local clock time is adjusted based on adding the clock offset to the local clock time.

14. The apparatus of claim 10, wherein the SIB message comprises a SIB type 16 message including a Coordinated Universal Time (UTC) time; and Wherein the one or more processing units are configured to execute the set of instructions to adjust a local clock time of a local clock source of the vehicle based on replacing the local clock time with a UTC time included in a SIB type 16 message.

15. The apparatus of claim 14, wherein the one or more processing units are configured to execute the set of instructions to: determining whether a SIB type 21 message is received from a base station; and Based on determining that the SIB type 21 message is not received from the base station and the GNSS receiver does not receive the GNSS signal including the time information, the local clock time is adjusted based on the UTC time included in the SIB type 16 message.

16. The apparatus of claim 10, wherein the SIB message comprises a SIB type 8 message including an absolute time of a cell managed by a base station; and Wherein the one or more processing units are configured to execute the set of instructions to adjust a local clock time of a local clock source of the vehicle including replacing the local clock time with an absolute time included in a SIB Type 8 message.

17. The apparatus of claim 16, wherein the one or more processing units are configured to execute the set of instructions to: determining whether a SIB type 21 message is received from a base station; and Based on determining that the SIB type 21 message is not received from the base station and the GNSS receiver does not receive the GNSS signal including time information, adjusting the local clock time based on the absolute time included in the SIB type 8 message.

18. The apparatus of claim 10, wherein the one or more processing units are configured to execute the set of instructions to determine whether the vehicle's GNSS receiver receives a GNSS signal that includes time information for a time synchronization operation based on at least one of: whether the GNSS receiver receives the GNSS signal, whether the GNSS signal has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal, or whether the GNSS signal includes time information.

19. A device, include: means for determining whether a Global Navigation Satellite System (GNSS) receiver of the vehicle receives a GNSS signal including time information for time synchronization operation of a local clock source of the vehicle; means for adjusting a local clock time of a local clock source of a vehicle based on whether a GNSS receiver receives a GNSS signal including time information, wherein if the GNSS receiver receives a GNSS signal including time information, the local clock time is based on the time information included in the GNSS signal, and if the GNSS receiver does not receive a GNSS signal including time information, the local clock time is adjusted based on one or more wireless signals broadcast from a base station, wherein the one or more wireless signals include a system information block (SIB) message; as well as Means for adjusting at least one of a phase or a frequency of a clock signal provided to a C-V2X radio interface based on the adjusted local clock time.

20. The apparatus of claim 19, wherein the SIB message comprises a SIB type 21 message; wherein the one or more wireless signals further include a master information block MIB message including a system frame number SFN; and The local clock time is adjusted based on the SFN of the MIB message.

21. The apparatus of claim 20, further comprising means for adjusting a local clock time based on the SFN of the MIB message based on receiving the SIB 21 message and determining that the GNSS receiver does not receive a GNSS signal including time information.

22. The device according to claim 21, further comprising: include: Device module for maintaining local SFN; as well as The device module for adjusting the local clock time based on the SFN of the MIB message includes: Means means for determining a SFN difference between a SFN in a SIB type 21 message and a local SFN; Means for determining a clock offset based on the SFN difference; and Means for adjusting a local clock time based on adding a clock offset to the local clock time.

23. The apparatus of claim 19, wherein the SIB message comprises a SIB type 16 message including a Coordinated Universal Time (UTC) time; and Wherein the means for adjusting the local clock time of the local clock source of the vehicle includes means for replacing the local clock time with the UTC time included in the SIB Type 16 message.

24. The device according to claim 23, further comprising: include: A device module for determining whether a SIB type 21 message is received from a base station; as well as Means for adjusting a local clock time based on a UTC time included in a SIB type 16 message based on determining that a SIB type 21 message was not received from a base station and that a GNSS receiver did not receive a GNSS signal including time information.

25. The apparatus of claim 19, wherein the SIB message comprises a SIB type 8 message including an absolute time of a cell managed by a base station; and Wherein the means for adjusting the local clock time of the local clock source of the vehicle comprises means for replacing the local clock time with an absolute time included in the SIB Type 8 message.

26. The device according to claim 25, further comprising: include: A device module for determining whether a SIB type 21 message is received from a base station; as well as Means for adjusting a local clock time based on an absolute time included in a SIB Type 8 message based on determining that a SIB Type 21 message was not received from a base station and that a GNSS receiver did not receive a GNSS signal including time information.

27. The apparatus of claim 19, further comprising a means for determining whether the GNSS receiver receives a GNSS signal including time information for time synchronization operations based on at least one of: whether the GNSS receiver receives a GNSS signal, whether the GNSS signal has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal, or whether the GNSS signal includes time information.

28. A non-transitory computer readable medium storing instructions which, when executed by a processor, cause the processor to: determining whether a GNSS receiver of the vehicle receives a GNSS signal including time information for a time synchronization operation of a local clock source of the vehicle; and adjusting a local clock time maintained by a local clock source based on whether the GNSS receiver receives a GNSS signal including time information, wherein if the GNSS receiver receives a GNSS signal including time information, the local clock time is based on the time information included in the GNSS signal, and if the GNSS receiver does not receive a GNSS signal including time information, the local clock time is adjusted based on one or more wireless signals broadcast from a base station, wherein the one or more wireless signals include a system information block (SIB) message, Adjusting the local clock time enables the clock system to adjust at least one of the phase or frequency of a clock signal provided to the C-V2X wireless interface based on the adjusted local clock time.

29. The non-transitory computer-readable medium of claim 28, wherein the SIB message comprises a SIB Type 21 message; wherein the one or more wireless signals further include a master information block MIB message including a system frame number SFN; and The local clock time is adjusted based on the SFN of the MIB message.

30. The non-transitory computer-readable medium of claim 29, further comprising instructions that, when executed by a processor, cause the processor to: adjust a local clock time based on a SFN of the MIB message based on receiving the SIB 21 message and determining that the GNSS receiver does not receive a GNSS signal including time information.

31. The non-transitory computer readable medium of claim 30, wherein the C-V2X wireless interface maintains a local SFN; and Wherein the non-transitory computer readable medium further comprises instructions, which when executed by the processor, cause the processor to adjust the local clock time based on the SFN of the MIB message based on: Determine the SFN difference between the SFN in the SIB type 21 message and the local SFN; determining a clock offset based on the SFN difference; as well as The local clock time is adjusted based on adding the clock offset to the local clock time.

32. The non-transitory computer-readable medium of claim 28, wherein the SIB message comprises a SIB Type 16 message including a Coordinated Universal Time (UTC) time; and Wherein the non-transitory computer readable medium further comprises instructions that, when executed by the processor, cause the processor to adjust a local clock time of a local clock source of the vehicle based on replacing the local clock time with a UTC time included in a SIB Type 16 message.

33. The non-transitory computer readable medium of claim 32, further comprising instructions that, when executed by the processor, cause the processor to: determining whether a SIB type 21 message is received from a base station; and Based on determining that the SIB type 21 message is not received from the base station and the GNSS receiver does not receive the GNSS signal including the time information, the local clock time is adjusted based on the UTC time included in the SIB type 16 message.

34. The non-transitory computer-readable medium of claim 28, wherein the SIB message comprises a SIB Type 8 message including an absolute time of a cell managed by a base station; and The non-transitory computer-readable medium further comprises instructions which, when executed by the processor, cause the processor to adjust a local clock time of a local clock source of the vehicle including replacing the local clock time with an absolute time included in a SIB Type 8 message.

35. The non-transitory computer readable medium of claim 34, further comprising instructions that, when executed by the processor, cause the processor to: determining whether a SIB type 21 message is received from a base station; and Based on determining that the SIB type 21 message is not received from the base station and the GNSS receiver does not receive the GNSS signal including time information, adjusting the local clock time based on the absolute time included in the SIB type 8 message.

36. The non-transitory computer-readable medium of claim 28, further comprising instructions that, when executed by the processor, cause the processor to determine whether the vehicle's GNSS receiver receives a GNSS signal that includes time information for time synchronization operations based on at least one of: whether the GNSS receiver receives the GNSS signal, whether the GNSS signal has sufficient signal strength or a sufficiently low noise level to allow time information to be extracted from the GNSS signal, or whether the GNSS signal contains time information.

37. A computer program product storing instructions which, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 9.

Images