Time-synchronized operation in vehicle communications

Abstract

In one example, the method includes determining, by a vehicle UE, whether a global navigation system (GNSS) receiver of the vehicle receives a GNSS signal including time information for time synchronization operation for a local clock source of the vehicle, adjusting a local clock time of the 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 technology]

[0001] Clock synchronization is essential for distributed network systems. It provides a common time frame among the network nodes of a distributed network system to support various network functions such as message transmission, channel scheduling, and resource sharing in real time and in the correct order. Clock synchronization also enables secure connectivity, data consistency, and process coordination among the network nodes of a distributed network system.

[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 quickly and establish communications by forming networks in an ad-hoc manner. Such ad-hoc networks are typically very short-lived and may depend on the speed of the vehicles. In such networks, providing reliable and constant access to accurate network-wide time to network nodes becomes even more important.

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

[0004] Although GNSS provides an accessible mechanism for providing time synchronization to vehicular networks, vehicles may not be able to receive the time information contained in GNSS signals. This may be due, for example, to the vehicle entering a location where GNSS signal coverage is absent or very weak. For example, the vehicle may be moving to a location that completely blocks GNSS signals (e.g., underground) or where GNSS signals may be substantially blocked or attenuated by structures (e.g., mountains, tall buildings, etc.). In these scenarios, the vehicle may not be able to perform time synchronization operations when the vehicle is out of GNSS coverage and cannot operate within the vehicular network. [Prior art documents] [Non-patent literature]

[0005] [Non-Patent Document 1] 3rd 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 Release 15) [Non-Patent Document 2] LTE Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) Protocol specification (3GPP TS 36.331 version 10.1.0 Release 10) [Non-Patent Document 3] LTE Evolved Universal Terrestrial Radio Access (E-UTRA) and Radio Resource Control (RRC) Protocol specification (3GPP TS 36.331 version 11.5.0 Release 11) [Non-Patent Document 4] 3rd Generation Partnership Project (3GPP) Working Group SA6, and in Technical Specification (TS) 23.434 and TS 23.286 Summary of the Invention [Problem to be solved by the invention]

[0006] The techniques described herein address these and other issues by providing a hybrid mechanism for performing time synchronization operations for a vehicle's C-V2X wireless interface. The vehicle may include a GNSS receiver and a vehicle user equipment (vehicle UE) including a C-V2X wireless interface to support C-V2X communications with other devices, such as base stations, infrastructure such as roadside units (RSUs), other vehicles, etc. The vehicle further includes a local clock source to provide 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 the local clock source, etc. The GNSS receiver and the local clock source may be part of the vehicle UE or may be external to the vehicle UE. [Means for solving the problem]

[0007] The vehicle UE may implement a hybrid mechanism for synchronizing the local clock source as well as the operation of 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 that the time synchronization operation should be performed based on a wireless signal from a base station of a cellular network (e.g., LTE, 5G NR, etc.). The time synchronization operation may further include, for example, adjusting a local clock time maintained by the local clock source, adjusting a frequency and / or a phase of a periodic clock signal provided to the C-V2X wireless interface, etc. In some examples, the synchronization module can continue to monitor the GNSS signals received by the GNSS receiver, and if a GNSS signal is received that includes time information for time synchronization operations, it can switch to using the GNSS signal for time synchronization operations.

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

[0009] If the GNSS receiver does not receive a GNSS signal including time information, the synchronization module can perform a time synchronization operation based on one or more wireless signals broadcast by the base station. The wireless signals may be part of messages broadcast by the base station to assist the vehicular UE in selecting and registering with a cell managed by the base station. The wireless signals may include, for example, System Information Block (SIB) messages and Master Information Block (MIB) messages. In one example, the vehicular UE may receive a SIB type 21 (SIB21) message. SIB21 is a message that may be used to convey configuration information, such as an RRC message, to support C-V2X sidelink communication. SIB21 may be, for example, a 3 rdThe synchronization module may be configured to receive the SIB21 from the base station and to synchronize the base station to the C-V2X communication. Based on receiving the 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.

