Managing processing of basic security messages

Abstract

Various embodiments include methods and systems of an Internet of Vehicles (V2X) system of a vehicle for managing processing of basic security messages (BSMs). Various embodiments may include calculating a relevance value for a received BSM prior to performing a security process of the BSM; determining whether the relevancy value of the BSM meets a relevancy threshold; and in response to determining that the relevancy value of the BSM does not meet the relevancy threshold, stopping processing of the BSM.

Description

[0001] Related Applications

[0002] This application claims the benefit of priority to U.S. non-provisional application No. 17 / 804,108, filed on May 26, 2022; the entire contents of which are incorporated herein by reference. Background Art

[0003] Vehicle-to-everything (V2X) systems may employ protocols and messaging defined under relevant standards, such as Cellular Vehicle-to-everything (C-V2X), Dedicated Short Range Communications (DSRC), and ITS-G5. These standards are the foundation for vehicle-based wireless communications and may be used to support smart highways, autonomous and semi-autonomous vehicles, and improve the overall efficiency and safety of highway transportation systems. An element of a V2X communication system is the ability of vehicles to broadcast V2X messages that other vehicles may receive and process to improve traffic safety, such as Basic Safety Messages (BSM) or Collaborative Awareness Messages (CAM).

[0004] The V2X communication system can be configured to detect inaccurate or intentionally false information in a BSM or CAM received from another vehicle or from an Intelligent Transportation System (ITS) infrastructure device such as a roadside unit (RSU). However, processing a BSM or CAM to detect inaccurate or false information is computationally resource intensive. Unnecessarily processing a BSM or CAM that is not relevant to the safety or operation of the receiving vehicle consumes limited V2X computing resources. Summary of the invention

[0005] Various aspects include methods executable by a processor of a vehicle-to-everything (V2X) communication system for managing the processing of a basic safety message (BSM). Various aspects may include the V2X communication system processor performing the following operations: calculating a relevance value of a received BSM before performing safety processing of the BSM; determining whether the relevance value of the BSM satisfies a relevance threshold; and in response to determining that the relevance value of the BSM does not satisfy the relevance threshold, stopping processing of the BSM.

[0006] Some aspects may include, in response to determining that the relevance value of the BSM satisfies the relevance threshold, performing security processing of the BSM and performing an abnormal behavior detection operation on the BSM. In some aspects, performing security processing of the BSM may include performing cryptographic verification of the BSM. In some aspects, performing an abnormal behavior detection operation on the BSM may include performing semantic verification of the BSM.

[0007] In some aspects, calculating the relevance value of the received BSM may include calculating the relevance value based on the inverse of the collision time of the vehicle and the transmitter of the BSM. In some aspects, calculating the relevance value of the received BSM may include calculating the relevance value based on the relative speed of the vehicle and the transmitter of the BSM divided by the distance from the vehicle to the transmitter of the BSM. Some aspects may include determining the relevance threshold based on the processing capability of the V2X communication system and the maneuverability of the vehicle. Some aspects may include determining the relevance threshold based on the reaction time of the V2X communication system and / or the vehicle autonomous / semi-autonomous driving system and the braking time of the vehicle.

[0008] Additional aspects include a vehicle processing system including a memory and a processor configured to perform operations of any of the methods outlined above. Additional aspects may include a vehicle V2X communication system having various components for performing functions corresponding to any of the methods outlined above. Additional aspects may include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of the vehicle V2X communication system to perform various operations corresponding to any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description and detailed description given, serve to explain the features herein.

[0010] Figure 1A is a system block diagram illustrating an example communication system suitable for implementing various embodiments.

[0011] Figure 1B is a system block diagram illustrating an example decomposed base station architecture suitable for implementing any of the various embodiments.

[0012] Figure 1C is a system block diagram illustrating a communication system suitable for implementing various embodiments.

[0013] Figure 2A is a component diagram of an example vehicle V2X communication system suitable for implementing various embodiments.

[0014] Figure 2B is a component block diagram illustrating components of an example vehicle autonomous / semi-autonomous driving system V2X communication system suitable for implementing various embodiments.

[0015] Figure 3Ais a block diagram illustrating components of a system-on-chip for use in a vehicle V2X communication system according to various embodiments.

[0016] Figure 3B is a component block diagram illustrating elements of a vehicle V2X communication system configured in accordance with various embodiments.

[0017] Figure 4A is a process flow diagram of an example method performed by a processor of a vehicle V2X communication system for managing the transmission of abnormal behavior reports according to various embodiments.

[0018] Figure 4B is a process flow diagram of example operations that may be performed by a processor of a vehicle V2X communication system as part of a method for managing the transmission of abnormal behavior reports in accordance with various embodiments.

[0019] Figure 5 is a component block diagram of a computing device suitable for use with the various embodiments. DETAILED DESCRIPTION

[0020] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0021] Various embodiments include methods and processors for a vehicle V2X communication system for managing the processing of V2X messages such as basic safety messages (BSM) or cooperative awareness messages (CAM) (collectively referred to herein as "basic safety messages" or "BSM"), so that the V2X communication system selectively performs safety processing and abnormal behavior detection on the received BSM based on the relevance of the received BSM to reduce computing costs and resource consumption.

[0022] As used herein, the term “vehicle” generally refers to cars, motorcycles, trucks, buses, trains, boats, and any other type of vehicle V2X-capable system that may be configured to manage the transmission of abnormal behavior reports.

[0023] The term "system on chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources and / or processors integrated on a single substrate. A single SOC may contain circuits for digital, analog, mixed signal, and radio frequency functions. A single SOC may also include any number of general and / or special processors (digital signal processors, modem processors, video processors, etc.), storage blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SOC may also include software for controlling the integrated resources and processors and for controlling peripheral devices.

[0024] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuits and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high-speed communication and the sharing of memory and resources.

[0025] In V2X communication, the V2X communication system evaluates the received BSM by performing security processing (such as one or more cryptographic verification and / or authentication operations) and one or more abnormal behavior detection operations to determine whether the BSM is credible and reliable (e.g., semantic verification of the BSM, authentication operations, integrity determination operations, non-repudiation determination operations, etc.). The V2X communication system typically includes a V2X vehicle system, a roadside unit (RSU), a base station, and other participants in the V2X communication system, and the V2X communication volume may be large. Performing security processing and abnormal behavior detection may consume a large amount of computing resources of the receiving V2X communication system.

[0026] Various embodiments include a vehicle V2X communication receiving and processing system ("V2X communication system") configured to selectively perform security processing and abnormal behavior detection processing on BSMs received by the vehicle processing system based on whether the BSM is related to the vehicle. In various embodiments, the V2X communication system may determine whether the received BSM rises to a level of relevance or importance such that the V2X communication system should perform security processing, semantic verification, and abnormal behavior detection on the BSM. Technical standards for V2X communication systems generally require that security processing be performed on the received BSM, and then if the BSM passes the security processing operation, semantic confirmation and abnormal behavior detection are performed on the BSM. Various embodiments enable the V2X communication system to save processing resources that would otherwise be used to process BSMs that the V2X communication system determines are not related to the V2X communication system. In some embodiments, the V2X communication system may calculate the relevance value of the BSM before performing security processing and semantic verification of the received BSM, determine whether the relevance value of the BSM meets the relevance threshold, and in response to determining that the relevance value of the BSM does not meet the relevance threshold, stop processing of the BSM before performing security processing and semantic verification. In some embodiments, the V2X communication system may perform or execute security processing of the BSM and perform semantic verification and one or more abnormal behavior detection operations on the BSM in response to determining that the relevance value of the BSM meets the relevance threshold.

