Monitoring, detecting, estimating and warning CV2x-PC5

Abstract

The present disclosure provides for "monitoring, detecting, estimating, and alerting CV2X-PC5 operating states". Monitoring, detection, estimation, and warning of cellular vehicle-to-ambient PC5 (CV2X-PC5) operating conditions of a vehicle are performed. An input is received by the CV2X-PC5 indicating a message timing of a message for one or more subscribed vehicle features. Time synchronization of the received inputs is monitored. It is determined whether a synchronization problem is detected, including performing a regression estimate to early predict a potential time synchronization problem. In response to the occurrence of the synchronization problem, an alternative wireless communication medium of the vehicle is utilized to mitigate the impact of the synchronization problem on the one or more subscribed vehicle features.

Description

Technical Field

[0001] Aspects of the present disclosure generally relate to monitoring, detecting, estimating, and alerting on cellular vehicle-to-world PC5 (CV2X-PC5) operating status. Background Art

[0002] Vehicle-to-everything (V2X) is a type of communication that allows vehicles to communicate with various aspects of the traffic environment. This communication can include interacting with vehicles using vehicle-to-vehicle (V2V) communications and interacting with infrastructure using vehicle-to-infrastructure (V2I) communications. PC5 is a standard for V2X technology that covers device-to-device communications in the 5.9 GHz frequency band.

[0003] Vehicles may include radio transceivers and onboard units (OBUs) to facilitate V2X communications. Roadside units (RSUs) can provide wireless communications from roadside infrastructure to OBUs. This type of communication may be referred to as infrastructure-to-vehicle (I2V) communications. RSUs typically operate in the same frequency bands as V2X using technologies such as cellular vehicle-to-everything (CV2X) and dedicated short-range communications (DSRC). Some RSUs offer additional functionality, such as local Wi-Fi hotspots for pedestrians or cellular backhaul to transmit information to a central system. Summary of the Invention

[0004] In one or more illustrative examples, a method for monitoring the cellular vehicle-to-the-world PC5 (CV2X-PC5) operational status of a vehicle includes: receiving, via CV2X-PC5, input indicating message timing of messages for one or more subscribed vehicle features; monitoring time synchronization of the received input; determining whether a synchronization problem is detected, including performing regression estimation to early predict potential time synchronization problems; and in response to occurrence of the synchronization problem, utilizing an alternative wireless communication medium of the vehicle to mitigate an impact of the synchronization problem on the one or more subscribed vehicle features.

[0005] In one or more illustrative examples, a system for monitoring, detecting, estimating, and alerting on a cellular vehicle-to-the-world PC5 (CV2X-PC5) operational status of a vehicle includes one or more computing devices configured to: receive input indicating message timing of a message via CV2X-PC5 for one or more subscribed vehicle features; monitor time synchronization of the received input; determine whether a synchronization problem is detected, including performing regression estimation for early prediction of potential time synchronization problems; and in response to occurrence of the synchronization problem, utilize an alternative wireless communication medium of the vehicle to mitigate an impact of the synchronization problem on the one or more subscribed vehicle features.

[0006] In one or more illustrative examples, a non-transitory computer-readable medium includes instructions for monitoring, detecting, estimating, and warning about a cellular vehicle-to-the-world PC5 (CV2X-PC5) operational state of a vehicle, the instructions, when executed by one or more computing devices of the vehicle, causing the vehicle to perform operations including: receiving input indicating message timing of a message via CV2X-PC5, the message being for one or more subscribed vehicle features; monitoring time synchronization of the received input; determining whether a synchronization problem is detected, including performing regression estimation for early prediction of potential time synchronization problems; and in response to occurrence of the synchronization problem, utilizing an alternative wireless communication medium of the vehicle to mitigate an impact of the synchronization problem on the one or more subscribed vehicle features. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An exemplary system supporting the operation of the CV2X-PC5 timer method is shown;

[0008] Figure 2 Examples of vehicles in both outdoor and indoor environments are shown;

[0009] Figure 3 A data flow diagram illustrating the operation of the CV2X-PC5 timer algorithm;

[0010] Figure 4 shows an exemplary process for the operation of the CV2X-PC5 timer algorithm; and

[0011] Figure 5 An exemplary computing device supporting operation of the CV2X-PC5 timer algorithm is shown. DETAILED DESCRIPTION

[0012] As required, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to illustrate details of particular components. Therefore, the specific structural and functional details disclosed herein are not to be construed as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.

[0013] CV2X PC5 technology is a synchronous system. This means that CV2X-PC5 relies on precise timing of the transmission and reception of over-the-air (OTA) data packets. The time synchronization required for CV2X-PC5 operation may include that the CV2X device timing should be within ±12Ts (391ns) of the Global Navigation Satellite System (GNSS) time. The frequency stability of CV2X-PC5 operation may include that the CV2X device needs to maintain its carrier frequency within ±0.1 parts per million (PPM) within 1 time slot (e.g., 0.5 milliseconds) compared to the absolute frequency. 391ns is the allowed timing error for certain transmissions. It should be noted that this is only an example and other timing thresholds that are considered synchronous may be used.

[0014] Various methods can be used to determine and maintain the timing of CV2X-PC5 operations. In one example, GNSS signals from satellites can be used because they have improved time accuracy compared to signals from repeaters or simulators. In another example, Side Link Synchronization Signaling (SLSS) can be used at the PHY layer and / or Master Information Block messaging can be used at the Radio Link Control (RLC) sublayer to achieve time and frequency synchronization. However, identifying or predicting the transition between GNSS or SLSS time synchronization loss early enough in time to trigger corrective action can be challenging.

[0015] Applications using the CV2X-PC5 feature may also struggle to understand the reasons behind potential loss or pauses in CV2X-PC5 communications caused by timing drift, which also impacts overall CV2X-PC5 feature performance. Nevertheless, multiple applications using the CV2X-PC5 feature may rely on synchronized CV2X-PC5 timing, including various V2V applications, V2I / I2V applications, vehicle-to-pedestrian (V2P) applications, and vehicle-to-network (V2N) applications. Loss of timing synchronization may also impact CV2X-PC5 wireless communication radio frequency (RF) performance metrics.

[0016] Various aspects of the present disclosure relate to predicting the loss of time synchronization to address the potential impact on the transmission and reception of any CV2X-PC5 messages to and from the vehicle, so that various features of the vehicle can communicate information to vehicle clients via a human-machine interface (HMI) and other alternative wireless communication media. The method can be used to perform monitoring, detection, estimation, and warning of CV2X-PC5 operating status using CV2X-PC5 timer methods.