[0010] In some examples, the time synchronization operation may be based on information included in a Master Information Block (MIB) message broadcast by the base station. The Master Information Block is defined, for example, 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 Release 10). The MIB message may be periodically broadcast by the base station using a physical layer channel, such as a physical broadcast channel (PBCH), and may include information, for example, a system bandwidth, a system frame number, and the like. The SFN may represent a local clock time at 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 every 10 millisecond (ms) interval. When the counter reaches 1023, it may be reset to zero. The synchronization module may also maintain and update a local system frame number based on the local clock. The synchronization module may compare the system frame number in the MIB to its local system frame number and control a local clock source to adjust the local clock time based on the difference between the two system frame numbers.

[0011] In another example, the UE may receive a SIB type 16 (SIB16) 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 specification (3GPP TS 36.331 version 11.5.0 Release 11). The SIB type 16 message includes information related to GPS time and Coordinated Universal Time (UTC). Additionally, the SIB type 8 message includes information for inter-RAT cell reselection. The information includes the absolute time in the current cell. The synchronization module may obtain the time information (e.g., UTC time, absolute time in the current cell, etc.) from the SIB and forward the time information to a local clock source to update the local clock time. In some examples, the UE may use the SIB type 16 or SIB type 8 message to perform a time synchronization operation based on determining that a SIB type 21 message is not received from the base station.

[0012] An exemplary method for performing time synchronization of 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 the local clock source of the vehicle based on one of the time information included in the GNSS signal or a wireless signal from a base station based on whether the GNSS receiver receives the GNSS signal including the time information. 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.

[0013] Exemplary devices, means, and non-transitory computer-readable media for storing instructions for performing the aforementioned methods are also described. [Brief description of the drawings]

[0014] [Figure 1] FIG. 1 illustrates an example C-V2X network in which the disclosed techniques may be used. [Figure 2A] FIG. 1 illustrates an exemplary vehicle communication system. [Figure 2B] FIG. 1 illustrates an exemplary vehicle communication system. [Figure 3A] FIG. 2 illustrates an example of a hybrid time synchronization operation performed by a vehicle communication system. [Figure 3B] FIG. 2 illustrates an example of a hybrid time synchronization operation performed by a vehicle communication system. [Figure 3C] FIG. 2 illustrates an example of a hybrid time synchronization operation performed by a vehicle communication system. [Figure 3D] FIG. 2 illustrates an example of a hybrid time synchronization operation performed by a vehicle communication system. [Figure 3E] FIG. 2 illustrates an example of a hybrid time synchronization operation performed by a vehicle communication system. [Figure 3F] FIG. 2 illustrates an example of a hybrid time synchronization operation performed by a vehicle communication system. [Figure 4] FIG. 1 illustrates an example method for performing hybrid time synchronization operations for a C-V2X wireless interface. [Figure 5A] FIG. 5 illustrates an example system architecture for implementing the example hybrid time synchronization mechanism of FIGS. 3A-4. [Figure 5B] FIG. 5 illustrates an example system architecture for implementing the example hybrid time synchronization mechanism of FIGS. 3A-4. [Figure 6] FIG. 1 is a block diagram of one embodiment of a mobile computer system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] According to some exemplary implementations, similar reference symbols in various drawings indicate similar elements. In addition, multiple instances of an element may be indicated by the first number of the element followed by a letter or a hyphen and a second number. For example, multiple instances of element 110 may be indicated as 110-1, 110-2, 110-3, etc., or as 110-A, 110-B, 110-C, etc. When referring to such an element using only the first number, any instance of the element should be understood (e.g., element 110 in the previous example would refer to elements 110-1, 110-2, and 110-3, or elements 110-A, 110-B, and 110-C).

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