[0027] In some embodiments, performing security processing of the BSM may include, in response to determining that the relevance value of the BSM satisfies a relevance threshold, performing cryptographic verification of the BSM. For example, the BSM may include a digital signature or an authentication code. In some embodiments, the V2X communication system may perform semantic verification of the BSM. For example, the V2X communication system may, in response to determining that the relevance value of the BSM satisfies a relevance threshold, perform one or more operations to verify or validate the digital signature or authentication code of the BSM (e.g., perform semantic verification of the BSM).

[0028] In some embodiments, calculating the correlation value of the received BSM may include calculating the correlation value based on the inverse of the collision time of the vehicle and the transmitter of the BSM. In some embodiments, the V2X communication system may calculate the correlation value based on the relative speed of the vehicle and the transmitter of the BSM divided by the distance from the vehicle to the transmitter of the BSM. For example, the V2X communication system may express the correlation value as

[0029]

[0030] Wherein relativeSpeed ​​represents the relative speed of the transmitters of the receiving V2X communication system and the BSM, and distance represents the distance between the transmitters of the receiving V2X communication system and the BSM. In some embodiments, the V2X communication system may determine the speed of the transmitter of the BSM based on the value in the speed field of the received BSM. In some embodiments, the V2X communication system may determine the distance between the V2X receiver and the transmitter of the BSM based on the value in the positioning field of the received BSM and the location information of the V2X communication system (e.g., GPS information, base station triangulation information, location information from V2X infrastructure such as roadside units (RSUs), etc.). In some embodiments, the lower the relevance value, the less relevant the BSM is, and the less urgent the BSM is for the V2X communication system to process; conversely, the higher the relevance value, the more relevant the BSM is, and the more urgent the BSM is for the V2X communication system to process.

[0031] As described above, the V2X communication system may determine whether the relevance value of the BSM satisfies a relevance threshold. In some embodiments, the V2X communication system may determine the relevance threshold based on the processing capability of the V2X communication system and the maneuverability of the vehicle. For example, the V2X communication system may determine one or more metrics or values ​​representing processing speed, processing capability, computational throughput, or another suitable value representing the processing capability of the V2X communication system or the vehicle's autonomous / semi-autonomous processing system. The V2X communication system may also determine one or more metrics or values ​​representing the maneuverability of the vehicle, such as stopping distance, maximum achievable deceleration rate, maneuverability, speed of the vehicle, etc.

[0032] In some embodiments, the V2X communication system may also determine one or more values ​​based on traffic conditions or environmental conditions when determining the maneuverability of the vehicle. For example, the maximum achievable deceleration rate may depend on the braking ability of the vehicle and also on various environmental conditions (e.g., wet or icy roads may reduce the maximum achievable deceleration rate). As another example, heavy or congested traffic conditions may reduce the ability of the vehicle to brake or steer safely, thereby reducing the maneuverability of the vehicle.

[0033] In some embodiments, the V2X communication system may determine the relevance threshold based on the reaction time of the V2X communication system and the braking time of the vehicle. For example, the V2X communication system may express the relevance threshold as:

[0034]

[0035] Where α represents a correlation threshold, rt represents a value of a reaction time of the V2X communication system, bt represents a value of a braking time of the vehicle, and c represents a constant that may be greater than or equal to 1. The braking time may be the amount of time required for the vehicle to come to a complete stop. In some embodiments, the braking time may be the amount of time required for the vehicle to achieve a substantially zero relative velocity between the V2X communication system and the transmitter of the BSM. In some embodiments, the braking time may be the amount of time required for the vehicle to brake sufficiently to avoid a collision with the transmitter of the BSM.

[0036] Various embodiments may improve the operation of a V2X communication system in a vehicle by enabling the V2X communication system to dynamically determine whether to use limited computing resources to perform safety processing and / or one or more abnormal behavior detection operations on a BSM, thereby saving computing resources required to perform safety processing of BSMs that are of low or no relevance to the vehicle. Various embodiments enable the V2X communication system to save processing resources that would otherwise be used to process BSMs that the V2X communication system determines are not relevant to the V2X communication system.

[0037] Figure 1A 1 is a system block diagram illustrating an example communication system 100 suitable for implementing various embodiments. The communication system 100 includes a 5G New Radio (NR) network, an ITS V2X wireless network, and / or any other suitable network, such as a Long Term Evolution (LTE) network. References to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting.

[0038] The communication system 100 may include a heterogeneous network architecture including a core network 140, a plurality of base stations 110, and various mobile devices including a vehicle 102 equipped with a V2X communication system 104 including wireless communication capabilities. The base stations 110 may communicate with the core network 140 over a wired communication link 126. The communication system 100 may also include a roadside unit 112 that supports V2X communication with the vehicle 102 via the V2X wireless communication link 124.

[0039] The base station 110 is a network element that communicates with a wireless device (e.g., the V2X communication system 104 of the vehicle 102) via a wireless communication link 122, and may be referred to as a Node B, an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio head, a transmit receive point (TRP), a new radio base station (NR BS), a 5G Node B (NB), a next generation Node B (gNodeB or gNB), etc. Each base station 110 may provide communication coverage for a particular geographic area or "cell." In 3GPP, the term "cell" may refer to the coverage area of ​​a base station, a base station subsystem serving the coverage area, or a combination thereof, depending on the context in which the term is used. The core network 140 may be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, a reference Figure 1B Decomposed networks, etc.

[0040] The roadside unit 112 may communicate with the core network 140 via a wired or wireless communication link 128. The roadside unit 112 may communicate with a vehicle 102 equipped with a V2X communication system via a V2X wireless communication link 124 for downloading information useful for the V2X communication system autonomous and semi-autonomous driving functions, and for receiving information such as abnormal behavior reports from the V2X communication system 104.

[0041] An abnormal behavior authority network computing device (MA) 132 may communicate with the core network 140 via a wired or wireless communication link 127. The MA 132 may receive abnormal behavior reports from the V2X communication system 104, as may be transmitted by the V2X communication system 104 from time to time.

[0042] The wireless communication link 122 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. The wireless communication links 122 and 124 may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication links include: 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile phone communication technology cellular RATs. Other examples of RATs that may be used in one or more of the various wireless communication links within the communication system 100 include medium-range protocols (such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire) and relatively short-range RATs (such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE)).

[0043] Figure 1Bis a system block diagram illustrating an example decomposed base station 160 architecture that may be part of a V2X and / or 5G network suitable for communicating map data to a vehicle and communicating updated object / or feature locations in accordance with any of various embodiments. Figure 1A and Figure 1B , the decomposed base station 160 architecture may include one or more central units (CU) 162, which may communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more decomposed base station units (such as a near real-time (Near-RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time (Non-RT) RIC 168 associated with a service management and orchestration (SMO) framework 166, or both). The CU 162 may communicate with one or more distributed units (DU) 170 via corresponding midhaul links (such as an F1 interface). The DU 170 may communicate with one or more radio units (RU) 172 via corresponding fronthaul links. The RU 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, a user equipment (UE) such as a V2X communication system 104 may be served by multiple RUs 172 simultaneously.

[0044] Each of the units (i.e., CU 162, DU 170, RU 172), as well as near-RT RIC 164, non-RT RIC 168, and SMO framework 166 may include one or more interfaces, or be coupled to one or more interfaces configured to receive or send signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of the units or an associated processor or controller that provides instructions to the communication interface of these units may be configured to communicate with one or more of the other units via a transmission medium. For example, a unit may include a wired interface that is configured to receive or send signals to one or more of the other units via a wired transmission medium. Additionally, these units may include a wireless interface that may include a receiver, a transmitter, or a transceiver (such as a radio frequency (RF) transceiver) that is configured to receive or send signals or both to one or more of the other units on a wireless transmission medium.

[0045] In some aspects, CU 162 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented with an interface configured to communicate signals with other control functions hosted by CU 162. CU 162 may be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some specific implementations, CU 162 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (such as an E1 interface). As needed, CU 162 may be implemented to communicate with DU 170 for network control and signaling.

[0046] DU 170 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 172. In some aspects, DU 170 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) depending at least in part on a functional partitioning such as that defined by the 3rd Generation Partnership Project (3GPP). In some aspects, DU 170 may further host one or more low PHY layers. Each layer (or module) may be implemented using an interface that is configured to communicate signals with other layers (and modules) hosted by DU 170 or with control functions hosted by CU 162.