[0017] The CV2X-PC5 timer method can receive inputs including: CV2X-PC5 status (e.g., indicating the status of the vehicle's CV2X-PC5 components), vehicle's GNSS (e.g., semi-major axis accuracy, semi-minor axis accuracy, time confidence, number of available satellites, number of satellites in use, etc.), time uncertainty (e.g., from received and transmitted CV2X-PC5 messages), vehicle system clock (e.g., system clock time, clock drift time, gPTP report value, etc.), SLSS messages (e.g., SLSS messages received from one or more CV2X-PC5 RSUs), data from vehicle sensors (e.g., cameras, light detection and ranging (lidar), etc.), data from CV2X-PC5 messages (e.g., inter-packet gap (IPG), packet error rate (PER), received signal strength indicator (RSSI), etc.).

[0018] Based on the inputs, the CV2X-PC5 timer method can be used as a platform feature to support the timing of various vehicle CV2X-PC5 features. The method can include using a feedback loop system to monitor the inputs via both dynamic and static data rate intervals. Based on the received data, the method can detect whether time synchronization over a defined sample threshold drops below the 391ns threshold as described above, or whether time synchronization begins to drift closer to the 391ns threshold and is exceeded via a predefined condition. Based on detecting such a condition within a predefined duration, the CV2X-PC5 feature can instantaneously perform regression estimation training for early prediction of potential time synchronization issues. If a problem is identified, the method can alert any CV2X-PC5 features subscribed to the CV2X-PC5 timer feature output.

[0019] Based on this output, the CV2X-PC5 timer method can help the CV2X-PC5 feature provide an alert and / or initiate alternative wireless communication to allow the CV2X-PC5 feature to continue in the event of a lack of synchronization. The subscribed CV2X-PC5 feature can use the alert trigger to plan ahead for potential loss of CV2X-PC5 message delivery and / or notify the corresponding feature of the vehicle client that the potential feature is unavailable. The alert can also trigger the CV2X-PC5 wireless connection status and display the CV2X-PC5 wireless connection status on the vehicle HMI. The algorithm can also distinguish between GNSS reception via a repeater and real satellite reception, and can notify the corresponding CV2X-PC5 feature of potential synchronization issues specific to the repeater. Other aspects of the present disclosure are discussed in detail below.

[0020] Figure 1An exemplary system 100 that supports the operation of the CV2X-PC5 timer method is shown. As shown, the system 100 includes one or more vehicles 102. Each vehicle 102 may include various controllers, such as a telematics control unit (TCU) 104, a gateway controller 106, an infotainment controller 108, a GNSS controller 110, and an OBU 112. The vehicle 102 may also include various vehicle sensors 114. These components of the vehicle 102 may communicate over one or more buses, which may allow the OBU 112 to receive bus data 116 describing the operation of the components of the vehicle 102. This may include data from the TCU 104, the gateway controller 106, the infotainment controller 108, the GNSS controller 110, the vehicle sensors 114, and the OBU 112. Figure 1 The OBU 112 may include a transceiver 118 and may maintain data such as a map 120 and a CV2X-PC5 timer algorithm 122. The system 100 may also include various infrastructure elements 124 that communicate with the vehicle 102. These may include, for example, a multi-access edge computing (MEC) 126 device, an RSU 128, traffic controls 130, and infrastructure sensors 132. The system 100 may include additional components that communicate with the vehicle 102 and the infrastructure elements 124. For example, a vehicle manufacturing cloud 134 at the manufacturing plant that builds the vehicle 102 may wirelessly communicate with the vehicle 102 and the infrastructure elements 124. In turn, the vehicle manufacturing cloud 134 may wirelessly communicate with the vehicle 102 and the infrastructure elements 124. The vehicle manufacturing cloud 134 may, in turn, wirelessly communicate with the vehicle delivery manager cloud 136. The vehicle delivery manager cloud 136 may communicate with various entities configured to provide services to the vehicle 102. These entities may include, for example, dealers 138, insurance agencies 140, rental agencies 142, and valet parking 144. System 100 may also include a vehicle customer web portal cloud 146 that communicates with vehicle delivery manager cloud 136 and a user device 148 of a pedestrian or vehicle 102 user. User device 148 may also be configured to communicate with vehicle 102 to provide various V2P services to the pedestrian. It should be noted that the components of system 100 are merely examples. Other systems 100 may include more, fewer, or differently positioned components.

[0021] Vehicle 102 may include various other types of passenger vehicles, such as sedans, crossover utility vehicles (CUVs), vans, sport utility vehicles (SUVs), trucks, recreational vehicles (RVs), scooters, or other mobile machines used to transport people or goods. In many cases, vehicle 102 may be powered by an internal combustion engine. In such cases, the fuel source may be gasoline or diesel fuel. As another possibility, vehicle 102 may be a hybrid electric vehicle (HEV), powered by both an internal combustion engine and one or more electric motors, such as a series hybrid electric vehicle, a parallel hybrid electric vehicle, or a parallel / series hybrid electric vehicle. As yet another possibility, vehicle 102 may be an electric vehicle (EV), powered by an electric motor rather than an internal combustion engine. Because the type and configuration of vehicle 102 may vary, the capabilities of vehicle 102 may also vary accordingly. As some other possibilities, vehicle 102 may have different capabilities in terms of passenger capacity, towing capacity and capacity, and storage capacity. For ownership, inventory, and other purposes, vehicle 102 may be associated with a unique identifier, such as a vehicle identification number (VIN).

[0022] The TCU 104 may include network hardware configured to facilitate communication between the vehicle 102 and other devices of the system 100. The TCU 104 may include various types of computing devices that support the execution of the functions of the TCU 104 described herein. In one example, the TCU 104 may include one or more processors configured to execute computer instructions, and storage media on which computer-executable instructions and / or data may be maintained. Computer-readable storage media (also referred to as processor-readable media or storage devices) include any non-transitory (e.g., tangible) media that participates in providing data (e.g., instructions) that can be read by a computer (e.g., by a processor). Generally speaking, a processor receives instructions and / or data, such as from a storage device, into memory and uses the data to execute the instructions, thereby performing one or more processes, including one or more of the processes described herein. Computer-executable instructions may be compiled or interpreted according to a computer program created using a variety of programming languages ​​and / or techniques, including, but not limited to, JAVA, C, C++, C#, FORTRAN, PASCAL, VISUAL BASIC, PYTHON, JAVASCRIPT, PERL, etc., either individually or in combination.

[0023] The gateway controller 106 can be configured to provide an electrical interface between vehicle buses used for communication within the vehicle 102. In one example, the gateway controller 106 can be configured to route signals from one vehicle bus to another vehicle bus within the vehicle 102. The gateway controller 106 can accordingly allow different components of the vehicle 102 to communicate despite the components being connected to different buses in different manners.

[0024] The infotainment controller 108 may be configured as an HMI that provides various services to the occupants of the vehicle 102. These services may include, for example, emergency calls, turn-by-turn navigation, media playback, etc. The HMI may include various screens, touch screens, speakers, microphones, etc. for allowing information to be received from and provided to the occupants.

[0025] The GNSS controller 110 may allow the vehicle 102 to perform autonomous geospatial positioning of the vehicle 102. As some examples, the GNSS controller 110 functionality may allow the vehicle 102 to determine its location using one or more satellite networks, such as Global Positioning System (GPS), GLONASS, Galileo, BeiDou, and / or others.

[0026] The OBU 112 can be configured to provide telematics services to the vehicle 102. As some non-limiting possibilities, these services may include navigation, turn-by-turn directions, vehicle health reports, local business searches, accident reporting, and hands-free calling. The OBU 112 can communicate with a transceiver 118. Thus, the OBU 112 can be configured to communicate via a cellular network using various protocols utilizing the transceiver 118. For example, the OBU 112 can access the cellular network via a connection to one or more cellular towers. To facilitate communication over the communication network, the OBU 112 can be associated with a unique device identifier (e.g., a mobile device number (MDN), an Internet Protocol (IP) address, etc.) to identify the OBU 112 communications over the communication network as associated with the vehicle 102. Additionally, the OBU 112 can be configured to communicate via a broadcast peer-to-peer protocol (such as PC5) to facilitate V2X communication with devices such as the RSU 128. It should be noted that these protocols are merely examples, and that different peer-to-peer and / or cellular technologies may be used.

[0027] The vehicle sensors 114 may be configured to receive information about the surrounding environment of the vehicle 102. In one example, the vehicle sensors 114 may include one or more of a camera (e.g., an advanced driver assistance system (ADAS) camera), an ultrasonic sensor, a radio detection and ranging (radar) system, and / or a lidar system.

[0028] The bus data 116 may include information transmitted across one or more buses of the vehicle 102. A vehicle bus may include various communication methods available between components of the vehicle 102. As some non-limiting examples, a vehicle bus may include one or more of a vehicle controller area network (CAN), Ethernet, and / or a media oriented systems transport (MOST) network.

[0029] The transceiver 118 can be configured to provide wireless communication services to the TCU 104. The TCU 104 can include or otherwise have access to a transceiver 118 configured to facilitate communication with other vehicles 102 or with infrastructure elements 124. The TCU 104 can also be configured to communicate via various other protocols, such as communicating with a communication network via a network protocol such as Uu. Additionally, the TCU 104 can be configured to communicate via a broadcast peer-to-peer protocol (e.g., PC5) to facilitate CV2X communication with devices such as other vehicles 102. It should be noted that these protocols are merely examples and that different peer-to-peer and / or cellular technologies can be used.

[0030] Map 120 may include information such as road segment shape, segment markings, the location of traffic controls 130 and obstacles, and other information that may be useful to vehicle 102 as it traverses the road. Map 120 may be constructed using data collected from various vehicle sensors 114 and / or by using aerial imagery.

[0031] The CV2X-PC5 timer algorithm 122 may be configured to perform monitoring, detection, estimation, and warning functions regarding the cellular vehicle's PC5 operational status to the outside world. Figure 3 Other aspects of the operation of the CV2X-PC5 timer algorithm 122 are discussed in detail.

[0032] The infrastructure elements 124 may include various hardware external to the vehicle 102 that communicates with the vehicle 102. The infrastructure elements 124 may include elements that communicate with the vehicle 102 during construction (such as in a manufacturing facility), during service (such as at a dealership 138), and while in motion (such as along a road or within a parking facility).

[0033] The MEC 126 may include various multi-access edge computing or mobile edge computing devices. The MEC 126 may include various hardware and software components to enable cloud computing capabilities for the vehicle 102 or other infrastructure elements 124. The use of the MEC 126 allows processing to be performed closer to the vehicle 102 rather than remotely at a central cloud computing site.

[0034] The RSU 128 may be a device with processing and networking capabilities and may be designed to be placed near a roadway for communication with the vehicle 102. In one example, the RSU 128 may include hardware configured to communicate via a broadcast peer-to-peer protocol, such as PC5, to facilitate V2X communication with the vehicle 102. The RSU 128 may also have wired or wireless backhaul capabilities to allow for wired or wireless communication with other elements of the system 100.

[0035] Traffic controls 130 may include various devices that may monitor and facilitate travel of the vehicle 102 along a road, such as traffic lights, stop signs, train crossings, warning signs, and the like.

[0036] Infrastructure sensors 132 may include various devices that use cameras, lidar, radar, electromagnetic, wireless backscatter, etc. to track the location or other attributes of vehicles 102, pedestrians or other traffic participants or obstacles, such as red light cameras, wireless toll gantries, parking meters, under-road traffic flow counter loops, etc.

[0037] The vehicle manufacturing cloud 134 may include various wired and / or wireless infrastructure installed at the manufacturing plant where the vehicle 102 is built. This infrastructure may wirelessly communicate with the vehicle 102 and / or infrastructure elements 124 to provide information regarding the location, build status, or other aspects of the vehicle 102 during and after the build process but prior to shipping and delivery.

[0038] Vehicle delivery manager cloud 136 may include various wired and / or wireless infrastructure configured to provide information regarding the location, status, or other aspects of vehicles 102 after the build process and during shipping and delivery. Dealers 138 may be configured to receive information from vehicle delivery manager cloud 136. This may allow dealers 138 to receive the current shipping status of vehicles 102 ordered and / or under construction. Insurance agencies 140 may be configured to receive information from vehicle delivery manager cloud 136. This may allow insurance agencies 140 to update their records regarding when vehicles 102 are available for insurance coverage. Rental agencies 142 may be configured to receive information from vehicle delivery manager cloud 136. This may allow rental agencies 142 to update their records regarding when vehicles 102 are available for rental. Valet parking 144 may be configured to receive information from vehicle delivery manager cloud 136. This may allow valet parking 144 to update its records regarding which vehicles 102 are parked and / or retrieved at which locations.

[0039] The vehicle customer web portal cloud 146 may include various wired and / or wireless infrastructures configured to provide services to user devices 148 regarding vehicles 102 and / or regarding status information from the vehicle delivery manager cloud 136. In one example, the vehicle customer web portal cloud 146 may allow a user to identify and / or update the build status, insurance status, parking status, etc. of one or more vehicles 102.

[0040] Figure 2 The example 200 of the vehicle 102 is shown in both an outdoor environment 202 and an indoor environment 204. The outdoor environment 202 may include, for example, a road or off-road trail. The indoor environment 204 may include, for example, a factory, a dealership 138, a service center, a parking garage, etc.

[0041] Automatic vehicle marshaling (AVM) server 206 may be configured to monitor vehicles 102, whether vehicles 102 are in outdoor environment 202 or indoor environment 204. AVM server 206 may be configured to perform GNSS-based location services for locating vehicles 102, including providing a map of the locations of multiple vehicles 102 on a map. AVM server 206 may also be configured to receive sensor data from infrastructure sensors 132 to form a more complete view of the status of each of vehicles 102 in addition to the location of each of vehicles 102.

[0042] When operating in the outdoor environment 202, the AVM server 206 may be configured to utilize the constellation of GNSS satellites 208 to facilitate geolocation of the vehicle 102. This may be accomplished, for example, via the vehicle 102 utilizing its GNSS controller 110 to locate itself using the GNSS satellites 208 and wirelessly transmitting this location information via its OBU 112 and transceiver 118 to the RSU 128, which is in communication with the AVM server 206.

[0043] However, when operating in indoor environment 204, vehicle 102 can utilize signals from GNSS repeater 210. GNSS repeater 210 can receive signals from a constellation of GNSS satellites 208 via antenna 212 located within the line of sight of GNSS satellites 208. GNSS repeater 210 can capture GNSS broadcasts using antenna 212 and rebroadcast those signals into indoor environment 204. This allows vehicle 102 to utilize location services while inside, which would otherwise be impossible because vehicle 102 would not be visible to the constellation of GNSS satellites 208 when located in indoor environment 204. However, the repeater approach can reduce the accuracy of GNSS position while in indoor environment 204.

[0044] The AVM server 206 may require precise CV2X-PC5 timing to transmit and receive messages. However, it may be difficult for the AVM server 206 to understand the reasons behind potential loss or suspension of CV2X-PC5 communications caused by time drift, which also affects overall CV2X-PC5 feature performance. Nevertheless, multiple CV2X-PC5 applications may rely on synchronized CV2X-PC5 timing, including various V2V applications, V2I / I2V applications, vehicle-to-pedestrian (V2P) applications, and vehicle-to-network (V2N) applications. Loss of time synchronization may also affect CV2X-PC5 wireless communication radio frequency (RF) performance metrics.

[0045] Figure 3 A data flow diagram 300 illustrates the operation of the CV2X-PC5 timer algorithm 122. The CV2X-PC5 timer algorithm 122 can predict the loss of time synchronization. This can be used to account for the impact of the loss of time synchronization on any CV2X-PC5 message transmissions and receipts from the vehicle 102. Based on inputs, the CV2X-PC5 timer algorithm 122 can serve as a platform feature to support the timing of various CV2X-PC5 features of the vehicle 102. The CV2X-PC5 timer algorithm 122 can be used to perform monitoring, detection, estimation, and alerting of CV2X-PC5 operational states. As shown, the CV2X-PC5 timer algorithm 122 can include an input component 302, a monitoring component 304, a detection component 306, an estimation component 308, a alerting component 310, and an output component 312. Note that this is merely an example, and different modularizations of the functionality of the CV2X-PC5 timer algorithm 122 can be used.

[0046] Input component 302 can be configured to receive various inputs. These inputs may include CV2X-PC5 message transmission / reception status 314, as identified from transceiver 118. This information may include status data indicating the CV2X-PC5 status of vehicle 102 and time uncertainty identified from received and transmitted CV2X-PC5 messages. Inputs may also include GNSS position 316 of vehicle 102, as determined using GNSS controller 110. These inputs may include, for example, semi-major axis accuracy, semi-minor axis accuracy, time confidence, number of available satellites, number of satellites in use, whether repeaters are used, etc. Inputs may also include time uncertainty 318, which may be identified, for example, from received and transmitted CV2X-PC5 messages. Inputs may also include vehicle system clock 320, which may include, for example, system clock time of various controllers in vehicle 102, clock drift time, gPTP report values, etc. Inputs may also include SLSS messages 322, which may include, for example, receiving SLSS messages 322 from one or more CV2X-PC5 RSUs 128. The inputs may also include sensor data 324 from the vehicle sensors 114. This may include images from a camera, 3D data from a lidar, or a point cloud, etc. The inputs may also include key performance indicator (KPI) data 326 from CV2X-PC5 messages. This may include, for example, IPG, PER, RSSI, etc. The input component 302 may capture these inputs and buffer and synchronize them for use by other operations of the CV2X-PC5 timer algorithm 122.

[0047] The monitoring component 304 can include using a feedback loop system to monitor input via both dynamic and static data rate intervals. In one example, the monitoring component 304 can monitor input via the input component 302 using a dynamic data rate interval or a static data rate interval based on the feedback loop system determined by the detection component 306. For example, if the SemiMajorAxisAccuracy inaccuracy exceeds a threshold, if the SemiMinorAxisAccuracy inaccuracy exceeds a threshold, and / or if the GNSSTimeConfidence is less than a threshold, a dynamic data rate for monitoring can be set. Otherwise, a static rate can be used for monitoring. As used herein, a static rate can refer to a rate with a fixed frequency (such as 1 Hz), while a dynamic rate can refer to a slower and / or variable rate with a frequency such as 10 Hz (but other rates are also possible). A dynamic rate can provide more data rate points for the timer algorithm to choose from, thereby allowing flexibility in processing update rates.

[0048] Detection component 306 can detect whether time synchronization at a defined sample threshold has dropped below a 391ns threshold, or whether time synchronization has begun to drift closer to the 391ns threshold and has been exceeded via a predefined condition. Based on this determination, detection component 306 can inform monitoring component 304 whether to use a static rate or a dynamic rate. One of the key data elements used to detect drift is the time uncertainty value. The time uncertainty can be received from the CV2X-PC5 radio module itself. Detection component 306 can perform operations as shown in the following pseudo code:

[0049]

[0050] The CV2X-PC5_status value may be calculated based on threshold states, which may include unknown, active, and inactive. If the threshold state indicates that the state is at least at the active threshold, then the first if of condition 1 may be satisfied, while if the threshold state indicates that the state is inactive, then the else if may be satisfied.

[0051] GNSS_setting_value can be configurable to adjust the confidence level of its comparison. For example, the first predetermined value can be configured as a first confidence level, e.g., 68% of the output value is inside and the remaining 32% is outside, while the second predetermined value can be configured as a second confidence level, e.g., 35% is outside.

[0052] If alert_timer_module is set to false, no timer alert is issued, which means that the V2X functionality is working as expected under operating conditions.

[0053] Regarding vehicle_system_module_drifttime, this is the time reported by the system time of the vehicle 102. The system time of the vehicle 102 may report the drift time from the current time and lag the previous time within a predefined period of trailing sampling points (e.g., 10 sampling points), for example, when compared to a UTC 1 millisecond time interval value.

[0054] Timer_Estimation is used to indicate whether to execute the training regression. If this value is set to true, the training regression algorithm is executed. If it is set to false, the training regression algorithm is not executed.

[0055] check_slss_message_reception can verify the received message data when an SLSS message is received by CV2X-PC5. SLSS messages are broadcast every 100 milliseconds by the RSU infrastructure and can therefore be received every 100 milliseconds by the vehicle 102. If no SLSS message is received, the vehicle 102 proceeds to condition 1 of the GNSS check.

[0056] The estimation component 308 can instantaneously perform regression estimation training based on detecting such a time synchronization condition within a predefined duration for early prediction of potential time synchronization problems. The estimation can be performed as shown in the following pseudo code:

[0057]

[0058] It should be noted that while the pseudocode is similar or identical in either branch of the if statement, the functionality depends on alert_timer_module being true rather than false. For example, subscribed CV2X-PC5 features can determine whether they need to verify content every 100 millisecond iteration, which can vary based on whether alert_timer_module is true or false.

[0059] The slss_message_reception_data_valid field checks the received SLSS message data content, for example, every 10 milliseconds. If the content meets various requirements (such as physical level validity), the data can be considered valid. Some example data elements and parameters to be confirmed include whether the SLSS message has a synchronization source (e.g., eNB, RSU, GNSS, etc.), congestion of data rate and signal strength, transmission rate of CV2X-PC5 (e.g., based on SPS or event), time synchronization, etc.

[0060] function_of_estimation_training_regression refers to an AI-trained neural network training model that performs operations based on input and provides output in the form of level and confidence. Confidence can be classified under various categories, and an exemplary set of five categories may include 50%, 68%, 95%, 99%, 99.9%. Levels can be classified under various levels, and an exemplary set of three levels may include level-0, level-1, level-2, where level-0 is low and level-2 is high. When both level and confidence are combined, this can alert the corresponding subscribing function based on the timer output algorithm at what level and confidence the corresponding entity should utilize them. If the level is 2 and the confidence is 99.9%; then its highest level and confidence, the entity can use to trust the timer output algorithm.

[0061] If a problem is identified, the alert component 310 can alert any CV2X-PC5 features that subscribe to the CV2X-PC5 timer feature output. For example, a feature of the vehicle 102 can subscribe to receive timing information from the CV2X-PC5 timer algorithm 122, and the CV2X-PC5 timer algorithm 122 can send updates to the subscribed feature 328. This can allow the subscribed feature 328 to be notified of drift or other timing issues. The alert component 310 can also update the message time uncertainty 318 and can provide information for use in an HMI alert 330 and / or the use of an alternative wireless communication medium 332.

[0062] The warning can be implemented as shown in the following pseudo code:

[0063]

[0064] function_of_estimation_training_regression refers to an AI-trained neural network training model that performs operations based on input and provides output in the form of level and confidence. Confidence can be classified under various categories, and an exemplary set of five categories may include 50%, 68%, 95%, 99%, 99.9%. Levels can be classified under various levels, and an exemplary set of three levels may include level-0, level-1, level-2, where level-0 is low and level-2 is high. When both level and confidence are combined, this can alert the corresponding subscribing function based on the timer output algorithm at what level and confidence the corresponding entity should utilize them. If the level is 2 and the confidence is 99.9%; then its highest level and confidence, the entity can use to trust the timer output algorithm.

[0065] Output component 312 may facilitate the CV2X-PC5 feature to provide timing-related outputs to subscribed features 328. Subscribed CV2X-PC5 features may use alert triggers to plan ahead for potential loss of CV2X-PC5 messaging and / or notify the vehicle customer of potential feature unavailability.

[0066] If a timing issue is identified, output component 312 may also provide an HMI alert 330 to the user. In one example, output component 312 may trigger and display the CV2X-PC5 wireless connection status on the HMI of vehicle 102. For example, HMI alert 330 may be provided by output component 312 to infotainment controller 108 for display on the HMI of vehicle 102. HMI alert 330 may indicate that there is a problem with the time synchronization of wireless messages. Additionally or alternatively, HMI alert 330 may indicate that subscribed features 328 may be operating with reduced efficiency or may not be operating. In one example, HMI alert 330 may include a list of affected features.

[0067] The output component 312 may also suggest using an alternative wireless communication medium 332 (e.g., connection through the user's phone, connection to Wi-Fi, connection via another local vehicle 102, etc.) to allow the CV2X-PC5 feature to continue despite the lack of synchronization.

[0068] The CV2X-PC5 timer algorithm 122 can also distinguish between GNSS reception via the GNSS repeater 210 and reception via the real GNSS satellites 208 and can notify the corresponding CV2X-PC5 feature of potential synchronization issues specific to the repeater. This information can be provided to the subscription feature 328 and / or can be displayed in the HMI alert 330.

[0069] The confidence level (e.g., from low to high) can also be encoded and included in the C-V2X-PC5 message being broadcast to inform other participants of the synchronization level of the self-aware vehicle 102. This confidence level can then be used by remote vehicles 102 running the same algorithm to estimate future synchronization states. The AVM server 206 can also receive the message and create a map of the synchronization levels of participating vehicles 102, which can help predict possible signal outages due to synchronization loss. In another example, an alert can be issued to the vehicle 102 about the cluster location where synchronization loss occurred (e.g., to allow the vehicle 102 to preemptively adjust to another wireless protocol), and / or to allow the network operator to investigate the location (e.g., repair equipment, add additional cells to the network, etc.).

[0070] Figure 4 An exemplary process 400 is shown for the operation of the CV2X-PC5 timer algorithm 122. In one example, the process 400 may be performed by the OBU 112 executing the operation of the CV2X-PC5 timer algorithm 122 as discussed in detail herein.

[0071] At operation 402, the OBU 112 receives inputs indicative of CV2X timing. These inputs may be received into the input component 302 of the CV2X-PC5 timer algorithm 122. In one example, the inputs may include CV2X-PC5 message transmission / reception status 314, as identified from the transceiver 118; the GNSS position 316 of the vehicle 102, as determined using the GNSS controller 110; timing uncertainty 318, for example, identified from received and transmitted CV2X-PC5 messages; vehicle system clocks 320, including various controllers of the vehicle 102; SLSS messages 322; sensor data 324 from the vehicle sensors 114; and / or KPI data 326 from CV2X-PC5 messages. The input component 302 may capture these inputs and buffer and synchronize them for use by other operations of the CV2X-PC5 timer algorithm 122.

[0072] At operation 404, the OBU 112 monitors the time synchronization of the received input. In one example, the monitoring component 304 can monitor the input via the input component 302 using a dynamic data rate interval or a static data rate interval based on a feedback loop system determined by the detection component 306. For example, if the SemiMajorAxisAccuracy inaccuracy exceeds a threshold, if the SemiMinorAxisAccuracy inaccuracy exceeds a threshold, and / or if the GNSSTimeConfidence is less than a threshold, a dynamic data rate can be set for monitoring. Otherwise, a static rate can be used for monitoring. In addition, the detection component 306 can detect whether the time synchronization at a defined sample threshold has dropped below a 391ns threshold, or whether the time synchronization has begun to drift closer to the 391ns threshold and has been exceeded via a predefined condition. Based on this determination, the detection component 306 can inform the monitoring component 304 whether to use a static rate or a dynamic rate.

[0073] At operation 406, the OBU 112 determines whether a synchronization problem is detected. In one example, the estimation component 308 can instantaneously perform regression estimation training based on the detection of a time synchronization condition within a predefined duration to provide early prediction of potential time synchronization problems. If a synchronization problem is detected, control passes to operation 408. If not, process 400 ends.

[0074] At operation 408, the OBU 112 generates an alert based on the synchronization issue. In one example, the alert component 310 can alert any CV2X-PC5 features that subscribe to the CV2X-PC5 timer feature output. For example, a feature of the vehicle 102 can subscribe to receive timing information from the CV2X-PC5 timer algorithm 122, and the CV2X-PC5 timer algorithm 122 can send updates to the subscribed feature 328. This can allow the subscribed feature 328 to be notified of drift or other timing issues. The alert component 310 can also update the message time uncertainty 318 and can provide information for use in an HMI alert 330 and / or the use of an alternative wireless communication medium 332.

[0075] At operation 410, the OBU 112 provides output to the subscription feature 328 and / or the HMI alert 330. In one example, the alert component 310 may notify the output component 312, which may indicate the condition to the subscription feature 328 and / or send the HMI alert 330 for display to the user.

[0076] At operation 412, the OBU 112 provides an update of the subscription feature 328 to utilize the alternative wireless communication medium 332. In one example, the alert component 310 can send a message to the alternative wireless communication medium 332 to take over the message to allow the subscription feature 328 to continue to function despite the identification of the synchronization problem. After operation 412, the process 400 ends.

[0077] Figure 5 An exemplary computing device supporting the operation of the CV2X-PC5 timer algorithm 122 is shown. Figure 5 And refer to Figures 1 to 4 The vehicle 102, TCU 104, gateway controller 106, infotainment controller 108, GNSS controller 110, OBU 112, vehicle sensor 114, transceiver 118, infrastructure element 124, MEC 126, RSU 128, traffic control 130, infrastructure sensor 132, vehicle manufacturing cloud 134, vehicle delivery manager cloud 136, dealer 138, insurance agency 140, rental agency 142, valet parking 144, vehicle customer web portal cloud 146, user device 148, detection component 306, GNSS satellite 208, GNSS relay 210, etc. may be examples of such computing devices 502. The computing devices 502 generally include computer-executable instructions, such as those of the PC5 timer algorithm 122, wherein the instructions may be executable by one or more computing devices 502. The computer executable instructions may be compiled or interpreted from a computer program created using a variety of programming languages ​​and / or technologies, including, but not limited to, Java, TM, C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, etc. Generally speaking, a processor (e.g., a microprocessor) receives instructions, for example, from a memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. Such instructions and other data can be stored and transmitted using a variety of computer-readable media.

[0078] As shown, computing device 502 may include processor 504 operatively connected to storage device 506, network device 508, output device 510, and input device 512. It should be noted that this is merely an example and computing device 502 having more, fewer, or different components may be used.

[0079] The processor 504 may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and / or a graphics processing unit (GPU). In some examples, the processor 504 is a system on a chip (SoC) that integrates the functionality of a CPU and a GPU. The SoC may optionally include other components (such as, for example, a storage device 506 and a network device 508) into a single integrated device. In other examples, the CPU and GPU are interconnected via peripheral connection devices (such as a high-speed peripheral component interconnect (PCI) or another suitable peripheral data connection). In one example, the CPU is a commercially available central processing unit that implements an instruction set, such as one of the x86, ARM, Power, or microprocessor (MIPS) instruction set families without interlocked pipeline stages.

[0080] Regardless of the details, during operation, the processor 504 executes stored program instructions retrieved from the storage device 506. The stored program instructions accordingly comprise software that controls the operation of the processor 504 to perform the operations described herein. The storage device 506 may include both non-volatile memory devices and volatile memory devices. Non-volatile memory includes solid-state memory, such as NAND flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is disabled or loses power. Volatile memory includes static and dynamic random access memory (RAM), which stores program instructions and data during operation of the system 100.

[0081] The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to an output device 510. The output device 510 may include a graphics or visual display device, such as an electronic display screen, a projector, a printer, or any other suitable device for reproducing a graphical display. As another example, the output device 510 may include an audio device, such as a speaker or headphones. As yet another example, the output device 510 may include a tactile device, such as a mechanically elevable device, which in one example may be configured to display Braille or another physical output that can be touched to provide information to the user.

[0082] Input device 512 may include any of a variety of devices that enable computing device 502 to receive control input from a user. Examples of suitable input devices 512 that receive human interface input may include a keyboard, mouse, trackball, touch screen, microphone, graphics tablet, etc.

[0083] The network devices 508 may each include any of a variety of devices that enable the described components to send and / or receive data from external devices over a network. Examples of suitable network devices 508 include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a Bluetooth or Bluetooth Low Energy (BLE) transceiver, or other network adapters or peripheral interconnects that receive data from another computer or external data storage device, which may be useful for receiving large amounts of data in an efficient manner.

[0084] With respect to the processes, systems, methods, heuristics, and the like described herein, it should be understood that although the steps of such processes, etc. have been described as occurring according to a certain ordered sequence, such processes can be practiced by performing the steps described in an order different from that described herein. It should also be understood that certain steps can be performed simultaneously, other steps can be added, or certain steps described herein can be omitted. In other words, the descriptions of processes herein are provided for the purpose of illustrating specific embodiments and should in no way be construed as limiting the claims.

[0085] Therefore, it should be understood that the above description is intended to be illustrative and not restrictive. Upon reading the above description, many embodiments and applications other than the examples provided will be apparent. The scope should not be determined with reference to the above description, but rather with reference to the appended claims and the full range of equivalents to which such claims are entitled. It is anticipated and expected that the technology discussed herein will develop in the future, and that the disclosed systems and methods will be incorporated into such future embodiments. In short, it should be understood that the present application is capable of modification and variation.

[0086] All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by persons skilled in the art described herein, unless an explicit indication to the contrary is given herein. Specifically, use of singular articles such as "a," "an," "the," and "said" should be construed to recite one or more of the indicated elements unless a claim recites an explicit limitation to the contrary.

[0087] The Abstract of the present disclosure is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It should be understood that the Abstract will not be used to interpret or limit the scope or meaning of the claims. Additionally, in the foregoing Detailed Description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. This approach to the present disclosure should not be interpreted as reflecting an intention that the claimed embodiments require more features than expressly recited in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in less than all the features of a single disclosed embodiment. Accordingly, the appended claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separately claimed subject matter.

[0088] Although exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the present disclosure. Rather, the words used in this specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the present disclosure. In addition, the features of the various implementing embodiments may be combined to form additional embodiments of the present disclosure.

[0089] According to the present invention, a method for monitoring, detecting, estimating and warning the cellular vehicle to outside world PC5 (CV2X-PC5) operating status of a vehicle includes: receiving input indicating message timing of a message for one or more subscribed vehicle features via CV2X-PC5; monitoring the time synchronization of the received input; determining whether a synchronization problem is detected, including performing regression estimation to predict potential time synchronization problems early; and in response to the occurrence of the synchronization problem, utilizing an alternative wireless communication medium of the vehicle to mitigate the impact of the synchronization problem on the one or more subscribed vehicle features.

[0090] In one aspect of the invention, the method includes notifying the one or more subscribed vehicle features of the synchronization problem.

[0091] In one aspect of the invention, the method includes indicating the synchronization problem via a human machine interface (HMI) alert to be provided to a user of the vehicle.

[0092] In one aspect of the invention, the input includes one or more of: a CV2X-PC5 message transmission / reception status as identified from the vehicle's transceiver; status data indicative of the vehicle's CV2X-PC5 status; a GNSS position of the vehicle as determined using the vehicle's Global Navigation Satellite System (GNSS) controller; a time uncertainty as identified from a CV2X-PC5 message sent from or received to the vehicle; a vehicle system clock of one or more controllers of the vehicle; a side link synchronization signal (SLSS) message received by the vehicle from one or more CV2X-PC5 roadside units (RSUs); sensor data from vehicle sensors; and / or key performance indicator (KPI) data from the CV2X-PC5 messages.

[0093] In one aspect of the invention, the monitoring switches between a static rate or a dynamic rate based on one or more of SemiMajorAxisAccuracy accuracy, SemiMinorAxisAccuracy accuracy, and / or GNSSTimeConfidence.

[0094] In one aspect of the invention, the regression estimation comprises providing an output indicating a time synchronization level and a confidence level at the level using a neural network trained based on the input indicating message timing of messages, wherein the level and confidence value are provided to the one or more subscribed vehicle features to allow the one or more subscribed vehicle features to be debugged based on the time synchronization level and the confidence level at the level.

[0095] In one aspect of the invention, the potential time synchronization problem includes that the time synchronization has begun to drift closer to a maximum tolerance, while the time synchronization has not yet exceeded the maximum tolerance.

[0096] According to the present invention, a system for monitoring, detecting, estimating and warning the cellular vehicle-to-the-world PC5 (CV2X-PC5) operating status of a vehicle is provided, which has: one or more computing devices, wherein the one or more computing devices are configured to: receive input indicating message timing of messages through CV2X-PC5, wherein the messages are for one or more subscribed vehicle features; monitor the time synchronization of the received input; determine whether a synchronization problem is detected, including performing regression estimation to predict potential time synchronization problems early; and in response to the occurrence of the synchronization problem, utilize an alternative wireless communication medium of the vehicle to mitigate the impact of the synchronization problem on the one or more subscribed vehicle features.

[0097] According to an embodiment, the one or more computing devices are further configured to notify the one or more subscribed vehicle features of the synchronization problem.

[0098] According to an embodiment, the one or more computing devices are further configured to indicate the synchronization problem via a human machine interface (HMI) alert to be provided to a user of the vehicle.

[0099] According to an embodiment, the input includes one or more of: a CV2X-PC5 message transmission / reception status as identified from the vehicle's transceiver; status data indicative of the vehicle's CV2X-PC5 status; a GNSS position of the vehicle as determined using the vehicle's Global Navigation Satellite System (GNSS) controller; a time uncertainty as identified from a CV2X-PC5 message sent from or received to the vehicle; a vehicle system clock of one or more controllers of the vehicle; a side link synchronization signal (SLSS) message received by the vehicle from one or more CV2X-PC5 roadside units (RSUs); sensor data from vehicle sensors; and / or key performance indicator (KPI) data from the CV2X-PC5 messages.

[0100] According to an embodiment, the monitoring switches between a static rate or a dynamic rate based on one or more of SemiMajorAxisAccuracy accuracy, SemiMinorAxisAccuracy accuracy and / or GNSSTimeConfidence.

[0101] According to an embodiment, the regression estimation includes providing an output indicating a time synchronization level and a confidence level at the level using a neural network trained based on the input indicating message timing of messages, wherein the level and confidence value are provided to the one or more subscribed vehicle features to allow the one or more subscribed vehicle features to be debugged based on the time synchronization level and the confidence level at the level.

[0102] According to an embodiment, the potential time synchronization problem comprises that the time synchronization has started to drift closer to a maximum tolerance, while the time synchronization has not yet exceeded the maximum tolerance.

[0103] According to the present invention, a non-transitory computer-readable medium is provided, which has instructions for monitoring, detecting, estimating and warning the cellular vehicle-to-the-world PC5 (CV2X-PC5) operating status of a vehicle, and when the instructions are executed by one or more computing devices of the vehicle, the vehicle performs operations including: receiving input indicating message timing of a message via CV2X-PC5, the message being used for one or more subscribed vehicle features; monitoring time synchronization of the received input; determining whether a synchronization problem is detected, including performing regression estimation to predict potential time synchronization problems early; and in response to the occurrence of the synchronization problem, utilizing an alternative wireless communication medium of the vehicle to mitigate the impact of the synchronization problem on the one or more subscribed vehicle features.

[0104] According to an embodiment, the invention also features instructions that, when executed by the one or more computing devices, cause the vehicle to perform operations including notifying one or more subscribed vehicle features of a synchronization problem.

[0105] According to an embodiment, the invention also features instructions that, when executed by the one or more computing devices, cause the vehicle to perform operations including indicating the synchronization issue via a human machine interface (HMI) alert to be provided to a user of the vehicle.

[0106] According to an embodiment, the input includes one or more of: a CV2X-PC5 message transmission / reception status as identified from the vehicle's transceiver; status data indicative of the vehicle's CV2X-PC5 status; a GNSS position of the vehicle as determined using the vehicle's Global Navigation Satellite System (GNSS) controller; a time uncertainty as identified from a CV2X-PC5 message sent from or received to the vehicle; a vehicle system clock of one or more controllers of the vehicle; a side link synchronization signal (SLSS) message received by the vehicle from one or more CV2X-PC5 roadside units (RSUs); sensor data from vehicle sensors; and / or key performance indicator (KPI) data from the CV2X-PC5 messages.

[0107] According to an embodiment, the monitoring switches between a static rate or a dynamic rate based on one or more of SemiMajorAxisAccuracy accuracy, SemiMinorAxisAccuracy accuracy and / or GNSSTimeConfidence.

[0108] According to an embodiment, the regression estimation includes providing an output indicating a time synchronization level and a confidence level at the level using a neural network trained based on the input indicating message timing of messages, wherein the level and confidence value are provided to the one or more subscribed vehicle features to allow the one or more subscribed vehicle features to be debugged based on the time synchronization level and the confidence level at the level, and the potential time synchronization problem includes that the time synchronization has begun to drift closer to a maximum tolerance, while the time synchronization has not yet exceeded the maximum tolerance.

Claims

1. A method for monitoring, detecting, estimating, and alerting a vehicle's cellular vehicle-to-the-world (CV2X-PC5) operating status, comprising: receiving, by the CV2X-PC5, input indicating message timing for messages for one or more subscribed vehicle features; monitoring time synchronization of received inputs; determining whether a synchronization problem is detected, including performing regression estimation for early prediction of potential time synchronization problems; and In response to the occurrence of the synchronization problem, an alternative wireless communication medium of the vehicle is utilized to mitigate an effect of the synchronization problem on the one or more subscribed vehicle features. 2 . The method of claim 1 , further comprising notifying the one or more subscribed vehicle features of the synchronization issue. 3 . The method of claim 1 , further comprising indicating the synchronization problem via a human machine interface (HMI) alert to be provided to a user of the vehicle.

4. The method of claim 1 , wherein the input comprises one or more of: CV2X-PC5 message transmission / reception status as identified from the vehicle's transceiver; Status data indicating the CV2X-PC5 status of the vehicle; a Global Navigation Satellite System (GNSS) position of the vehicle as determined using a GNSS controller of the vehicle; a time uncertainty as identified from a CV2X-PC5 message sent by or received from the vehicle; a vehicle system clock of one or more controllers of the vehicle; Side Link Synchronization Signal (SLSS) messages received by the vehicle from one or more CV2X-PC5 Roadside Units (RSUs); sensor data from vehicle sensors; and / or Key Performance Indicator (KPI) data from the CV2X-PC5 message. 5 . The method of claim 1 , wherein the monitoring switches between a static rate or a dynamic rate based on one or more of SemiMajorAxisAccuracy accuracy, SemiMinorAxisAccuracy accuracy, and / or GNSSTimeConfidence.

6. The method of claim 1 , wherein the regression estimating comprises providing an output indicating a time synchronization level and a confidence level at the level using a neural network trained based on the input indicating message timing of messages, wherein the level and confidence value are provided to the one or more subscribed vehicle features to allow the one or more subscribed vehicle features to be debugged based on the time synchronization level and the confidence level at the level.

7. The method of claim 1, wherein the potential time synchronization problem comprises that the time synchronization has begun to drift closer to a maximum tolerance, but the time synchronization has not yet exceeded the maximum tolerance.

8. A system for monitoring, detecting, estimating, and alerting a vehicle's cellular vehicle-to-the-world (CV2X-PC5) operating status, comprising: One or more computing devices, the one or more computing devices being configured to: receiving, by the CV2X-PC5, input indicating message timing for messages for one or more subscribed vehicle features; monitoring time synchronization of received inputs; determining whether a synchronization problem is detected, including performing regression estimation for early prediction of potential time synchronization problems; and In response to the occurrence of the synchronization problem, an alternative wireless communication medium of the vehicle is utilized to mitigate an effect of the synchronization problem on the one or more subscribed vehicle features. 9 . The system of claim 8 , wherein the one or more computing devices are further configured to notify the one or more subscribed vehicle features of the synchronization issue.

10. The system of claim 8, wherein the one or more computing devices are further configured to indicate the synchronization problem via a human machine interface (HMI) alert to be provided to a user of the vehicle.

11. The system of claim 8, wherein the input comprises one or more of: CV2X-PC5 message transmission / reception status as identified from the vehicle's transceiver; Status data indicating the CV2X-PC5 status of the vehicle; a Global Navigation Satellite System (GNSS) position of the vehicle as determined using a GNSS controller of the vehicle; a time uncertainty as identified from a CV2X-PC5 message sent by or received from the vehicle; a vehicle system clock of one or more controllers of the vehicle; Side Link Synchronization Signal (SLSS) messages received by the vehicle from one or more CV2X-PC5 Roadside Units (RSUs); sensor data from vehicle sensors; and / or Key Performance Indicator (KPI) data from the CV2X-PC5 message.

12. The system of claim 8, wherein the monitoring switches between a static rate or a dynamic rate based on one or more of SemiMajorAxisAccuracy accuracy, SemiMinorAxisAccuracy accuracy, and / or GNSSTimeConfidence.

13. The system of claim 8, wherein the regression estimation comprises providing an output indicating a time synchronization level and a confidence level at the level using a neural network trained based on the input indicating message timing of messages, wherein the level and confidence value are provided to the one or more subscribed vehicle features to allow the one or more subscribed vehicle features to be debugged based on the time synchronization level and the confidence level at the level.

14. The system of claim 8, wherein the potential time synchronization problem comprises the time synchronization having begun to drift closer to a maximum tolerance, but the time synchronization has not yet exceeded the maximum tolerance.

15. A non-transitory computer-readable medium comprising instructions for monitoring, detecting, estimating, and alerting a cellular vehicle-to-the-world (CV2X-PC5) operational status of a vehicle, the instructions, when executed by one or more computing devices of the vehicle, causing the vehicle to perform operations comprising: receiving, by the CV2X-PC5, input indicating message timing for messages for one or more subscribed vehicle features; monitoring time synchronization of received inputs; determining whether a synchronization problem is detected, including performing regression estimation for early prediction of potential time synchronization problems; and In response to the occurrence of the synchronization problem, an alternative wireless communication medium of the vehicle is utilized to mitigate an effect of the synchronization problem on the one or more subscribed vehicle features.

Images