[0017] Clock synchronization is essential 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). FIG. 1 shows an example of a vehicular network 100 formed based on wireless communication between vehicles 102 and 104 and an infrastructure 105 (e.g., base stations, roadside units, etc.). To enable wireless communication, the operation of the wireless interfaces of the vehicles 102 and 104 and the infrastructure 105 needs to be synchronized to a common time. For example, as shown in FIG. 1, the vehicle 102 or the infrastructure 105 may transmit multiple subframes 106 of wireless data to the vehicle 104 at predetermined clock times. The vehicle 102 may transmit subframe 0 of wireless data between clock times T0 and T1, then transmit 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 may include a different set of symbols and / or be modulated using a different set of carrier frequencies.

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

[0019] Proper 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 it is subframe 0 transmitted between clock times T0 and T1 at vehicle 102. In addition, typically, the local clock time is maintained at a local clock source, which may derive clock signals from the local clock time and provide clock signals 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 may ensure that the clock signals provided to the wireless interfaces of vehicles 102 and 104 and infrastructure 105 are synchronized and have a deterministic phase relationship. This can improve the consistency and reliability of the network connections between the vehicles 102 and 104 and the infrastructure 105.

[0020] One way to maintain the same clock time on 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 contain atomic clocks that are monitored and controlled so that they are highly synchronized and traceable to national and international standards, such as Coordinated Universal Time (UTC).

[0021] FIG. 2A illustrates an example of time synchronization based on GNSS signals. As shown in FIG. 2A, a vehicle 200 may include a controller 202, a vehicle network wireless interface 206, a local clock source 208, a clocking 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 in the wireless interface 206 and the time synchronization operation 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, as well as a digital logic circuit (e.g., a counter) that may update and store a local clock time based on the clock signal. The local clock time (referred to as Time in FIG. 2A ) may be a part of a vehicle communication system 214, which may be a user equipment (UE). A and Time B A local clock time (labeled as ) may be transmitted to the wireless interface 206, for example, to enable the wireless interface 206 to determine a receive time of the subframe and identify each subframe based on the receive time as described above. The local clock time may also be adjusted by the controller 202 in a time synchronization operation. The clocking system 210 may derive a clock signal from the local clock time (or a clock signal from an oscillator) and provide the clock signal to the wireless interface 206 as well as other components of the vehicle 200. For example, the clocking system 210 may receive a count value from the local clock source 208 that represents the local clock time and generate periodic clock signals of different frequencies based on division of the count value.

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

[0023] After updating the current local clock time, the local clock source 208 may then continue to update the local clock time based on the periodic clock signal from the oscillator. Because the clock signal generated by the oscillator may drift due to random errors, misalignment between the local clock times stored in the local clock source 208 and the satellites 222 may reappear and increase over time. To reduce the misalignment, a time synchronization operation may be performed periodically to realign the local clock times of the local clock source 208 and the satellites 222.

[0024] The time synchronization operation of FIG. 2A can be performed by multiple vehicles and infrastructure of a vehicular network. Each vehicle and infrastructure of the vehicular network can include a GNSS receiver that receives the same GNSS signal containing the same local clock time information from the same satellite (or the same set of satellites). Each vehicle and infrastructure of the vehicular 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 times with the satellite. This can reduce mismatches in the local clock times between the vehicles and the infrastructure, as well as the frequency and phase of the clock signals, and can improve the robustness of the vehicular network.

[0025] Although GNSS provides an accessible mechanism for providing time synchronization, the vehicle 200 may not be able to receive the local clock information contained in the GNSS signal 220, as shown in FIG. 2B. This may be due to a variety of reasons. For example, the vehicle 200 may enter a location where there is no or very weak GNSS signal coverage. For example, the vehicle 200 may move into a location that completely blocks the GNSS signal (e.g., underground) or into a location where the GNSS signal may be substantially blocked or attenuated by structures (e.g., mountains, tall buildings, etc.). As another example, the GNSS receiver 212 is faulty and is unable to extract the local clock time information from the GNSS signal 220. As yet another example, the GNSS signal 220 transmitted by the satellite 222 does not contain the local clock time information. In all these examples, the vehicle 200 is unable to perform a time synchronization operation and is unable to adjust the local clock time of the local clock source 208. Due to the lack of time synchronization, the vehicle 200 may not be able to join the vehicular network and, as a result, be unable to communicate with other vehicles and / or infrastructure in the vehicular network.