[0047] The lower layer functionality may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DUs 170 may correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transforms (FFTs), inverse FFTs (iFFTs), digital beamforming, physical random access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on functional splits (such as lower layer functional splits). In such an architecture, the RUs 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some specific implementations, real-time and non-real-time aspects of control and user plane communications with the RUs 172 may be controlled by the corresponding DUs 170. In some scenarios, this configuration may enable the DUs 170 and CUs 162 to be implemented in a cloud-based radio access network (RAN) architecture (such as a vRAN architecture).

[0048] The SMO framework 166 may be configured to support RAN deployment and configuration of non-virtualized network elements and virtualized network elements. For non-virtualized network elements, the SMO framework 166 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 166 may be configured to interact with a cloud computing platform (such as an open cloud (O-Cloud) 176) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, CU 162, DU 170, RU 172, and near-RT RIC 164. In some specific implementations, the SMO framework 166 may communicate with hardware aspects of the 4G RAN (such as an open eNB (O-eNB) 174) via the O1 interface. Additionally, in some specific implementations, the SMO framework 166 may communicate directly with one or more RUs 172 via the O1 interface. The SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166 .

[0049] The non-RT RIC 168 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 may be coupled to or in communication with the near-RT RIC 164 (such as via an A1 interface). The near-RT RIC 164 may be configured to include logic functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface (such as via an E2 interface) that connects one or more CUs 162, one or more DUs 170, or both, and the O-eNB with the near-RT RIC 164.

[0050] In some implementations, in order to generate an AI / ML model to be deployed in the near-RT RIC 164, the non-RT RIC 168 may receive parameters or external enrichment information from an external server. Such information may be utilized by the near-RT RIC 164 and may be received from a non-network data source or from a network function at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns for performance and employ AI / ML models to perform corrective actions through the SMO framework 166 (such as via reconfiguration of O1) or via creation of RAN management policies (such as A1 policies).

[0051] Figure 1C is a system block diagram illustrating a communication system 103 suitable for implementing various embodiments. Figures 1A to 1C, the communication system 103 may include three vehicles 12, 14, 16. Each vehicle 12, 14, 16 may include a V2X communication system 104, 106, 108, respectively, each of which is configured to periodically broadcast V2X messages such as basic safety messages 30, 40, 50 for reception and processing by the V2X communication systems (e.g., 104, 106, 108) of other vehicles. By sharing vehicle position, speed, direction, braking, and other information, vehicles can maintain safe separation and identify and avoid potential collisions. For example, a trailing vehicle 12 that receives a basic safety message 40 from a leading vehicle 16 can determine the speed and position of the vehicle 16, which in turn enables the vehicle 12 to match the speed and maintain a safe separation distance 20. By being notified by the basic safety message 40 when the leading vehicle 16 applies brakes, the V2X communication system 102 in the trailing vehicle 12 can also simultaneously apply brakes to maintain a safe separation distance 20 even when the leading vehicle 16 stops suddenly. As another example, a V2X communication system 104 within a truck vehicle 14 may receive basic safety messages 30, 50 from two vehicles 12, 16, and thus be notified that the truck vehicle 14 should stop at an intersection to avoid a collision. Each of the vehicle V2X onboard equipment 104, 106, 108 may communicate with each other using any of a variety of close proximity communication protocols. In addition, the vehicle may be able to send data and information about the detected basic safety messages and abnormal behavior reports about the detected V2X abnormal behavior to the original equipment manufacturer (OEM) (70, 72) and / or MA 74 (e.g., 132) via the communication network 18 via communication links 60, 61, 62. The abnormal behavior report may be sent directly to the MA 74 (e.g., via communication links 64, 66). In other embodiments, the abnormal behavior report may first be sent to an abnormal behavior report pre-processing unit (such as an OEM server 70, 72) via communication links 64, 66 for pre-processing. The pre-processed abnormal behavior report may then be sent from the abnormal behavior report pre-processing unit 70, 72 to the MA 74 via the communication link 64, 66. In other embodiments, the abnormal behavior report may be received at the MA 74 from a vehicle, such as from the vehicle 16. The MA 74 relays the received abnormal behavior report from the vehicle 16 to the OEM server 70, 72 via the communication link 64, 66. Additionally, the OEM server 70, 72 may provide a confirmation report to the MA 74 via the communication link 64, 66.

[0052] Figure 2A is a component diagram of an example communication system 200 suitable for implementing various embodiments. Figures 1A to 2A, the system 200 may include a vehicle 102 that includes a V2X communication system 104. The vehicle V2X communication system 104 may communicate with various systems and devices such as an onboard network 210, an infotainment system 212, various sensors 214, various actuators 216, and a radio module 218 coupled to an antenna 219. The vehicle V2X communication system 104 may also communicate with a roadside unit 112, a cellular communication network base station 110, and other external devices.

[0053] The vehicle V2X communication system 104 may include a processor 205, a memory 206, an input module 207, an output module 208, and a radio module 218. The processor 205 may be coupled to the memory 206 (i.e., a non-transitory storage medium) and may be configured with processor-executable instructions stored in the memory 206 to perform operations according to the methods of the various embodiments described herein. In addition, the processor 205 may be coupled to the output module 208 (which may control the vehicle-mounted display) and to the input module 207 to receive information from vehicle sensors and driver input.

[0054] The V2X communication system 104 may include a V2X antenna 219 coupled to a radio module 218, the antenna being configured to communicate with one or more ITS participants (e.g., stations), the roadside unit 112, and the base station 110 or another suitable network access point. The V2X antenna 219 and the radio module 218 may be configured to receive dynamic traffic flow characteristic information via vehicle-to-everything (V2X) communications. In various embodiments, the V2X communication system may receive information from a plurality of information sources, such as the on-board network 210, the infotainment system 212, the various sensors 214, the various actuators 216, and the radio module 218. The V2X communication system may be configured to use map data in addition to sensor data to perform autonomous or semi-autonomous driving functions, as further described below.

[0055] Examples of vehicle-mounted networks 210 include controller area networks (CAN), local interconnect networks (LIN), networks using the FlexRay protocol, media-oriented systems transport (MOST) networks, and automotive Ethernet networks. Examples of vehicle sensors 214 include location determination systems (such as global navigation satellite systems (GNSS) systems), cameras, radars, lidars, ultrasonic sensors, infrared sensors, and other suitable sensor devices and systems. Examples of vehicle actuators 216 include various physical control systems such as for steering, braking, engine operation, lights, direction signals, etc.

[0056] Figure 2B2 is a component block diagram illustrating components of an example vehicle autonomous / semi-autonomous driving system 220 that can be coupled to the V2X communication system 104 and is suitable for implementing various embodiments. The autonomous / semi-autonomous driving system 220 may include various subsystems, communication elements, computing elements, computing devices, or units that can be utilized within the vehicle 102. Figures 1A to 2A The various computing elements, computing devices, or units within the autonomous / semi-autonomous driving system 220 may be implemented within a system (i.e., a subsystem) of computing devices that communicate data and commands to each other via the vehicle-mounted network 210 (e.g., by Figure 2B In some implementations, various computing elements, computing devices, or units within the autonomous / semi-autonomous driving system 220 may be implemented within a single computing device, such as separate threads, processes, algorithms, or computing elements. Figure 2B Each subsystem / computing element illustrated in the 200 is also generally referred to herein as a "layer" within a computing "stack" that makes up the vehicle autonomous / semi-autonomous driving system 220. However, the use of the terms layer and stack when describing various embodiments is not intended to imply or require that the corresponding functionality be implemented within a single vehicle computing device, although this is a potential specific implementation embodiment. Instead, the use of the term "layer" is intended to include subsystems with independent processors, computing elements (e.g., threads, algorithms, subroutines, etc.) running in one or more computing devices, and combinations of subsystems and computing elements.

[0057] The autonomous / semi-autonomous driving system 220 may include a radar and / or lidar perception layer 222, a camera perception layer 224, a positioning engine layer 226, a map database 228, a map fusion and arbitration layer 230, a route planning layer 232, an operating mode evaluation layer 234, a sensor fusion and road world model (RWM) management layer 236, a motion planning and control layer 238, and a behavior planning and prediction layer 240. Layers 222 to 240 are merely examples of some of the layers in one example configuration of the autonomous / semi-autonomous driving system 220. In other configurations, other layers may be included, such as additional layers for other perception sensors (e.g., a lidar perception layer, etc.), additional layers for planning and / or control, additional layers for modeling, etc., and / or some of the layers 222 to 240 may be excluded from the autonomous / semi-autonomous driving system 220. Figure 2BAs illustrated by the arrows in , each of the layers 222 to 240 can exchange data, calculation results, and commands. In addition, the autonomous / semi-autonomous driving system 220 can receive and process data from sensors (e.g., radar, lidar, camera, inertial measurement unit (IMU), etc.), navigation information resources (e.g., global positioning system (GPS) receiver, IMU, etc.), vehicle networks (e.g., controller area network (CAN) bus), and databases in memory (e.g., digital map data). The autonomous / semi-autonomous driving system 220 can output vehicle control commands or signals to the autonomous driving system (ADS) vehicle control unit 242, which is a system, subsystem, or computing device that interfaces directly with the vehicle steering, throttle, and brake controls. Figure 2A The configuration of the autonomous / semi-autonomous driving system 220 and the ADS vehicle control unit 242 illustrated in FIG. 2 is merely an example configuration, and other configurations of the vehicle management system and other vehicle components may be used. As an example, Figure 2B The configuration of the autonomous / semi-autonomous driving system 220 and the ADS vehicle control unit 242 illustrated in FIG. 2 may be used in a vehicle configured for autonomous or semi-autonomous operation, while a different configuration may be used in a non-autonomous vehicle.

[0058] The radar and / or lidar perception layer 222 may receive data from one or more detection and ranging sensors, such as radar (e.g., 132) and / or lidar (e.g., 138), and process the data to identify and determine the location of other vehicles and objects in the vicinity of the vehicle 100. The radar perception layer 222 may include the use of neural network processing and artificial intelligence methods to identify objects and vehicles, and pass such information to the sensor fusion and RWM management layer 236.

[0059] The camera perception layer 224 may receive data from one or more cameras, such as cameras, and process the data to identify and determine the location of other vehicles and objects in the vicinity of the vehicle 100. The camera perception layer 224 may include the use of neural network processing and artificial intelligence methods to identify objects and vehicles, and pass such information to the sensor fusion and RWM management layer 236.

[0060] The positioning engine layer 226 may receive data from the radar and / or lidar sensing layer 222, the camera sensing layer 224, and various navigation information sources, and process the data and information to determine the location of the vehicle 100. The various navigation information sources may include, but are not limited to, GPS receivers, IMUs, and / or other sources and sensors connected via a CAN bus. The positioning engine layer 226 may also utilize input from one or more cameras, such as cameras and / or any other available sensors capable of identifying and determining the direction and distance to objects near the vehicle, such as radar, lidar, etc.

[0061] According to various embodiments, the autonomous / semi-autonomous driving system 220 may include or be coupled to the vehicle V2X communication system 104. One or more of the layers 222-240 may provide information to or receive information from the V2X communication system 104. The V2X communication system 104 may be configured to communicate with a highway communication system, such as via a V2X communication link (e.g., 124) and / or communicate with a remote information source (e.g., computing device 132) via a cellular wireless communication link (e.g., 122), such as via a 5G cellular network.

[0062] The map fusion and arbitration layer 230 may access the map database 228 to obtain location information about nearby objects and features, and receive positioning / navigation information output from the positioning engine layer 226, and process the data to further determine the location of the vehicle 102 in the map, such as the location within a lane, the location within a street map, etc. The sensor data may be stored in a memory (e.g., memory 312).

[0063] Similar to the location information in some map objects and features and sensor accuracy and precision, GPS positioning includes some errors, so the map fusion and arbitration layer 230 can be used to determine the best guess position of the vehicle within the road based on arbitration between GPS coordinates, sensor data, and map data regarding objects and features in and near the road. For example, although the GPS coordinates may place the vehicle near the middle of a two-lane road in the sensor data, the map fusion and arbitration layer 230 may determine that the vehicle is most likely aligned with a lane of travel that is consistent with the direction of travel based on the direction of travel. The map fusion and arbitration layer 230 can pass the arbitrated map position information to the sensor fusion and RWM management layer 236.

[0064] The route planning layer 232 may utilize sensor data and input from an operator or dispatcher to plan a route to be followed by the vehicle 102 to a particular destination. The route planning layer 232 may pass map-based location information to the sensor fusion and RWM management layer 236. However, other layers, such as the sensor fusion and RWM management layer 236, do not require the use of a priori maps. For example, other stacks may operate and / or control a vehicle based solely on sensory data without a provided map, building concepts of lanes, boundaries, and local maps as the sensory data is received.

[0065] In embodiments including an operating mode evaluation layer 234, the processing layer may use safety and / or confidence information about nearby objects and features to select an appropriate ADS driving mode. In some embodiments, the operating mode evaluation layer 234 may determine whether the current autonomous or semi-autonomous driving mode is consistent or appropriate with nearby objects and features in the driving environment in view of safety and / or confidence information about nearby objects and features in the driving environment.

[0066] The sensor fusion and RWM management layer 236 may receive data and outputs generated by the radar and / or lidar perception layer 222, the camera perception layer 224, the map fusion and arbitration layer 230, the route planning layer 232, and the operating mode evaluation layer 234, and use some or all of such inputs to estimate or refine the position and state of the vehicle 102 relative to the road, other vehicles on the road, and other objects in the vicinity of the vehicle 100. For example, the sensor fusion and RWM management layer 236 may combine image data from the camera perception layer 224 with arbitration map position information from the map fusion and arbitration layer 230 to refine the determined position of the vehicle within the traffic lane. As another example, the sensor fusion and RWM management layer 236 may combine object recognition and image data from the camera perception layer 224 with object detection and ranging data from the radar and / or lidar perception layer 222 to determine and refine the relative position of other vehicles and objects in the vicinity of the vehicle. As another example, the sensor fusion and RWM management layer 236 may receive information about the location and direction of travel of other vehicles from V2X communications (such as via a CAN bus) and combine this information with information from the radar and / or lidar perception layer 222 and the camera perception layer 224 to refine the location and motion of other vehicles. The sensor fusion and RWM management layer 236 may output the refined location and state information of the vehicle 100 and the refined location and state information of other vehicles and objects in the vicinity of the vehicle to the motion planning and control layer 238 and / or the behavior planning and prediction layer 240.

[0067] As a further example, the sensor fusion and RWM management layer 236 can use dynamic traffic control instructions to direct the vehicle 102 to change speed, lane, direction of travel, or other navigation elements, and combine this information with other received information to determine refined position and state information. The sensor fusion and RWM management layer 236 can output the refined position and state information of the vehicle 102 and the refined position and state information of other vehicles and objects in the vicinity of the vehicle 100 to the motion planning and control layer 238, the behavior planning and prediction layer 240, and / or devices remote from the vehicle 102, such as data servers, other vehicles, etc., via wireless communication (such as through a C-V2X connection, other wireless connections, etc.).

[0068] As yet a further example, the sensor fusion and RWM management layer 236 may monitor perception data from various sensors (such as perception data from the radar and / or lidar perception layer 222, the camera perception layer 224, other perception layers, etc.) and / or data from one or more sensors themselves to analyze conditions in the vehicle sensor data. The sensor fusion and RWM management layer 236 may be configured to detect conditions in the sensor data, such as sensor measurements being at, above, or below a threshold, certain types of sensor measurements occurring, etc., and may output the sensor data as part of refined position and state information of the vehicle 102 that is provided to the behavior planning and prediction layer 240 and / or devices remote from the vehicle 100 (such as data servers, other vehicles, etc.) via wireless communications (such as through a C-V2X connection, other wireless connections, etc.).

[0069] The behavior planning and prediction layer 240 of the autonomous vehicle V2X communication system 220 can use the refined position and state information of the vehicle 102 and the position and state information of other vehicles and objects output from the sensor fusion and RWM management layer 236 to predict the future behavior of other vehicles and / or objects. For example, the behavior planning and prediction layer 240 can use such information to predict the future relative positions of other vehicles based on the own vehicle position and speed and the positions and speeds of other vehicles in the vicinity of the vehicle. Such predictions can take into account information from map data and route planning to anticipate changes in relative vehicle positioning along the road as the host vehicle and other vehicles. The behavior planning and prediction layer 240 can output other vehicle and object behavior and position predictions to the motion planning and control layer 238. Additionally, the behavior planning and prediction layer 240 can use the object behavior in conjunction with the position prediction to plan and generate control signals for controlling the motion of the vehicle 102. For example, based on the route planning information, the refined position in the road information, and the relative position and movement of other vehicles, the behavior planning and prediction layer 240 may determine that the vehicle 102 needs to change lanes and accelerate, such as to maintain or achieve a minimum spacing with other vehicles and / or to prepare for a turn or exit. As a result, the behavior planning and prediction layer 240 may calculate or otherwise determine the steering angle of the wheels and the change to the throttle setting, which will be commanded to the motion planning and control layer 238 and the ADS vehicle control unit 242 along with various such parameters necessary to implement such lane changes and accelerations. One such parameter may be a calculated steering wheel command angle.

[0070] The motion planning and control layer 238 may receive data and information output from the sensor fusion and RWM management layer 236, map data from the map database 232, and other vehicle and object behavior and position predictions from the behavior planning and prediction layer 240, and use this information to plan and generate control signals for controlling the motion of the vehicle 102, and verify that such control signals meet the safety requirements of the vehicle 100. For example, based on the route planning information, the refined position in the road information, and the relative position and motion of other vehicles, the motion planning and control layer 238 may verify and pass various control commands or instructions to the ADS vehicle control unit 242.

[0071] The ADS vehicle control unit 242 may receive commands or instructions from the motion planning and control layer 238 and convert such information into mechanical control signals for controlling the wheel angles, brakes, and throttle of the vehicle 100. For example, the ADS vehicle control unit 242 may respond to a calculated steering wheel command angle by transmitting a corresponding control signal to a steering wheel controller.

[0072] In various embodiments, the V2X communication system 104 may communicate with other V2X communication system participants (e.g., other vehicles 12, 14, 16) via wireless communication links to send sensor data, positioning data, vehicle data, and data collected by onboard sensors about the vehicle's surroundings. Other V2X communication system participants may use such information to update stored sensor data for relay to other V2X communication system participants.

[0073] In various embodiments, the vehicle V2X communication system 220 may include functionality to perform safety checks or oversight of various commands, plans, or other decisions at various layers that may affect the safety of the vehicle and occupants. Such safety checks or oversight functionality may be implemented within a dedicated layer or distributed between various layers and included as part of the functionality. In some embodiments, various safety parameters may be stored in a memory, and the safety check or oversight functionality may compare the determined values ​​(e.g., relative spacing to nearby vehicles, distance to the centerline of the road, etc.) to the corresponding safety parameters and issue a warning or command if the safety parameters are violated or about to be violated. For example, a safety or supervisory function in the behavior planning and prediction layer 240 (or in a separate layer) may determine a current or future separation distance between another vehicle (as defined by the sensor fusion and RWM management layer 236) and the vehicle (e.g., based on a world model refined by the sensor fusion and RWM management layer 236), compare the separation distance to a safe separation distance parameter stored in memory, and issue a command to the motion planning and control layer 238 to accelerate, decelerate, or turn if the current or predicted separation distance violates the safe separation distance parameter. As another example, a safety or supervisory function in the motion planning and control layer 238 (or in a separate layer) may compare a determined or commanded steering wheel command angle to a safe wheel angle limit or parameter, and issue an override command and / or alarm in response to the commanded angle exceeding the safe wheel angle limit.

[0074] Some safety parameters stored in memory may be static (i.e., do not change over time), such as maximum vehicle speed. Other safety parameters stored in memory may be dynamic in that they are continuously or periodically determined or updated based on vehicle state information and / or environmental conditions. Non-limiting examples of safety parameters include: maximum safe speed, maximum brake pressure, maximum acceleration, and safe wheel angle limits, all of which may vary depending on road and weather conditions.

[0075] Figure 3Ais a block diagram illustrating example components of a system on a chip (SOC) 300 for use in a vehicle V2X processing system according to various embodiments. Figures 1A to 3A , the processing device SOC 300 may include several heterogeneous processors, such as a digital signal processor (DSP) 303, a modem processor 304, an image and object recognition processor 306, a mobile display processor 307, an application processor 308, and a resource and power management (RPM) processor 317. The processing device SOC 300 may also include one or more coprocessors 310 (e.g., a vector coprocessor) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, 317. Each of these processors may include one or more cores and an independent / internal clock. Each processor / core may perform operations independently of other processors / cores. For example, the processing device SOC 300 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows). In some embodiments, the application processor 308 may be the main processor, central processing unit (CPU), microprocessor unit (MPU), arithmetic logic unit (ALU), etc. of the SOC 300. Graphics processor 306 may be a graphics processing unit (GPU).