[0026] FIG. 3A illustrates an example of a vehicle communication system that can address some of the above problems. As shown in FIG. 3A, a vehicle 300 can include a controller 302, a vehicle network wireless interface 206, a local clock source 208, a clocking system 210, and a GNSS receiver 212, all of which can be part of a vehicle communication system 314, which can be a vehicle user equipment (vehicle UE). Similar to FIG. 2A and FIG. 2B, 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 communications with other vehicles and base stations / eNodeBs 320 of a cellular network (e.g., LTE, 5G NR, etc.). The local clock source 208 can include an oscillator that can generate a periodic clock signal, as well as digital logic circuitry (e.g., a counter) that can update and store a local clock time based on the clock signal. The clocking system 210 can derive a clock signal from a local clock time (or a clock signal from an oscillator) and provide the clock signal to the wireless interface 206 as well as other components of the vehicle 300, as described above in Figures 2A and 2B.

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

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

[0029] If the synchronization module 316 determines that the GNSS receiver 212 does not receive a GNSS signal that includes time information, the synchronization module 316 can perform a time synchronization operation based on a wireless signal 312 broadcast by a base station 320. The wireless signal can be part of a message broadcast by the base station to assist the vehicle UE in selecting and registering with a cell managed by the base station as part of a camp-on operation. The wireless signal can include, for example, a System Information Block (SIB) message.

[0030] In one example, the vehicle 300 can receive a System Information Block type 21 (SIB 21) message from the base station 320. SIB 21 is a message that can be used to convey configuration information, such as an RRC message, to support C-V2X sidelink communications. SIB 21 can be, for example, rd The SIB21 is defined in the 3GPP 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 Release 15). Based on receiving the SIB21, the synchronization module 316 may determine that the base station 320 supports C-V2X communications. Based on such a determination, the synchronization module 316 may perform a time synchronization operation with the base station 320 to support C-V2X communications over the wireless interface 206.

[0031] In some examples, the time synchronization operation may be based on information included in a Master Information Block (MIB) message broadcast by the base station 320. The Master Information Block may be defined, for example, 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 Release 10). The MIB message may be periodically broadcast by the base station 320 using a physical layer channel, such as a physical broadcast channel (PBCH). FIG. 3B illustrates an example of a MIB message. As shown in FIG. 3B, the MIB message may include information, such as, for example, a system bandwidth, a system frame number (SFN) 330, and the like. The SFN may represent a local clock time at 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 every 10 millisecond (ms) interval. The counter may be reset to zero when it reaches 1023.

[0032] Referring to FIG. 3C, the synchronization module 316 derives a local system frame number (SFN) based on the local clock time. UE For example, the local system frame number may be based on counting periodic clock signals generated by an oscillator of the local clock source 208. The synchronization module 316 may also maintain and update the MIB(SFN) as follows: BS The system frame number at the local system frame number (labeled SFN) can be compared to the local system frame number to determine the SFN difference (labeled ΔSFN). ΔSFN = SFN BS - SFN UE (Formula 1)

[0033] The SFN difference ΔSFN can be either a positive or negative number. If ΔSFN is a positive number, the local clock time at the vehicle 300 leads the local clock time at the base station 320, which requires adding a time offset to the local clock time at the vehicle 300 to make the two local clock times equal. If ΔSFN is a negative number, the local clock time at the vehicle 300 lags the local clock time at the base station 320, which requires subtracting a time offset from the local clock time at the vehicle 300 to make the two local clock times equal.

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

[0035] The synchronization module 316 can then provide the time offset ΔTime to the local clock source 208, which 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 If so, then the local clock source 208 sets the local clock time to Time B can be updated to. Time B =Time A +ΔTime (Equation 3)

[0036] If ΔSFN and ΔTime are positive, then a positive time offset may be added to the local clock time at the vehicle 300 to equal the local time at the base station 320. If ΔSFN and ΔTime are negative, then a time offset may be subtracted from the local clock time at the vehicle 300 to equal the local time at the base station 320. The clocking system 210 (not shown in FIG. 3C ) may also update at least one of the phase or frequency of a clock signal (supplied to the wireless interface 206 and other components of the vehicle 300) based on the adjusted local clock time.