[0076] The processing device SOC 300 may include analog and custom circuits 314 for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as processing encoded audio and video signals for rendering in a web browser. The processing device SOC 300 may also include system components and resources 316, such as voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting processors and software clients (e.g., web browsers) running on the computing device.

[0077] The processing device SOC 300 may also include a dedicated circuit for camera actuation and management (CAM) 305, which includes, provides, controls and / or manages the operation of one or more cameras (e.g., main camera, web camera, 3D camera, etc.), video display data from camera firmware, image processing, video pre-processing, video front end (VFE), embedded JPEG, high-definition video codec, etc. The CAM 305 may be an independent processing unit and / or include an independent or internal clock.

[0078] In some embodiments, the image and object recognition processor 306 may be configured with processor executable instructions and / or specialized hardware configured to perform image processing and object recognition analysis involved in various embodiments. For example, the image and object recognition processor 306 may be configured to perform operations of processing images received from the camera via the CAM 305 to recognize and / or identify other vehicles, and otherwise perform the functions of the camera perception layer 224 as described. In some embodiments, the processor 306 may be configured to process radar or lidar data and perform the functions of the radar and / or lidar perception layer 222 as described.

[0079] System components and resources 316, analog and custom circuits 314, and / or CAM 305 may include circuits to interface with peripheral devices such as cameras, radars, lidar electronic displays, wireless communication devices, external memory chips, etc. Processors 303, 304, 306, 307, 308 may be interconnected to one or more memory elements 312, system components and resources 316, analog and custom circuits 314, CAM 305, and RPM processor 317 via interconnect / bus module 324, which may include a reconfigurable logic gate array and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by advanced interconnects, such as a high-performance network-on-chip (NoC).

[0080] The processing device SOC 300 may further include an input / output module (not illustrated) for communicating with resources external to the SOC, such as a clock 318 and a voltage regulator 320. Resources external to the SOC (e.g., clock 318, voltage regulator 320) may be shared by two or more internal SOC processors / cores (e.g., DSP 303, modem processor 304, graphics processor 306, application processor 308, etc.).

[0081] In some embodiments, the processing device SOC 300 may be included in a control unit (e.g., 140) for use in a vehicle (e.g., 100). The control unit may include a communication link for communicating with a telephone network (e.g., 180), the Internet, and / or a network server (e.g., 184), as described.

[0082] The processing device SOC 300 may also include additional hardware and / or software components suitable for collecting sensor data from sensors, including motion sensors (e.g., accelerometers and gyroscopes of an IMU), user interface elements (e.g., input buttons, touch screen displays, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., position, direction, motion, orientation, vibration, pressure, etc.), cameras, compasses, GPS receivers, communication circuits (e.g., WLAN, WiFi, etc.) and other well-known components of modern electronic devices.

[0083] Figure 3B is a component block diagram illustrating elements of a vehicle V2X communication system 104 configured according to various embodiments. Figures 1A to 3B , the V2X communication system 104 of a vehicle (e.g., 102) can be configured to communicate with a roadside unit 112, a cellular network base station 110 and / or one or more other vehicles 12, 14, 16.

[0084] The vehicle V2X communication system 104 may include one or more processors 205, memory 206, radio modules 218, and other components. The vehicle processing system 104 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to the processor 205.

[0085] The memory 206 may include a non-transitory storage medium that electronically stores information. The electronic storage medium of the memory 206 may include a system storage device provided integrally (i.e., substantially non-removable) with the vehicle processing system 104 and / or a removable storage device that is removably connected to the vehicle V2X communication system 104 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.) One or both. In various embodiments, the memory 206 may include one or more of a charge-based storage medium (e.g., EEPROM, RAM, etc.), a solid-state storage medium (e.g., a flash drive, etc.), an optically readable storage medium (e.g., an optical disk, etc.), a magnetically readable storage medium (e.g., a magnetic tape, a magnetic hard drive, a floppy disk drive, etc.), and / or other electronically readable storage media. The memory 206 may include one or more virtual storage resources (e.g., a cloud storage device, a virtual private network, and / or other virtual storage resources). The memory 206 may store software algorithms, information determined by the processor 205, information received from one or more other vehicles 12, 14, 16, information received from the roadside unit 112, information received from the base station 110, and / or other information that enables the vehicle-V2X communication system 104 to function as described herein.

[0086] The processor 205 may include one of a plurality of local processors that may be configured to provide information processing capabilities in the vehicle V2X communication system 104. As such, the processor 205 may include one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although the processor 205 is Figure 3B205 is shown as a single entity, but this is for illustrative purposes only. In some embodiments, processor 205 may include multiple processing units. These processing units may be physically located within the same device, or processor 205 may represent the processing functionality of multiple devices distributed within the vehicle and operating in coordination.

[0087] The vehicle V2X communication system 104 may be configured by machine-readable instructions 332, which may include one or more instruction modules. The instruction modules may include computer program modules. In various embodiments, the instruction modules may include one or more of a relevance calculation module 334, a relevance threshold module 336, a relevance determination module 338, a processing stop / continue module 340, a transmit / receive (TX / RX) module 342, a security processing module 344, an abnormal behavior detection module 346, and / or other modules.

[0088] The relevance calculation module 334 may be configured to calculate a relevance value of the received BSM before performing safety processing of the BSM. The relevance calculation module 334 may be configured to calculate the relevance value based on the inverse of the collision time between the vehicle and the transmitter of the BSM. The relevance calculation module 334 may be configured to calculate the relevance value based on the relative speed of the vehicle and the transmitter of the BSM divided by the distance from the vehicle to the transmitter of the BSM.

[0089] The relevance threshold module 336 may be configured to determine the relevance threshold based on the processing capability of the V2X communication system and the maneuverability of the vehicle. The relevance threshold module 336 may be configured to determine the relevance threshold based on the reaction time of the V2X communication system and / or the vehicle autonomous / semi-autonomous driving system and the braking time of the vehicle.

[0090] The relevance determination module 338 may be configured to determine whether the relevance value of the BSM satisfies a relevance threshold.

[0091] The processing stop / continue module 340 may be configured to stop processing of the BSM in response to determining that the relevance value of the BSM does not satisfy the relevance threshold. The processing stop / continue module 340 may be configured to perform security processing of the BSM and perform one or more abnormal behavior detection operations on the BSM in response to determining that the relevance value of the BSM satisfies the relevance threshold.

[0092] The TX / RX module 342 may be configured to control the operation of communication devices of the vehicle processing system, such as the radio module 218 .

[0093] The security processing module 344 may be configured to perform security processing of the BSM in response to determining that the relevance value of the BSM satisfies the relevance threshold. The security processing module 344 may be configured to perform cryptographic verification of the BSM in response to determining that the relevance value of the BSM satisfies the relevance threshold.

[0094] The abnormal behavior detection module 346 may be configured to perform abnormal behavior detection of the BSM in response to determining that the relevance value of the BSM satisfies the relevance threshold. The abnormal behavior detection module 346 may be configured to perform semantic validation of the BSM.

[0095] Processor 205 may be configured to execute modules 332 - 346 and / or other modules via software, hardware, firmware, some combination of software, hardware and / or firmware, and / or other mechanisms for configuring processing capabilities on processor 205 .

[0096] The description of the functionality provided by the different modules 332 to 346 is for illustrative purposes and is not intended to be limiting, as any of the modules 332 to 346 may provide more or less functionality than described. For example, one or more of the modules 332 to 346 may be eliminated, and some or all of their functionality may be provided by other modules of the modules 332 to 346. As another example, the processor 205 may be configured to execute one or more additional modules that may perform some or all of the functionality attributed below to one of the modules 332 to 346.

[0097] Figure 4A is a process flow diagram of an example method 400a performed by a processor of a vehicle V2X communication system for managing the transmission of abnormal behavior reports according to various embodiments. Figures 1A to 4A , method 400a can be performed by a processor of a V2X communication system (e.g., 205, 300) or other vehicle processor (e.g., 205, 220, 300), which can be implemented in hardware elements, software elements, or a combination of hardware elements and software elements (collectively referred to as "vehicle processor").