[0037] If the vehicle 300 does not receive the SIB21 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 (SIB16) 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 specification (3GPP TS 36.331 version 11.5.0 Release 11). FIG. 3D illustrates an example of the content of SIB16, and FIG. 3E illustrates an example of the content of SIB8. As shown in FIG. 3D, the SIB type 16 message includes a timeInfoUTC field 330. The timeInfoUTC field 330 may indicate a Coordinated Universal Time (UTC time) that corresponds to the ending boundary of the system information (SI) window in which the SystemInformationBlockType16 is transmitted or the SFN boundary immediately following it. 3E, the SIB type 8 message includes information for inter-RAT cell reselection, including a systemTimeInfo field 340 that can indicate the absolute time in the current cell.

[0038] Referring to FIG. 3F, the synchronization module 316 receives a clock time Time , which may be UTC time (from SIB16), absolute time in the cell (from SIB8), etc. B The synchronization module 316 may then receive an SIB8 or SIB16 message that includes the received clock time, Time B may be provided to the local clock source 208, which may provide the current local clock time, Time A The clock time when the message was received. B The clocking system 210 (not shown in FIG. 3F) may also update at least one of the phase or frequency of a clock signal (provided to the wireless interface 206 and other components of the vehicle 300) based on the adjusted local clock time.

[0039] 3A-3F, the synchronization module 316 may continue to monitor the GNSS signals received by the GNSS receiver 212. The synchronization module 316 may switch to using the GNSS signals for time synchronization operations if the GNSS receiver 212 receives a GNSS signal that includes time information for the time synchronization operations, for example, because the vehicle 300 has moved to a location with improved GNSS signal reception, the GNSS receiver 212 has received a GNSS signal from a different satellite, etc.

[0040] 4 shows a flowchart of an example method 400 of performing time synchronization for a vehicle's C-V2X wireless interface. The C-V2X wireless interface (e.g., wireless 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 wireless interface.

[0041] The 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 for the vehicle's local clock source. The synchronization module can determine whether the GNSS receiver receives a GNSS signal that includes time information for time synchronization operations in various ways. In one example, the synchronization module can determine whether the GNSS signal received by the GNSS receiver has sufficient signal strength or a sufficiently low level of noise to enable extraction of time information, if any, from the GNSS signal. In another example, the synchronization module can determine whether the GNSS signal includes time information at all. The GNSS receiver may not receive a GNSS signal that includes time information for time synchronization operations, for example, if the vehicle is in a location with poor GNSS signal reception (e.g., underground), if the GNSS receiver is faulty, if the GNSS signal does not include time information, etc.

[0042] If the synchronization module 316 determines (at step 412) that the GNSS receiver has received a GNSS signal including time information, the synchronization module 316 may perform a time synchronization operation of a local clock source of the vehicle based on the time information included in the GNSS signal at step 414. The synchronization module may provide the time information included in the GNSS signal to the local clock source 208 and 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 clocking 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.

[0043] If the GNSS receiver does not receive a GNSS signal including time information (step 412), the synchronization module may perform a time synchronization operation based on one or more wireless signals broadcast by the base station in step 418. The one or more wireless signals may be part of a message broadcast by the base station to assist the vehicle UE in selecting and registering with a cell managed by the base station. The wireless signals 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 (SIB21) message indicating that the base station supports C-V2X communication. The vehicle UE may also receive a master information block (MIB) message from the base station including a system frame number (SFN). 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 a local system frame number based on a 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, as described above in Equations 1-3.

[0044] In another example, the UE may receive a SIB type 16 (SIB16) or SIB type 8 (SIB8) message. The SIB type 16 message includes information related to GPS time and Coordinated Universal Time (UTC). Additionally, the SIB type 8 message includes information for inter-RAT cell reselection. The information includes the absolute time in the current cell. The synchronization module may obtain the time information (e.g., UTC time, absolute time in the current cell, etc.) from the SIB and forward the time information to the local clock source 208 to update the local clock time. In some examples, the UE may use SIB16 and / or SIB8 to perform a time synchronization operation based on not receiving a SIB21 message from the base station.