[0098] In block 402, the processor may calculate a relevance value for the received BSM prior to performing safety processing of the BSM. In some embodiments, calculating the relevance value for the received BSM may include calculating the relevance value based on a reciprocal of a collision time between the vehicle and a transmitter of the BSM. In some embodiments, calculating the relevance value for the received BSM may include calculating the relevance value based on a relative speed of the vehicle and the transmitter of the BSM divided by a distance from the vehicle to the transmitter of the BSM. The means for performing the operations of block 402 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing a relevance calculation module 334.

[0099] At block 404, the processor may determine whether the relevance value of the BSM satisfies a relevance threshold. In some embodiments, as part of the operations in block 404, the vehicle processor may determine the relevance threshold based on the processing capability of the V2X communication system, the autonomous / semi-autonomous driving system, and / or the maneuvering capability of the vehicle. In some embodiments, as part of the operations in block 404, the processor may determine the relevance threshold based on the reaction time of the V2X communication system, the autonomous / semi-autonomous driving system, and / or the braking time of the vehicle. The means for performing the operations of block 404 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the relevance determination module 338.

[0100] In block 406, in some embodiments, the processor may, in response to determining that the relevance value of the BSM does not satisfy the relevance threshold, stop processing of the BSM without performing security processing. By pausing processing of the BSM and, in some embodiments, deleting the BSM without performing security processing, the vehicle processor may avoid devoting processing resources and time required to verify and validate a BSM that has little relevance to the vehicle. Means for performing the operations of block 406 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the processing stop / continue module 340.

[0101] The vehicle processor may repeat the operations of blocks 402 through 406 from time to time, such as when the vehicle processor receives a new BSM from the transmitter of the BSM.

[0102] Figure 4B is a process flow diagram of example operations 400b that may be performed by a processor of a vehicle V2X communication system as part of a method 400a for managing the transmission of abnormal behavior reports in accordance with various embodiments. Figures 1A to 4BOperation 400b may be performed by a processor of a V2X communication system (e.g., 205, 300) or other vehicle processor (e.g., 104, 205, 220, 300), which may be implemented in hardware elements, software elements, or a combination of hardware elements and software elements (collectively referred to as a "vehicle processor").

[0103] In block 401 , the processor may receive a BSM from a transmitter of the BSM. Means for performing the operations of block 401 may include a processor (eg, 205 , 303 , 304 , 306 , 307 , 308 , 310 ) executing the TX / RX module 342 and the radio module 218 .

[0104] In block 402, the processor may calculate a relevance value for a received BSM prior to performing security processing of the BSM, as described.

[0105] In determination block 404, the processor may determine whether the relevance value of the BSM satisfies a relevance threshold, as described. Means for performing the operations of block 404 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing relevance determination module 338.

[0106] In response to determining that the relevance value of the BSM does not satisfy the relevance threshold (ie, determination block 404 = "No"), the vehicle processor may stop processing of the BSM in block 406 without performing safety processing, as described.

[0107] In response to determining that the relevance value of the BSM satisfies the relevance threshold (i.e., determination block 404 = "Yes"), the processor may perform security processing on the BSM in block 408. In some embodiments, the security processing may include performing cryptographic verification of the BSM. The means for performing the operations of block 408 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the security processing module 344.

[0108] In determination block 410 , the processor may determine whether the BSM passes the security process. Means for performing the operations of determination block 410 may include a processor (eg, 205 , 303 , 304 , 306 , 307 , 308 , 310 ) executing the security process module 344 .

[0109] In response to determining that the BSM has not passed the safety process (i.e., determination block 410 = "No"), the processor may stop processing the BSM in block 416. Means for performing the operations of block 416 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the process stop / continue module 340.

[0110] In response to determining that the BSM passes the security process (i.e., determination block 410 = "Yes"), the processor may perform abnormal behavior detection on the BSM in block 412. The means for performing the operations of block 412 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the abnormal behavior detection module 346.

[0111] In determination block 414, the processor may determine whether abnormal behavior is detected in the BSM. Means for performing the operations of determination block 414 may include a processor (eg, 205, 303, 304, 306, 307, 308, 310) executing the abnormal behavior detection module 346.

[0112] In response to determining that abnormal behavior is detected in the BSM (i.e., determination block 414 = "Yes"), the processor may stop processing the BSM in block 416. Means for performing the operations of block 416 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the processing stop / continue module 340.

[0113] In response to determining that abnormal behavior is not detected in the BSM (i.e., determination block 414 = "No"), the processor may communicate the BSM to the relevant V2X application in block 418. The V2X application may use the information in the BSM to perform various vehicle operations. The means for performing the operations of block 418 may include a processor (205, 303, 304, 306, 307, 308, 310).

[0114] The vehicle processor may repeat the operations of blocks 401 through 418 from time to time, such as when the processor receives a new BSM from the transmitter of the BSM.

[0115] Figure 5 is a component block diagram of a network computing device 500 suitable for use in various embodiments. Figures 1A to 5 , various embodiments (including but not limited to the embodiments described with reference to FIG. 6A to FIG. 6E ) may be implemented on a variety of computing devices, examples of which are Figure 5500 is illustrated in the form of a server device. The network computing device 500 may include a processor 501 coupled to a volatile memory 502 and a large capacity non-volatile memory (such as a disk drive 503). The network computing device 500 may also include a peripheral memory access device coupled to the processor 501, such as a floppy disk drive, a compact disk (CD) or a digital video disk (DVD) drive 506. The network computing device 500 may also include a network access port 504 (or interface) coupled to the processor 501 for establishing a data connection with a network (such as the Internet and / or a local area network coupled to other system computers and servers). The network computing device 500 may include one or more transceivers 505 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless communication link. The network computing device 500 may include additional access ports for coupling to peripheral devices, external memory or other devices, such as USB, FireWire, Thunderbolt, etc.

[0116] Each specific implementation example is described in the following paragraphs. Although some of the examples in the following specific implementation examples are described according to the example methods, other example implementations may include: the example method discussed in the following paragraphs implemented by a V2X communication system that may be an onboard unit, a mobile device unit, or a mobile computing unit, the V2X communication system including a processor configured with processor-executable instructions to perform the operations of the method of the following specific implementation example; the example method discussed in the following paragraphs implemented by a vehicle V2X communication system including a component for performing the functions of the method of the following specific implementation example; and the example method discussed in the following paragraphs may be implemented as a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, which are configured to cause the processor of the V2X communication system to perform the operations of the method of the following specific implementation scheme.

[0117] Embodiment 1. A method for managing the processing of basic safety messages (BSM) executed by a processor of a vehicle-to-everything (V2X) communication system of a vehicle, the method comprising: calculating a relevance value of a received BSM before performing safety processing of the BSM; determining whether the relevance value of the BSM satisfies a relevance threshold; and in response to determining that the relevance value of the BSM does not satisfy the relevance threshold, stopping the processing of the BSM without performing safety processing.

[0118] Embodiment 2. According to the method of embodiment 1, the method also includes, in response to determining that the relevance value of the BSM satisfies the relevance threshold, performing security processing of the BSM and performing abnormal behavior detection operations on the BSM.

[0119] Embodiment 3. The method according to embodiment 2, wherein performing security processing of the BSM includes performing cryptographic verification of the BSM.

[0120] Embodiment 4. The method according to embodiment 2, wherein performing an abnormal behavior detection operation on the BSM includes performing semantic verification of the BSM.

[0121] Embodiment 5. The method of any one of embodiments 1 to 4, wherein calculating the relevance value of the received BSM comprises calculating the relevance value based on a reciprocal of a collision time between the vehicle and a transmitter of the BSM.

[0122] Embodiment 6. A method according to any one of embodiments 1 to 5, wherein calculating the relevance value of the received BSM includes calculating the relevance value based on the relative speed of the vehicle and the transmitter of the BSM divided by the distance from the vehicle to the transmitter of the BSM.

[0123] Embodiment 7. The method according to any one of embodiments 1 to 6 further comprises determining the relevance threshold based on a processing capability of the V2X communication system and a maneuverability capability of the vehicle.

[0124] Embodiment 8. The method according to any one of embodiments 1 to 7 further comprises determining the relevance threshold based on a reaction time of the V2X communication system or an autonomous or semi-autonomous driving system and a braking time of the vehicle.

[0125] The various embodiments illustrated and described are provided merely as examples of the various features described in the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment, and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one exemplary embodiment. For example, one or more operations of the method may replace or be combined with one or more operations of the method.

[0126] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are only used to guide the reader through the description of the method. In addition, any reference to a claim element in singular form (e.g., a reference using the article "a," "an," or "the") should not be interpreted as limiting the element to the singular.

[0127] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. Although the technician may implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as departing from the scope of the claims.

[0128] The hardware for implementing the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed with a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Although a general purpose processor may be a microprocessor, in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.

[0129] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or codes on a non-transient computer-readable medium or a non-transient processor-readable medium. The operation of the method or algorithm disclosed herein may be embodied in a processor-executable software module, which may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and not limitation, such non-transient computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, disk storage or other magnetic storage device, or any other medium that can be used to store the desired program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical disks reproduce data optically with lasers. The above combination is also included within the scope of non-transient computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0130] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but should be accorded the broadest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for managing the processing of basic safety messages (BSM) by a processor of a vehicle-to-everything (V2X) system of a vehicle, the method include: Calculating a relevance value of a received BSM before performing security processing of the BSM; determining whether the relevance value of the BSM satisfies a relevance threshold; as well as In response to determining that the relevance value of the BSM does not satisfy the relevance threshold, processing of the BSM is stopped without performing security processing.

2. The method of claim 1, further comprising, in response to determining that the relevance value of the BSM satisfies the relevance threshold, performing security processing of the BSM and performing an abnormal behavior detection operation on the BSM. The method of claim 2 , wherein performing security processing of the BSM comprises performing cryptographic authentication of the BSM. 4 . The method of claim 2 , wherein performing an abnormal behavior detection operation on the BSM comprises performing a semantic verification of the BSM. 5 . The method of claim 1 , wherein calculating a relevance value of the received BSM comprises calculating the relevance value based on an inverse of a collision time between the vehicle and a transmitter of the BSM.

6. The method of claim 1, wherein calculating a relevance value for the received BSM comprises calculating the relevance value based on a relative speed of the vehicle and a transmitter of the BSM divided by a distance from the vehicle to the transmitter of the BSM. 7 . The method of claim 1 , further comprising determining the relevance threshold based on a processing capability of the V2X communication system and a maneuverability of the vehicle. 8 . The method of claim 1 , further comprising determining the correlation threshold based on a reaction time of the V2X communication system and a braking time of the vehicle.

9. A vehicle-to-everything (V2X) communication system for a vehicle, the vehicle-to-everything (V2X) communication system include: A processor configured with processor-executable instructions to: Calculating a relevance value of a received BSM before performing security processing of the BSM; determining whether the relevance value of the BSM satisfies a relevance threshold; as well as In response to determining that the relevance value of the BSM does not satisfy the relevance threshold, processing of the BSM is stopped without performing security processing.

10. The V2X communication system of claim 9, wherein the processor is further configured with processor-executable instructions to, in response to determining that the relevance value of the BSM satisfies the relevance threshold, perform safety processing of the BSM and perform abnormal behavior detection operations on the BSM.

11. The V2X communication system of claim 10, wherein the processor is further configured with processor-executable instructions to perform cryptographic verification of the BSM.

12. The V2X communication system of claim 10, wherein the processor is further configured with processor-executable instructions to perform semantic verification of the BSM.

13. The V2X communication system of claim 9, wherein the processor is further configured with processor-executable instructions to calculate the correlation value based on a reciprocal of a collision time between the vehicle and a transmitter of the BSM.

14. The V2X communication system of claim 9, wherein the processor is further configured with processor-executable instructions to calculate the correlation value based on a relative speed of the vehicle and the transmitter of the BSM divided by a distance from the vehicle to the transmitter of the BSM.

15. The V2X communication system of claim 9, wherein the processor is further configured with processor-executable instructions to determine the relevance threshold based on a processing capability of the V2X communication system and a maneuvering capability of the vehicle.

16. The V2X communication system of claim 9, wherein the processor is further configured with processor-executable instructions to determine the correlation threshold based on a reaction time of the V2X communication system and a braking time of the vehicle.

17. A vehicle-to-everything (V2X) system for a vehicle, the vehicle-to-everything (V2X) system include: means for calculating a relevance value of a received BSM prior to secure processing of the BSM; means for determining whether the relevance value of the BSM satisfies a relevance threshold; and Means for stopping processing of the BSM without performing security processing in response to determining that the relevance value of the BSM does not satisfy the relevance threshold.

18. The V2X communication system of claim 17, further comprising means for performing safety processing of the BSM and performing an abnormal behavior detection operation on the BSM in response to determining that the relevance value of the BSM satisfies the relevance threshold.

19. The V2X communication system of claim 18, wherein the means for performing security processing of the BSM comprises means for performing cryptographic authentication of the BSM.

20. The V2X communication system of claim 18, wherein the means for performing an abnormal behavior detection operation on the BSM comprises means for performing semantic verification of the BSM.

21. The V2X communication system of claim 17, wherein the means for calculating a correlation value of the received BSM comprises means for calculating the correlation value based on a reciprocal of a collision time between the vehicle and a transmitter of the BSM.

22. The V2X communication system of claim 17, wherein the means for calculating a relevance value for the received BSM comprises means for calculating the relevance value based on a relative speed of the vehicle and the transmitter of the BSM divided by a distance from the vehicle to the transmitter of the BSM.

23. The V2X communication system of claim 17, further comprising means for determining the relevance threshold based on a processing capability of the V2X communication system and a maneuverability of the vehicle.

24. The V2X communication system of claim 17, further comprising means for determining the correlation threshold based on a reaction time of the V2X communication system and a braking time of the vehicle.

25. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a processor of a vehicle-to-everything (V2X) communication system of a vehicle to perform an operation, the operation include: Calculating a relevance value of a received BSM before performing security processing of the BSM; determining whether the relevance value of the BSM satisfies a relevance threshold; as well as In response to determining that the relevance value of the BSM does not satisfy the relevance threshold, processing of the BSM is stopped without performing security processing.

26. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processor of the V2X communication system to perform operations, the operations further comprising, in response to determining that the relevance value of the BSM satisfies the relevance threshold, performing safety processing of the BSM and performing abnormal behavior detection operations on the BSM.

27. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processor of the V2X communication system to perform operations such that calculating the correlation value of the received BSM includes calculating the correlation value based on a reciprocal of a collision time between a vehicle including the V2X communication system and a transmitter of the BSM.

28. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processor of the V2X communication system to perform operations such that calculating the relevance value of the received BSM comprises calculating the relevance value based on a relative speed of a vehicle including the V2X communication system and a transmitter of the BSM divided by a distance from the vehicle to the transmitter of the BSM.

29. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processor of the V2X communication system to perform operations, the operations further comprising determining the relevance threshold based on a processing capability of the V2X communication system and a maneuverability capability of the vehicle.

30. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processor of the V2X communication system to perform operations further comprising determining the relevance threshold based on a reaction time of the V2X communication system and a braking time of the vehicle.

Images