[0045] Following step 418, the clocking 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, in step 416.

[0046] In some examples, the hybrid time synchronization mechanism described above in FIGS. 3A-4 may be implemented at the V2X application layer. FIG. 5A illustrates an example of a V2X application client-server architecture 500. As shown in FIG. 5A, the V2X application client-server architecture 500 includes a V2X client 502 and a V2X server 504 that can communicate over a cellular network 506. The V2X client 502 may be a UE or may be part of a vehicle. For example, the synchronization module 316 may be implemented as the V2X client 502. Meanwhile, the V2X server 504 may perform various functions to support the operation of the synchronization module 316, such as receiving and distributing data, service configuration, providing data security, etc.

[0047] In some examples, the hybrid time synchronization mechanism may be implemented via a functional architecture with VAL (Vertical Application Layer) and SEAL (Service Enablement Application Layer) as defined in 3rd Generation Partnership Project (3GPP) Working Group SA6, and in Technical Specification (TS) 23.434 and TS 23.286. FIG. 5B shows an example functional architecture diagram 510 of a V2X application layer functional model. As shown in FIG. 5B, 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 enable) layer. The VAE layer provides VAE functionality to the V2X application specific layer. The VAE layer can be considered as an instance of VAL for V2X services.

[0048] FIG. 6 illustrates one embodiment of a mobile computer system 600 that may be utilized as described herein above. For example, the mobile computer system 600 may comprise a vehicle computer system that is used to manage one or more systems related to navigation and / or automated driving of the vehicle and also to communicate with other on-board systems and / or other traffic entities. The mobile computer system 600 may be used to perform one or more of the functions of the method 400 of FIG. 4, for example, to implement the functions of the synchronization module 316. It should be noted that FIG. 6 is intended to provide only a generalized illustration of various components, any or all of which may be utilized as appropriate. It may be noted that in some instances, the components illustrated by FIG. 6 may be localized in a single physical device and / or distributed among various networked devices that may be disposed at different physical locations on the vehicle.

[0049] A mobile computer system 600 is shown comprising hardware elements that may be electrically coupled (or otherwise in communication as appropriate) via a bus 605. 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 processing means. As shown in FIG. 6, some embodiments may have a separate digital signal processor (DSP) 620 depending on the desired functionality. Location determination and / or other determinations based on wireless communication may be performed in the processing unit 610 and / or in the wireless communication interface 830 (described below). The mobile computer system 600 may also include one or more input devices 670 (e.g., touch screens, touch pads, microphones, buttons, dials, switches, etc.), which may include devices related to a user interface, and / or devices related to navigation, autonomous driving, etc. Similarly, one or more output devices 615 may relate to interacting with a user (e.g., via a display, light emitting diodes (LEDs), speakers, etc.) and / or devices related to navigation, autonomous driving, etc.

[0050] The mobile computer system 600 may also include a wireless communication interface 630, which may comprise, 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 Wi-Fi device, a WiMAX device, a WAN device, and / or various cellular devices), which may enable the mobile computer system 800 to communicate with other traffic entities (e.g., RSUs, other vehicles, etc.). Communications may be performed via one or more wireless communication antennas 832 that transmit and / or receive wireless signals 834. The wireless communication interface 830 may be part of the wireless interface 206 of FIGS. 2A and 3A-3F.

[0051] The mobile computer system 600 may further include sensors 640. The sensors 840 may include, but are 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 sensors 840 may be used to determine several real-time characteristics of the vehicle, such as, for example, location, speed, acceleration, etc.

[0052] An embodiment 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 utilized to determine the vehicle's current location, which may be used as a trigger to determine and / or transmit an ITM as described herein, as described above. The GNSS receiver 680 may extract the location of the mobile computer system 600 using conventional techniques from GNSS satellites of a GNSS system, such as the Global Positioning System (GPS) and / or similar systems. The GNSS receiver 680 may correspond, for example, to the GNSS receiver 212 of Figures 2A and 3A-3F.

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

[0054] The memory 660 of the mobile computer system 600 may also comprise software elements (not shown in FIG. 6 ), including an operating system, device drivers, executable libraries, and / or other code, such as one or more application programs, which may comprise computer programs provided by various embodiments and / or may be designed to perform methods and / or configure systems provided by other embodiments, as described herein. By way of example only, one or more procedures described with respect to the methods described above may be implemented as code and / or instructions in the memory 660 executable by the mobile computer system 600 (and / or the processing unit 610 or DSP 620 within the mobile computer system 600). In one aspect, such code and / or instructions can then be used to configure and / or adapt a general-purpose computer (or other device) to perform one or more operations in accordance with the methods described.

[0055] It will be apparent to those skilled in the art that substantial variations may be made according to particular requirements. For example, customized hardware may also be used and / or particular elements may be implemented in hardware, software (including portable software such as applets, etc.), or both. Furthermore, connection to other computing devices, such as network input / output devices, may be employed.

[0056] With reference to the accompanying drawings, components that may include memory may include non-transitory machine-readable media. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to any storage medium that participates in providing data to cause a machine to operate in a specific manner. In the embodiments provided above, various machine-readable media may participate in providing instructions / code to a processing unit and / or other devices for execution. Additionally or alternatively, machine-readable media may be used to store and / or transport such instructions / code. In many implementations, the computer-readable medium is a physical and / or tangible storage medium. Such media may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Common forms of computer-readable media include, for example, magnetic media and / or optical media, any other physical media with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described below, or any other medium from which a computer can read instructions and / or code.

[0057] The methods, systems, and devices described herein are examples. Various embodiments may omit, substitute, or add various procedures or components, as appropriate. For example, features described with respect to some embodiments may be combined in various other embodiments. Different aspects and elements of the embodiments may be combined in a similar manner. Various components of the drawings provided herein may be embodied in hardware and / or software. Also, technology evolves, and thus many of the elements are examples that do not limit the scope of the disclosure to those specific examples.

[0058] It has proven convenient at times, primarily for reasons of common usage, to refer to such signals as bits, information, values, elements, symbols, characters, variables, terms, numbers, numeric values, or the like. It should be understood, however, that all of these or similar terms are to be associated with the appropriate physical quantities and are merely convenient labels. Unless otherwise indicated, and as is apparent from the above description, it will be appreciated that throughout this specification descriptions utilizing terms such as "processing," "computing," "calculating," "determining," "determining," "identifying," "associating," "measuring," "performing," and the like refer to actions or processes of a particular apparatus, 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 transforming signals that are commonly represented as physical electronic, electrical, or magnetic quantities in the memory, registers, or other information storage, transmission, or display devices of the special purpose computer or similar special purpose electronic computing device.

[0059] The terms "and" and "or" as used herein may include various meanings that are also expected to depend at least in part on the context in which such terms are used. Typically, "or," when used to link an enumeration such as A, B, or C, is intended to mean A, B, and C, which are used herein in an inclusive sense, and A, B, or C, which are used herein in an exclusive sense. In addition, the term "one or more" as used herein may be used to represent any feature, structure, or characteristic in the singular, or may be used to represent any combination of features, structures, or characteristics. However, it should be noted that this is merely an illustrative example, and claimed subject matter is not limited to this example. Furthermore, the term "at least one of," when used to link an enumeration 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.

[0060] Although several embodiments have been described, various modifications, alternative configurations, and equivalents may be used without departing from the spirit of the present disclosure. For example, the above elements may simply be components of a larger system, and other rules may take precedence over or otherwise modify the application of the various embodiments. Also, some steps may be undertaken before, during, or after the above elements are considered. Thus, the above description does not limit the scope of the present disclosure. [Explanation of symbols]

[0061] 100 Vehicle Network 102 vehicles 104 vehicles 105 Infrastructure 106 Subframe 200 vehicles 202 Controller 206 Vehicle Network Wireless Interface 208 Local Clock Source 210 Clocking System 212 GNSS receiver 214 Vehicle Communication System 220 GNSS signals 222 Satellite 300 vehicles 302 Controller 312 Wireless Signal 314 Vehicle Communication System 316 Synchronization Module 320 Base Station / eNodeB 330 System Frame Number (SFN) 330 timeInfoUTC field 340 systemTimeInfo Field 400 ways 500 V2X Application Client-Server Architecture 502 V2X Client 504 V2X Server 506 Cellular Network 600 Mobile Computer System 605 Bus 610 Processing Unit 615 Output Device 620 Digital Signal Processor (DSP) 630 Wireless Communication Interface 632 Antenna 640 Sensor 660 Memory 670 Input Devices 680 GNSS Receiver 682 Antenna 684 signal 800 Mobile Computer System 830 Wireless Communication Interface 832 Wireless Communication Antenna 834 Wireless Signal 840 Sensor

Claims

1. 1. A method for performing time synchronization for a cellular vehicle-to-everything (C-V2X) wireless interface of a vehicle, comprising: determining, by a vehicle UE, whether a Global Navigation System (GNSS) receiver of the vehicle receives a GNSS signal including time information for time synchronization operation for 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 the time information, when the GNSS receiver receives a GNSS signal including the time information, the local clock time is adjusted based on the time information included in the GNSS signal; if the GNSS receiver does not receive a GNSS signal containing the time information, the local clock time is adjusted based on one or more wireless signals broadcast from a base station; the one or more wireless signals include a system information block (SIB) message including at least one of a SIB type 8 message, a SIB type 16 message, and a SIB type 21 message; determining whether the SIB type 21 message is received from the base station; adjusting the local clock time based on the SIB type 8 message or the SIB type 16 message based on determining that the SIB type 21 message has not been received from the base station and that the GNSS receiver has not received 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; The method includes:

2. the SIB message comprises the SIB type 21 message, the one or more wireless signals further comprising a Master Information Block (MIB) message including a System Frame Number (SFN); the local clock time is adjusted based on the SFN of the MIB message; The method of claim 1.

3. 3. The method of claim 2, wherein adjusting the local clock time of the vehicle's local clock source comprises adjusting the local clock time based on the SFN of the MIB message based on receiving the SIB type 21 message and determining that the GNSS receiver does not receive the GNSS signal including the time information.

4. the vehicular UE maintains a local SFN; adjusting the local clock time based on the SFN of the MIB message, determining an SFN difference between the SFN in the SIB type 21 message and the local SFN; determining a clock offset based on the SFN difference; adjusting the local clock time based on adding the clock offset to the local clock time; Including, The method of claim 3.

5. The method of claim 1, wherein the SIB type 16 message includes Coordinated Universal Time (UTC).

6. The method described in claim 5, wherein the step of adjusting the local clock time based on the SIB type 8 message or the SIB type 16 message includes a step of adjusting the local clock time based on the UTC time included in the SIB type 16 message.

7. The method described in claim 1, wherein the SIB type 8 message includes the absolute time of a cell managed by the base station.

8. The method described in claim 7, wherein the step of adjusting the local clock time based on the SIB type 8 message or the SIB type 16 message includes a step of adjusting the local clock time based on the absolute time contained in the SIB type 8 message.

9. 2. The method of claim 1, wherein the determination of whether the GNSS receiver receives the GNSS signal including time information for the time synchronization operation is 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 level of noise to enable extraction of the time information from the GNSS signal, or whether the GNSS signal includes the time information.

10. Cellular V2X (C-V2X) wireless interface; A Global Navigation Satellite System (GNSS) receiver; a local clock source configured to maintain a local clock time; a clocking system configured to generate a clock signal based on the local clock time and provide the clock signal to the C-V2X wireless interface; A memory for storing a set of instructions; 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 perform the method according to any one of claims 1 to 9. Device.

11. A non-transitory computer readable storage medium storing instructions that, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 9.

Images