Inappropriate behavior detection in vehicle-to-vehicle everything (V2X) maneuver coordination messages

Abstract

Various embodiments include methods and systems for identifying improper behavior detection in vehicle-on-vehicle (V2X) maneuver coordination messages. Various embodiments may include a V2X system of a vehicle that receives a maneuver coordination message, performs an inappropriate behavior test on the maneuver coordination message, and takes an action in response to the test identifying an inappropriate behavior associated with the maneuver coordination message. Various embodiments may include a network computing device of a V2X network that receives a plurality of maneuver coordination messages from a plurality of vehicles, identifies an inconsistency between the plurality of maneuver coordination messages, identifies an inappropriate behavior condition in response to identifying the inconsistency between the plurality of maneuver coordination messages, and takes an action in response to identifying the inappropriate behavior condition.

Description

[0001] Related applications

[0002] This application claims the benefit of priority to U.S. Non-Provisional Application No. 17 / 810,680, filed on July 5, 2022; the entire contents of which are incorporated herein by reference. Background Art

[0003] The vehicle-to-everything (V2X) system supports vehicle-to-vehicle and vehicle-to-highway system communications based on the communication protocols and message formats defined by relevant standards such as Cellular Vehicle-to-Everything (C-V2X), Dedicated Short-Range Communications (DSRC), and ITS-G5. These standards are the basis for vehicle-based wireless communications and can be used to support smart highways, autonomous and semi-autonomous vehicles, and improve the overall efficiency and safety of road transportation systems.

[0004] An element of the V2X processing system is the ability of vehicles to broadcast V2X messages that other vehicles can receive and process to improve traffic safety, such as Basic Safety Messages (BSMs) and Collaborative Awareness Messages (CAMs). Another such V2X message that enables vehicles to broadcast information about planned maneuvers is a Maneuver Coordination Message (MCM), such as a Maneuver Shared Coordination Message. MCM messages can be used in V2X systems and with autonomous and semi-autonomous vehicles to avoid collisions and otherwise perform safe path planning. Summary of the invention

[0005] Aspects include methods for misbehavior detection in a motorized coordination message that can be performed by a vehicle-to-everything (V2X) vehicle processing system. Aspects receive a first motorized coordination message, perform a misbehavior test on the first motorized coordination message, and the test takes action in response to identifying misbehavior associated with the first motorized coordination message.

[0006] In some aspects, receiving a first motorized coordination message may include receiving the first motorized coordination message including a first field and a second field, and performing a misbehavior test on the first motorized coordination message, and taking action in response to the test identifying misbehavior associated with the first motorized coordination message may include sending a message associated with the received first motorized coordination message that includes an indication that information in the first field is inconsistent with information in the second field.

[0007] In some aspects, performing a misbehavior test on a first mobile coordination message may include determining whether first information in one or more first fields of the first mobile coordination message is inconsistent with second information in one or more second fields of the first mobile coordination message, and determining that a misbehavior condition exists in the first mobile coordination message in response to determining that the first information in one or more first fields of the first mobile coordination message is inconsistent with the second information in one or more second fields of the first mobile coordination message.

[0008] In some aspects, performing the misbehavior test on the first motorized coordination message may include determining whether information in the first motorized coordination message type field is inconsistent with the presence or absence of one or more second fields.

[0009] In some aspects, performing the misbehavior test on the first maneuver coordination message may include determining whether information in a target road resource (TRR) location field is inconsistent with the message in a TRR type field.

[0010] In some aspects, performing the misbehavior test on the first motor coordination message may include determining whether information in a performer identifier (ID) field is inconsistent with information in a source ID field or information in a destination ID field.

[0011] In some aspects, performing the misbehavior test on the first maneuver coordination message may include determining whether information in the maximum speed field is inconsistent with the TRR position field.

[0012] In some aspects, performing the misbehavior test on the first maneuver coordination message may include determining whether first information in one or more fields related to a scheduled maneuver of the vehicle is inconsistent with second information in one or more second fields related to the scheduled maneuver of the vehicle.

[0013] In some aspects, performing the misbehavior test on the first maneuver coordination message may include determining whether first information in one or more fields related to a scheduled maneuver of the vehicle or second information in one or more second fields related to a scheduled maneuver of the vehicle exceeds a threshold.

[0014] In some aspects, performing the misbehavior test on the first maneuver coordination message may include determining whether first information in one or more fields related to a scheduled maneuver of the vehicle or second information in one or more second fields related to a scheduled maneuver of the vehicle indicates an overlap of the TRRs.

[0015] Some aspects may also include receiving a second motorized coordination message, determining whether first information in the first motorized coordination message is inconsistent with second information in the second motorized coordination message, and identifying a misbehavior condition in response to determining that the first information in the first motorized coordination message is inconsistent with the second information in the second motorized coordination message. In some aspects, the first motorized coordination message and the second motorized coordination message may be out of sequence.

[0016] In some aspects, performing a misbehavior test on the first maneuver coordination message can include determining a number of maneuver request rejections received from the remote vehicle associated with one or more requests to perform a maneuver sent by the vehicle to the remote vehicle, and identifying a misbehavior condition in response to determining that the number of maneuver request rejections satisfies a request rejection threshold. Some aspects can also include starting a timer associated with the one or more requests to perform a maneuver sent to the remote vehicle, and increasing the number of maneuver request rejections upon expiration of the timer without receiving a response to the one or more requests from the remote vehicle.

[0017] Some aspects may also include determining whether the remote vehicle is unable to respond to one or more requests to perform a maneuver, and determining whether the remote vehicle is unable to perform operations associated with one or more requests to perform a maneuver, wherein identifying the misbehavior condition in response to determining that a number of maneuver request rejections satisfy a request rejection threshold may include identifying the misbehavior condition in response to determining that the remote vehicle is able to respond to one or more requests to perform a maneuver, and that the remote vehicle is able to perform operations associated with one or more requests to perform a maneuver.

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

[0019] Further aspects include a method for misbehavior detection in maneuver coordination messages performed by a network computing device processing system of a V2X network. Such aspects may include receiving a plurality of misbehavior reports indicating maneuver coordination message misbehavior from a plurality of vehicles, identifying inconsistencies between the plurality of misbehavior reports, identifying a misbehavior condition in response to identifying the inconsistencies between the plurality of misbehavior reports, and taking action in response to identifying the misbehavior condition.

[0020] In some aspects, identifying inconsistencies between the plurality of misconduct reports may include identifying a vehicle that impersonated the plurality of vehicles. In some aspects, identifying inconsistencies between the plurality of misconduct reports may include identifying that a vehicle identified in the plurality of maneuver coordination messages did not send a misconduct report to the network computing device. Some aspects may also include sending a request to a second network computing device for information related to the identified inconsistencies between the plurality of misconduct reports.

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

[0022] 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 herein, serve to explain the features herein.

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

[0024] Figure 1B is a system block diagram illustrating an example non-aggregated base station architecture suitable for implementing various embodiments.

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

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

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

[0028] Figure 3A is a block diagram illustrating components of a system on a chip used in a vehicle V2X processing system according to various embodiments.

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

[0030] Figure 3Cis a component block diagram illustrating elements of a processing system of a network computing device configured in accordance with various embodiments.

[0031] Figure 4A is a block diagram illustrating elements of a motor coordination message suitable for implementing various embodiments.

[0032] Figure 4B is a block flow diagram illustrating a basic MCM protocol 460 suitable for implementing various embodiments.

[0033] Figure 4C is a block diagram illustrating an emergency MCM protocol 470 suitable for implementing various embodiments.

[0034] Figure 4D is a message flow diagram illustrating an example of vehicle positions and messages exchanged during a lane change maneuver facilitated by a maneuver coordination message.

[0035] Figure 5A is a process flow diagram of an example method for misbehavior detection in maneuver coordination messages performed by a processor of a V2X processing system in a vehicle in accordance with various embodiments.

[0036] Figures 5B to 5G is a process flow diagram of example operations that may be performed by a processor of a vehicle V2X processing system as part of a method for misbehavior detection in maneuver coordination messages in accordance with various embodiments.

[0037] Figure 6 is a process flow diagram of an example method 600 for misbehavior detection in maneuver coordination messages performed by a processor of a network computing device processing system of a V2X network in accordance with various embodiments.

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

[0039] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever 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.

[0040] Various embodiments include methods, vehicle processing systems, and network computing device processing systems for misbehavior detection in maneuver coordination messages (MCMs). In various embodiments, the V2X processing system may include one or more processors and / or other components configured to perform various operations for misbehavior detection in MCMs. In various embodiments, the V2X processing system of a vehicle may perform a misbehavior test on a received MCM, and may take action in response to the test identifying misbehavior associated with the MCM. In various embodiments, the processing system of a V2X network computing device may receive multiple MCMs from multiple vehicles and process the MCMs to identify inconsistencies between the multiple MCMs. The processing system of the V2X network computing device may identify a misbehavior condition in response to identifying inconsistencies between the multiple MCMs, and may take action in response to identifying the misbehavior condition.

[0041] As used herein, the term “vehicle” generally refers to any of a car, motorcycle, truck, bus, train, boat, and any other type of vehicle V2X-enabled system that may be configured to manage the transmission of misbehavior reports.

[0042] The term "system on a 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.

[0043] 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 wafers are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor wafers are packaged into a unified substrate. A SIP may also include multiple independent SOCs that are coupled together and tightly packaged via high-speed communication circuits, 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.

[0044] In V2X communication, a V2X processing system in a vehicle may be configured to send and receive maneuver coordination messages (MCMs). MCMs are a type of V2X message configured to enable a vehicle to send information about a vehicle's scheduled maneuver or maneuver status to other vehicles and / or network elements of a V2X network (such as a server, base station, roadside unit (RSU), or another participant in a V2X communication network). MCMs may be configured according to a technical standard, such as a maneuver sharing coordination service (MSCS) or another applicable technical standard, and may be sent, received, and / or exchanged according to an applicable communication protocol (e.g., a V2X communication protocol). A vehicle referred to herein as a "host vehicle" (HV) may participate in a maneuver negotiation (e.g., a handshake operation) and send, receive, and / or exchange MCMs with one or more other vehicles referred to herein as "remote vehicles" (RVs). The exchange of MCMs may indicate a scheduled maneuver of the host vehicle and / or request a maneuver by a remote vehicle. The remote vehicle may respond to a received MCM with an MCM indicating approval or rejection of the host vehicle's execution of a scheduled maneuver and / or agreement or refusal to execute a maneuver requested by the host vehicle.

[0045] Current V2X processing systems can be configured to detect inaccurate or intentionally false information in a BSM or CAM received from another vehicle or an Intelligent Transportation System (ITS) infrastructure device such as a Roadside Unit (RSU). Misbehavior detected in such messages can be communicated to other vehicles and network systems in a Misbehavior Report Message (MBR).

[0046] However, the misbehavior detection methods implemented in current V2X processing systems cannot detect misbehavior in MCM. Expected messages or specified message sequences in the MCM protocol may provide attack points by malicious actors who attempt to interrupt or disable safe vehicle operations. Information included in MCM message fields may provide another attack point for MCM misbehavior. Misbehavior attacks in MCM may target fields that are specifically used for MCM, and in some cases may be dedicated to MCM. Such misbehavior in MCM may include inaccurate or false information about vehicle scheduled maneuvers, attacks on the MCM handshake process, and / or interference with another vehicle's scheduled maneuvers, such as repeatedly rejecting another vehicle's requested maneuvers or declared scheduled maneuvers. Misbehavior in MCM may cause the system that implements maneuver coordination to be degraded or disabled, reduce the safety and efficiency of traffic management, and may reduce the allowed level of autonomous driving of the autonomous vehicle (such as Level 3 (conditional automation), Level 4 (high automation), or Level 5 (full automation) of driving automation defined by the Society of Automotive Engineers (SAE)).

[0047] The MCM protocol typically specifies a message sequence, such as a sequence of allowed or expected MCM message types (which may be indicated in a field of the MCM). In some embodiments, the MCM protocol may include an emergency protocol that may be used by emergency vehicles (e.g., police, fire, paramedics, and other emergency response vehicles) in addition to the base protocol used by most vehicles. The V2X processing system may identify the emergency vehicle via a V2X digital certificate associated with the received MCM and identify the sending vehicle as an emergency vehicle.

[0048] The MCM may include one or more information fields that may be used by other V2X messages (such as vehicle kinematics information, which may also be included in the BSM and CAM), as well as one or more information fields that are specific to the MCM (such as maneuver data). For example, the MCM may include an MCM type field, a reason code field, a maneuver execution status field, one or more fields including information about a target road resource ("TRR"), and / or the like that are typically used only in the MCM. The information in the MCM type field may indicate the communication status between the host vehicle and the remote vehicle, such as "maneuver initiation", "request", "response", and "cancel".

[0049] The information in the MCM Type field may enable the V2X processing system to configure an MCM with one or more optional fields. For example, an MCM Type field having a value of 7 may enable the use of a Maneuver Execution Status field in the MCM. As another example, an MCM Type field having a value of 0, 1, 3, or 6 may enable the use of a Maneuver field in the MCM. As another example, an MCM Type field having a value of 2, 4, or 5 may enable the use of a Reason Code field in the MCM. The MCM may be sent to another vehicle and / or network device, may be broadcast (e.g., MCM broadcast), and / or may be sent to a specified group of vehicles and / or network devices (e.g., MCM multicast).

[0050] The information in the MCM may enable the vehicle to perform a handshake operation or maneuver negotiation for a maneuver proposed by the host vehicle or a request by the host vehicle to perform a maneuver to another remote vehicle. In addition to information about the proposed or requested maneuver, the MCM may also indicate a reason for the acceptance or proposal. For example, the V2X processing system may include information in a reason code field indicating a reason for a scheduled maneuver, for aborting a scheduled maneuver, or for denying a request by another vehicle to perform or allow a maneuver (a request by a remote vehicle to the host vehicle). For example, a reason code may indicate that the vehicle cannot comply (reason code 0), the requested maneuver is not required (reason code 1), the receiving vehicle cannot understand the request (reason code 2), the vehicle has detected an erroneous behavior (reason code 3), the vehicle is canceling the remote vehicle's maneuver (reason code 4), and / or the like. Currently, reason code 3 (erroneous behavior detected) cannot distinguish between erroneous behavior detected due to a malfunctioning vehicle component, or erroneous behavior detected due to a V2X misbehavior attack.

[0051] The MCM cause code or other appropriate information in the MCM indicating a detected misbehavior attack may cause the vehicle V2X processing system to send a misbehavior report to a network computing device such as a misbehavior authority. In addition, indicating that one or more MCMs include a cause code indicating a detected misbehavior attack may cause the misbehavior authority or other appropriate network computing device to perform additional processing or analysis on the misbehavior reports received from one or more vehicles, and / or perform remedial or corrective actions on the detected aggressor vehicle.

[0052] A malicious actor or entity may introduce misbehavior in an MCM in a variety of ways. In a first type of attack, a malicious actor may send MCMs with overlapping sub-maneuvers to simulate a false road accident and thereby disrupt traffic. For example, a malicious actor may send multiple MCMs that falsely purport to be from a malicious actor vehicle (e.g., as a host vehicle) and one or more non-existent (fake, ghost) vehicles (e.g., as remote vehicles). The multiple MCMs may indicate that the host vehicle and the fake remote vehicle intend to perform maneuvers or sub-maneuvers that will result in temporal and spatial overlap, indicating an impending collision between the malicious actor host vehicle and the fake remote vehicle.

[0053] When real vehicles in the area detect an impending (false) collision and slow down or maneuver to avoid it, they become victims of the first type of attack. The attacker vehicle may ignore MCMs from real (victim) vehicles that attempt to cancel the maneuver of the attacking host vehicle. For example, the victim vehicle may send an MCM of message type 5 to cancel the attacker vehicle's maneuver, and the attacker vehicle may respond with an MCM of message type 4 to ignore the canceling MCM, or the attacker vehicle may send an MCM of message type 3 to make another maneuver reservation. Thus, the attacker's MCM misbehavior forces the victim vehicle to react by slowing down or maneuvering away from the false impending collision, causing a traffic disruption.

[0054] In a second type of attack, the attacker's goal is to cause unexpected behavior by the victim vehicle. For example, an attacker may send an MCM with values ​​in one or more fields that conform to the relevant MCM message protocol but still indicate an impossible situation. For example, the attacker's MCM may indicate that the attacker vehicle intends to perform a maneuver at an announced speed that is inconsistent with information in other fields of the attacker's MCM (such as a time field, a field indicating the distance required to complete the announced maneuver, or another suitable MCM information field). Such incorrect or inconsistent values ​​may cause the victim vehicle to erroneously approve the attacker vehicle's maneuver, which may result in an accident. Furthermore, processing such inconsistent field values ​​from the attacker's MCM may consume processing resources of the victim vehicle.

[0055] In a third type of attack, the attacker may attempt to disrupt traffic by performing a "denial of service" type attack to repeatedly deny or overrule the victim vehicle's maneuver requests. For example, the attacker vehicle may respond to a maneuver request MCM from the victim vehicle by sending a response MCM that overrules all maneuver requests from the victim vehicle. As another example, the attacker vehicle may respond to a maneuver request from the victim vehicle by sending an MCM that indicates that the attacker vehicle will perform a maneuver or sub-maneuver that causes an accident with the victim vehicle to force the victim vehicle to not perform the requested maneuver.

[0056] Various embodiments include methods implemented in a vehicle processing system and a network computing device processing system for detecting misbehavior in an MCM. In various embodiments, a V2X processing system of a vehicle receiving an MCM may perform a misbehavior test on the received MCM and take action in response to the test identifying misbehavior associated with the MCM. In various embodiments, the V2X processing system may be configured with one or more detectors configured to perform one or more tests for misbehavior on the MCM. The one or more detectors may be configured or implemented in software, hardware, or any combination of software and hardware.

[0057] In some embodiments, a V2X processing system may receive an MCM including a first field and a second field, and in response to the first and second fields including inconsistent information, the processing system may send a message associated with the received MCM including an indication that the information in the first field is inconsistent with the information in the second field. In some embodiments, the V2X processing system may determine whether first information in one or more first fields of the received MCM is inconsistent with second information in one or more second fields of the received MCM, and may determine that a misbehavior condition exists in the received MCM in response to determining that the first information in the one or more first fields of the received MCM is inconsistent with the second information in the one or more second fields of the received MCM. In some embodiments, in response to determining the misbehavior condition (e.g., in response to a test identifying misbehavior associated with the MCM), the V2X processing system may send a misbehavior report (e.g., an MBR) to a network computing device (such as a misbehavior authority server).

[0058] In some embodiments, performing a misbehavior test on the MCM may include determining whether information in the MCM type field is inconsistent with the presence or absence of one or more second fields. For example, the V2X processing system may perform a test to determine an inconsistency between the format of the MCM and the values ​​in one or more fields of the MCM. For some MCMs, the MCM should contain properly configured optional fields that are consistent with the values ​​in the MCM type field. In some embodiments, the V2X processing system may detect that the MCM is missing a field and may cancel and / or renegotiate the maneuver with the remote vehicle. In some embodiments, the format of the MCM may be defined in a technical standard such as the SAE J3186 standard.

[0059] In some embodiments, performing a misbehavior test on the MCM may include determining whether information in a target road resource (TRR) location field is inconsistent with information in a TRR type field. For example, the V2X processing system may perform a test to determine whether a value of the TRR location field is inconsistent with a value of the TRR type field (e.g., the value of the TRR location field and the value of the TRR type field cannot both be true).

[0060] In some embodiments, the V2X processing system may determine whether information related to a requested or proposed maneuver is inconsistent in two or more fields of the MCM. In some embodiments, performing a misbehavior test on the MCM may include determining whether information in a performer identifier (ID) field is inconsistent with information in a source ID field or information in a destination ID field. (The performer ID indicates an identifier of a vehicle running or performing a maneuver or sub-maneuver.) For example, the V2X processing system may determine whether the value of a source ID field identifying a sending vehicle and / or the value of a destination ID field identifying a receiving vehicle is consistent with the value of a performer ID field identifying a vehicle performing the maneuver or sub-maneuver. For example, a properly formatted and configured MCM must include identifiers for all maneuvering vehicles within a set of source IDs and destination IDs. In one form of MCM misbehavior, and the attacker may not include one or more destination IDs in the MCM that would notify the remote vehicle of the desired maneuver or sub-maneuver.

[0061] In some embodiments, performing a misbehavior test on the MCM may include determining whether the information in the maximum speed field is inconsistent with the TRR location field. For example, the receiving V2X processing system may determine or calculate the speed required to perform a maneuver or sub-maneuver (performed by the sending vehicle or the receiving vehicle) based on the vehicle's starting location and time and ending location and time. If the maneuvering vehicle requires a speed greater than the maximum speed value indicated in the MCM to complete the proposed maneuver, the V2X processing system may determine that these values ​​in the MCM are inconsistent.

[0062] In some embodiments, the V2X processing system may determine whether information in two or more fields of the MCM related to a requested or proposed maneuver is unreasonable. For example, the V2X processing system may determine whether the trajectory of the proposed or requested maneuver, or another aspect of the proposed requested maneuver, is reasonable or executable before executing the maneuver. In some embodiments, performing a misbehavior test on the MCM may include determining whether first information in one or more fields related to a predetermined maneuver of the vehicle is inconsistent with second information in one or more second fields related to a predetermined maneuver of the vehicle. For example, the V2X processing system may determine that the value of the minimum speed field in the MCM is greater than the value of the maximum speed field in the MCM. As another example, the V2X processing system may determine that the value in the performer size field (e.g., width, length, height, etc.) is greater than the numerical value in the TRR field (e.g., indicating the width, length, height, etc. of the TRR).

[0063] In some embodiments, the V2X processing system may determine that first information in one or more fields associated with a predetermined maneuver of the vehicle or second information in one or more second fields associated with a predetermined maneuver of the vehicle exceeds a threshold. In some embodiments, the V2X processing system may be configured with one or more thresholds for TRR parameters, vehicle performance and / or operating parameters, and the like. For example, the V2X processing system may be configured with a TRR width threshold, which may indicate a maximum road lane width. The V2X processing system may determine that a value of a TRR width field in the MCM is greater than the TRR width threshold, which may indicate an inconsistency in the MCM.

[0064] In some embodiments, the V2X processing system may determine that first information in one or more fields associated with a scheduled maneuver of the vehicle or second information in one or more second fields associated with a scheduled maneuver of the vehicle indicates an overlap of TRRs. For example, the V2X processing system may compare information in a first MCM with information in a second MCM, and may determine an inconsistency in the overlap of one or more parameters of TRRs including the first information and the second information. As another example, the V2X processing system may receive a first MCM from a first remote vehicle and a second MCM from a second remote vehicle, and may determine an overlap of TRR parameters in the first information of the first MCM and in the second information of the second MCM. In some embodiments, an overlap of TRR parameters may indicate a possible road accident, such as a possible collision between two vehicles.

[0065] In some embodiments, the V2X processing system may identify or determine an inconsistency between an MCM and a requirement of an applicable communication protocol (e.g., MSCS). For example, the V2X processing system may receive two MCMs (a first MCM and a second MCM) from a transmitting vehicle. The V2X processing system may perform a misbehavior test on the first or second MCM, which includes determining whether first information in the first MCM is inconsistent with second information in the MCM. The V2X processing system may identify a misbehavior condition in response to determining that the first information in the first MCM is inconsistent with the second information in the second MCM.

[0066] In some embodiments, the V2X processing system may determine that the first MCM and the second MCM are not in an expected or appropriate sequence. For example, the V2X processing system may determine that the first MCM includes a maneuver cancel (MCM type 5) to cancel a proposed maneuver, and the second MCM includes a maneuver hold (MCM category 3) or an emergency maneuver hold (MCM category 6) to indicate that a vehicle request or proposed maneuver was sent. The maneuver cancel MCM and the maneuver hold MCM may be out of sequence as required by the applicable communication protocol. In such an embodiment, the V2X processing system may determine whether the first MCM and the second MCM are out of sequence, thereby indicating an inconsistency in the first and / or second MCM.

[0067] In some embodiments, the V2X processing system may identify MCM misbehavior, where an attacker engages in uncooperative behavior, such as repeatedly denying maneuver requests, or proposing maneuvers or sub-maneuvers that force a victim vehicle to change or cancel a maneuver. In some embodiments, performing a misbehavior test on the MCM may include determining a number of maneuver request rejections received from a remote vehicle associated with one or more requests sent by the vehicle to perform a maneuver to the remote vehicle, and identifying a misbehavior condition in response to determining that the number of maneuver request rejections satisfies a request rejection threshold. For example, the V2X processing system may determine that the remote vehicle rejected or rejected a requested maneuver multiple times. When the V2X processing system determines that the number of rejections or rejections satisfies the request rejection threshold, the V2X processing system may identify a misbehavior condition.

[0068] In some embodiments, the V2X processing system may identify a failure to respond within a period of time as a request rejection. For example, the V2X processing system may start a timer associated with one or more requests to perform a maneuver sent to the remote vehicle. The V2X processing system may count maneuver request rejections when the timer expires without receiving a response to the one or more requests from the remote vehicle. In response to determining that the number of rejections or denials meets the request rejection threshold, the V2X processing system may identify a misbehavior condition.

[0069] In some embodiments, the V2X processing system may also consider whether the remote vehicle is able to respond to the request of the sending vehicle, and / or whether the remote vehicle is able to perform an operation (such as a maneuver or sub-maneuver) related to the request of the sending vehicle. For example, the V2X processing system may determine whether wireless communication link conditions allow or prevent V2X communication. For example, the V2X processing system may determine that wireless communication link interference, message or signal congestion, or other factors are interfering with V2X communication with the remote vehicle.

[0070] As another example, the V2X processing system may determine whether a remote vehicle is within communication range, such as based on information in another V2X message (such as a BSM or CAM), or based on information from one or more sensors of the vehicle (e.g., information from a camera, radar, lidar, and / or the like). As another example, the V2X processing system may determine whether road conditions permit or prevent completion or execution of a maneuver (e.g., based on information in another V2X message, information from a vehicle sensor, information from a digital map (such as a high-definition map), and / or the like).

[0071] In some embodiments, the V2X processing system may identify a misbehavior condition in response to determining that the remote vehicle is capable of responding to one or more requests to perform a maneuver and that the remote vehicle is capable of performing operations related to the one or more requests to perform the maneuver.

[0072] Various embodiments include methods and network computing device processing systems for misbehavior detection in an MCM. In some embodiments, the network computing device processing system may receive multiple misbehavior reports indicating MCM misbehavior from multiple vehicles, and may identify inconsistencies between multiple misbehavior event reports. The network computing device processing system may identify a misbehavior condition in response to identifying an inconsistency between multiple misbehavior reports, and may take action in response to identifying the misbehavior condition. In some embodiments, identifying an inconsistency between multiple misbehavior reports may include determining that the vehicle is imitating multiple vehicles. In some embodiments, identifying an inconsistency between multiple misbehavior reports may include determining that a vehicle identified in the multiple misbehavior reports did not send a misbehavior report to the network computing device. In some embodiments, the network computing device processing system may send a request for information related to the inconsistencies between the identified multiple misbehavior reports to a second network computing device.

[0073] For example, the network computing device may receive from one or more vehicles a report indicating one or more misbehavior in which the vehicle has identified or determined that the MCM misbehaved. Typically, such a misbehavior report may include a reason code identifying a misbehavior condition or misbehavior attack. Such a misbehavior report may also include a vehicle identifier, such as a source ID, a destination ID, a performer ID, and / or the like. Using such information, the network computing device may identify each vehicle involved in the maneuver and / or the MCM associated with the maneuver.

[0074] In some embodiments, the network computing device may determine that one or more involved vehicles failed to send a misconduct report. In some embodiments, the network computing device may determine that there are inconsistencies between or among misconduct reports. For example, the network computing device may identify the types of attacks that are inconsistent in the misconduct reports. As another example, the network computing device may determine that different misconduct reports identify different attackers. The network computing device may identify a misconduct condition in response to identifying an inconsistency between multiple misconduct reports.

[0075] In some embodiments, the network computing device may send an information request to another network computing device, such as a vehicle manufacturer or fleet operator, to notify them of a faulty device in an attacker vehicle. In some embodiments, the network computing device may request information from a link authority or another suitable network computing device to request information about whether a reported vehicle identifier (e.g., source ID, destination ID, performer ID, etc.) is associated with or linked to the same vehicle. The network computing device may use information about vehicle identifiers received in response to such a request to determine whether the attacker vehicle is impersonating one or more other vehicles, or sending MCMs that falsely purport to be from a remote vehicle other than the attacker vehicle. In response to identifying an improper behavior condition, the network computing device may take action against the attacker vehicle, such as revoking a digital certificate of the determined attacker vehicle, to deny the attacker access to the V2X communication network.

[0076] Various embodiments can enable the V2X processing system and the network device processing system in the vehicle to detect and respond to attacks that introduce MCM misbehavior. In an example attack scenario, the receiving vehicle can receive one or more MCMs from the sending vehicle, and the receiving vehicle can determine or identify the MCM misbehavior in the received MCMs. The received MCMs can be associated with a specific motor ID. The receiving vehicle can send MCMs indicating the detected MCM misbehavior to other vehicles. The MCMs sent to other vehicles can also include a specific motor ID from the sending vehicle, an identifier of the sending vehicle, a reason code (reason code 3) indicating the detected erroneous behavior, and / or other information. The receiving vehicle can also send a misbehavior report to the misbehavior management agency computing device in the V2X communication network. In addition, other vehicles to which the receiving vehicle reports the detected MCM misbehavior can also send misbehavior reports to the misbehavior management agency network computing device. Multiple misbehavior reports can enable the misbehavior management agency network computing device to identify the attacker vehicle and the type of attack being adopted.

[0077] In another example attack scenario, an attacker vehicle may send an MCM to cancel a maneuver negotiation or deny a maneuver requested by another vehicle. As a reason for the cancellation or denial, the MCM from the attacker vehicle may include a response code that falsely indicates that the attacker vehicle has detected MCM misbehavior, such as from the sending vehicle or from another (third) vehicle. Since the attacker vehicle has broadcast an MCM that includes a response code that falsely indicates that MCM misbehavior has been detected, other nearby vehicles may send misbehavior reports to the misbehavior management agency, reporting the (false) detected MCM misbehavior. However, misbehavior reports from other nearby vehicles may identify the attacker vehicle as the sender of the initial report of MCM misbehavior. Therefore, the misbehavior management agency may expect the attacker vehicle to also send a misbehavior report. However, in response to the attacker vehicle not sending a misbehavior report to the misbehavior management agency, the misbehavior management agency may identify the attacker vehicle as the true source of the MCM misbehavior. The misbehavior management agency may also take remedial action against the identified attacker vehicle.

[0078] Various embodiments improve the security and operability of a V2X processing system in a vehicle by enabling the V2X processing system and the network computing device processing system in the vehicle to identify and take appropriate actions in response to improper behavior in an MCM. Various embodiments improve the security of a V2X network and communication system by enabling the V2X processing system and the network computing device processing system in the vehicle to protect the integrity of the MCM. Various embodiments improve the security and operation of a V2X network and communication system by enabling the V2X processing system and the network computing device processing system in the vehicle to reduce or eliminate interference with network communications and road traffic that may be caused by improper behavior of an MCM.

[0079] 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.

[0080] 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 processing system 104 including wireless communication capabilities. The base stations 110 may communicate with the core network 140 via 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.

[0081] The base station 110 is a network element that communicates with a wireless device (e.g., the V2X processing 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 (eNode B 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 (gNode B or gNB), or the like. 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 that 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, as referenced herein. Figure 1B Described non-aggregate network, etc.

[0082] 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 processing system via a V2X wireless communication link 124 for downloading information useful for the V2X processing system autonomous and semi-autonomous driving functions, and for receiving information such as misbehavior reports from the V2X processing system 104.

[0083] A misbehavior 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 misbehavior reports from the V2X processing system 104, which may be sent by the V2X processing system 104 from time to time.

[0084] 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. Further 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).

[0085] Figure 1Bis a system block diagram illustrating an example non-aggregated base station 160 architecture according to any of the various embodiments, which may be part of a V2X and / or 5G network suitable for communicating map data and updated object / feature location data to vehicles. Figure 1A and 1B , the non-aggregated 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 non-aggregated 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 mid-haul 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 embodiments, a user equipment (UE), such as the V2X processing system 104, may be served by multiple RUs 172 simultaneously.

[0086] Each unit (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, signals) via a wired or wireless transmission medium. Each unit, or an associated processor or controller that provides instructions to the communication interface of the unit, may be configured to communicate with one or more other units via a transmission medium. For example, these units may include a wired interface that is configured to receive or send signals to one or more other units via a wired transmission medium. In addition, these units may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) configured to receive or send signals to one or more of the other units via a wireless transmission medium, or both.

[0087] 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) or the like. Each control function may be implemented with an interface configured to communicate signals with other control functions carried by CU 162. CU 162 may be configured to process user plane functions (i.e., central unit-user plane (CU-UP)), control plane functions (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some embodiments, CU 162 may be logically divided 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). CU 162 may be implemented to communicate with DU 170 when necessary for network control and signaling.

[0088] 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 carry 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, or the like) at least in part according to a functional partitioning such as those defined by the Third Generation Partnership Project (3GPP). In some aspects, DU 170 may also carry one or more low PHY layers. Each layer (or module) may be implemented with an interface that is configured to communicate signals with other layers (and modules) carried by DU 170 or with control functions carried by CU 162.

[0089] The lower layer functions 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 carry 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, or the like), or both, based at least in part on functional partitioning (such as functional partitioning of the lower layers). 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 embodiments, 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 implementation of the DUs 170 and CUs 162 in a cloud-based radio access network (RAN) architecture (such as a vRAN architecture).

[0090] The SMO framework 166 may be configured to support RAN deployment and provisioning of non-virtualized 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) via a cloud computing platform interface (such as an O2 interface) to perform network element lifecycle management (via instantiated virtualized network elements). Such virtualized network elements may include, but are not limited to, CU 162, DU 170, RU 172, and near-RT RIC 164. In some embodiments, 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. In addition, in some embodiments, 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 that is configured to support the functionality of the SMO framework 166 .

[0091] 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 over an interface connecting one or more CUs 162, one or more DUs 170, or both, and O-eNBs to the near-RT RIC 164 (such as via an E2 interface).

[0092] In some embodiments, 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 used 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 adjust RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns of performance and perform corrective actions using the AI / ML model through the SMO framework 166 (such as via O1 reconfiguration) or via the creation of RAN management policies (such as A1 policies).

[0093] Figure 1C 1 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 processing 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 processing devices (e.g., 104, 106, and 108) of other vehicles. By sharing vehicle position, speed, direction, braking, and other information, vehicles can maintain safe separation, identify and avoid potential collisions. For example, a rear vehicle 12 receiving a basic safety message 40 from a front 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 front vehicle 16 applies the brakes, the V2X processing system 102 in the rear vehicle 12 can simultaneously apply the brakes to maintain the safe separation distance 20, even when the front vehicle 16 stops suddenly. As another example, the V2X processing system 104 in the truck 14 may receive basic safety messages 30, 50 from two vehicles 12, 16, and thus be informed that the truck 14 should stop at the intersection to avoid a collision. Each of the vehicle V2X onboard devices 104, 106, 108 may communicate with each other using any of a variety of short-range communication protocols. In addition, the vehicle may be able to send data and information about the detected basic safety messages and misbehavior reports about the detected V2X misbehavior to the original equipment manufacturer (OEM) (70, 72) and / or MA74 (e.g., 132) via communication links 60, 61, 62 via the communication network 18. The misbehavior report may be sent directly to the MA 74 (e.g., via communication links 64, 66). In other embodiments, the misbehavior report may first be sent to a misbehavior report preprocessing unit such as an OEM server 70, 72 via communication links 64, 66 for preprocessing. Then, the preprocessed misbehavior report may be sent from the misbehavior report preprocessing server 70, 72 to the MA 74 via communication links 64, 66. In other embodiments, misbehavior reports from vehicles, such as from vehicle 16, may be received at MA 74. MA 74 may relay misbehavior reports received from vehicle 16 to OEM servers 70, 72 via communication links 64, 66. Additionally, OEM servers 70, 72 may provide confirmation reports to MA 74 via communication links 64, 66.

[0094] Figure 2A is a component diagram of an example vehicle V2X processing system 200 suitable for implementing various embodiments. Figures 1A to 2A, the processing system 200 may include a vehicle 102, which includes a V2X processing system 104. The vehicle V2X processing system 104 may communicate with various systems and devices, such as an in-vehicle 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 processing system 104 may also communicate with a roadside unit 112, a cellular communication network base station 110, and other external devices.

[0095] The V2X processing 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 an in-vehicle display, and to the input module 207 to receive information from vehicle sensors and driver input.

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

[0097] Examples of vehicle 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. 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 for steering, braking, engine operation, lights, direction signals, and the like.

[0098] Figure 2Bis a component block diagram illustrating components of an exemplary vehicle automatic / semi-automatic driving system 220, which may be coupled to the V2X processing system 104 and is suitable for implementing various embodiments. The automatic / semi-automatic driving system 220 may include various subsystems, communication elements, computing elements, computing devices, or units that may be used within the vehicle 102. Figures 1A to 2A , various computing elements, computing devices or units within the automatic / semi-automatic driving system 220 may be implemented within a system of computing devices (i.e., a subsystem) that is connected via the vehicle network 210 (e.g., by Figure 2B In some embodiments, various computing elements, computing devices, or units within the automatic / semi-automatic driving system 220 may be implemented within a single computing device (such as separate threads, processes, algorithms, or computing elements). Figure 2B Each of the subsystems / computing elements shown in is also generally referred to herein as a "layer" within the computing "stack" that makes up the vehicle autonomous / semi-autonomous driving system 220. However, the use of the terms "layer" and "stack" in describing various embodiments does not imply or require that the corresponding functions be implemented within a single vehicle computing device, although this is a potential implementation embodiment. Rather, 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.

[0099] 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-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-240 may be excluded from the autonomous / semi-autonomous driving system 220. Each of the layers 222-240 may exchange data, computation results, and commands, such as Figure 2BIn addition, the automatic / semi-automatic driving system 220 can receive and process data from sensors (e.g., radar, lidar, camera, inertial measurement unit (IMU), etc.), navigation information sources (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 automatic / semi-automatic driving system 220 can output vehicle control commands or signals to the automatic driving system (ADS) vehicle control unit 242, which is a system, subsystem, or computing device directly connected to the vehicle steering, throttle, and brake controls. Figure 2A The configuration of the automatic / semi-automatic driving system 220 and the ADS vehicle control unit 242 shown in FIG. 2 is merely an example configuration, and other configurations of the vehicle management system and other vehicle components may be used. For example, Figure 2B The configuration of the autonomous / semi-autonomous driving system 220 and the ADS vehicle control unit 242 shown 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 driving vehicle.

[0100] 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.

[0101] 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.

[0102] The positioning engine layer 226 can receive data from the radar and / or lidar perception layer 222, the camera perception layer 224, and various navigation information sources, and process the data and information to determine the location of the vehicle 100. The various sources of navigation information 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 (such as radar, lidar, etc.) that are capable of identifying and determining the direction and distance to objects near the vehicle.

[0103] The autonomous / semi-autonomous driving system 220 may include or be a vehicle V2X processing system 104 according to various embodiments. One or more of the layers 222-240 may provide information to or receive information from the V2X processing system 104. The V2X processing system 104 may be configured to communicate with a highway communication system, such as via a V2X communication link (e.g., 124) and / or 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.

[0104] The map fusion and arbitration layer 230 can 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 within the map, such as the location within the traffic lane, the location within the street map, etc. The sensor data can be stored in a memory (e.g., the memory 312).

[0105] Similar to the location information in some map objects and features and the accuracy and precision of sensors, the GPS position fix 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 the GPS coordinates, sensor data, and map data about objects and features in and near the road. For example, while 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.

[0106] The route planning layer 232 may utilize sensor data and input from an operator or dispatcher to plan a route for the vehicle 102 to follow 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, are not required to use prior maps. For example, other stacks may operate and / or control a vehicle based solely on perception data without providing a map, building a concept of lanes, boundaries, and local maps when receiving perception data.

[0107] 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 a current autonomous or semi-autonomous driving mode is consistent or appropriate, taking into account safety and / or confidence information about nearby objects and features in the driving environment.

[0108] 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 these 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 near the vehicle 100. For example, the sensor fusion and RWM management layer 236 may combine image data from the camera perception layer 224 with arbitrated 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 positions of other vehicles and objects near the vehicle. As another example, the sensor fusion and RWM management layer 236 can 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 can output accurate location and status information of the vehicle 100, as well as accurate location and status information of other vehicles and objects near the vehicle, to the motion planning and control layer 238 and / or the behavior planning and prediction layer 240.

[0109] As another example, the sensor fusion and RWM management layer 236 may 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 precise position and status information. The sensor fusion and RWM management layer 236 may output precise position and status information of the vehicle 102 and precise position and status information of other vehicles and objects in the vicinity of the vehicle 100 via wireless communications (such as through a C-V2X connection, other wireless connections, etc.) 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.).

[0110] As yet another example, the sensor fusion and RWM management layer 236 can 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 can 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 can output the sensor data via wireless communication (such as via a C-V2X connection, other wireless connection, etc.) as part of the precise location and status information of the vehicle 102, which 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.

[0111] The behavior planning and prediction layer 240 of the autonomous vehicle V2X processing system 220 can use the precise position and state information of the vehicle 102 output from the sensor fusion and RWM management layer 236, as well as the position and state information of other vehicles and objects, 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 near the vehicle based on its own vehicle position and speed and other vehicle positions and speeds. Such predictions can take into account information from map data and route planning to predict changes in relative vehicle positions as the host and other vehicles follow the road. The behavior planning and prediction layer 240 can output the behavior and position predictions of other vehicles and objects to the motion planning and control layer 238. In addition, 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 precise position in the road information, and the relative position and motion of other vehicles, the behavior planning and prediction layer 240 can 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. Thus, the behavior planning and prediction layer 240 may calculate or otherwise determine changes in the steering angle and throttle settings of the wheels that will be commanded to the motion planning and control layer 238 and the ADS vehicle control unit 242, as well as various parameters required to implement such lane changes and accelerations. One such parameter may be the calculated steering wheel command angle.

[0112] 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 route planning information, precise position in road information, and 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.

[0113] The ADS vehicle control unit 242 may receive commands or instructions from the motion planning and control layer 238 and convert this information into mechanical control signals for controlling the steering wheel angle, 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 sending a corresponding control signal to a steering wheel controller.

[0114] In various embodiments, the V2X processing system 104 can communicate with other V2X processing system participants (e.g., other vehicles 12, 14, 16) via wireless communication links to send sensor data, location data, vehicle data, and data collected by onboard sensors about the vehicle's surroundings. Such information can be used by other V2X processing system participants to update stored sensor data for relay to other V2X processing system participants.

[0115] In various embodiments, the vehicle V2X processing system 220 may include a function 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 passengers. Such safety checks or oversight functions 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 memory, and the safety check or oversight function may compare the determined values ​​(e.g., relative spacing from nearby vehicles, distance from the centerline of the road, etc.) to the corresponding safety parameters, and issue a warning or command if the safety parameters are violated or will be violated. For example, a safety or oversight function in the behavior planning and prediction layer 240 (or in a separate layer) may determine the 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 a separate layer) may compare a determined or commanded steering wheel command angle to safe steering wheel angle limits or parameters and issue an override command and / or alarm in response to the commanded angle exceeding the safe steering wheel angle limits.

[0116] 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 the parameters 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 steering wheel angle limits, all of which may be a function of road and weather conditions.

[0117] Figure 3A is 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 a plurality of 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., vector coprocessors) connected to the one or more heterogeneous processors 303, 304, 306, 307, 308, 317.

[0118] Each processor 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. The graphics processor 306 may be a graphics processing unit (GPU).

[0119] 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 presentation 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.

[0120] The processing device SOC 300 also includes dedicated circuitry 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, webcam, 3D camera, etc.), video display data from camera firmware, image processing, video pre-processing, video front end (VFE), online JPEG, high-definition video codec, etc. The CAM 305 can be an independent processing unit and / or include an independent or internal clock.

[0121] In some embodiments, the image and object recognition processor 306 may be configured with processor executable instructions and / or dedicated 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 image processing 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.

[0122] System components and resources 316, analog and custom circuits 314, and / or CAM 305 may also include circuits for interfacing with peripheral devices, such as cameras, radars, lidars, 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 an 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).

[0123] The processing device SOC 300 may also include an input / output module (not shown) 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.).

[0124] In some embodiments, the processing device SOC 300 may be included in a control unit (e.g., 140) for 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 the network server (e.g., 184).

[0125] 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.

[0126] Figure 3B is a component block diagram illustrating elements of a vehicle V2X processing system 104 configured in accordance with various embodiments. Figures 1A to 3B , the V2X processing system 104 of a vehicle (eg, 102 ) may 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 .

[0127] The vehicle V2X processing 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 to the processor 205 herein.

[0128] The memory 206 may include non-transitory storage media that electronically stores information. The electronic storage media of the memory 206 may include one or both of system storage provided integrally (i.e., substantially non-removable) with the vehicle processing system 104 and / or removable storage (which may be removably connected to the vehicle V2X processing 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.). In various embodiments, the memory 206 may include one or more charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy disk drives, etc.), and / or other electronically readable storage media.

[0129] The memory 206 may include one or more virtual storage resources (e.g., cloud storage, 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 a roadside unit 112, information received from a base station 110, and / or other information that enables the vehicle V2X processing system 104 to function as described herein.

[0130] The processor 205 may include one or more local processors that may be configured to provide information processing capabilities in the vehicle V2X processing system 104. Thus, the processor 205 may include one or more of 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. Figure 3B 205 is shown as a single entity, but this is for illustration 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 processing functionality of multiple devices distributed in the vehicle and operating in coordination.

[0131] The vehicle V2X processing 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 an MCM receiving module 334, an MCM misbehavior testing module 336, a response action module 338, a response timer module 340, a transmit / receive (TX / RX) module 342, and a remote vehicle (RV) response assessment processing module 344, an RV maneuver assessment module 346, and / or other modules.

[0132] The MCM receiving module 334 may be configured to receive an MCM from another vehicle (eg, 12 , 14 , 16 ).

[0133] The MCM misbehavior testing module 336 may be configured to perform misbehavior testing on the MCM.

[0134] The response action module 338 may be configured to take action in response to the test identifying inappropriate behavior associated with the MCM.

[0135] The response timer module 340 may be configured to start a timer associated with one or more requests to execute a message sent to a remote vehicle (eg, 12 , 14 , 16 ) and determine whether the timer has expired.

[0136] 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 .

[0137] The RV response assessment processing module 344 may be configured to determine whether a remote vehicle (eg, 12 , 14 , 16 ) is unable to respond to one or more requests to perform a maneuver.

[0138] The RV maneuver assessment module 346 may be configured to determine whether the remote vehicle (eg, 12 , 14 , 16 ) is unable to perform operations associated with one or more requests to perform a maneuver.

[0139] 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 .

[0140] The description of the functionality provided by the different modules 332-346 is for purposes of illustration and not limitation, as any of the modules 332-346 may provide more or less functionality than described. For example, one or more of the modules 332-346 may be excluded, and some or all of their functionality may be provided by another module 332-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-346.

[0141] Figure 3C is a component block diagram illustrating elements of a processing system 350 of a network computing device (eg, 132) configured in accordance with various embodiments. Figures 1A to 3C , the processing system 350 can be configured to communicate with one or more other vehicles 12 , 14 , 16 via the roadside unit 112 and / or via a cellular network base station 110 of a core network (eg, 140 ).

[0142] Processing system 350 may include one or more processors 352, memory 206, wired or wireless communication interfaces 356, and other components. Processing system 350 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed to processor 352 herein.

[0143] The memory 354 may include non-transitory storage media that electronically stores information. The electronic storage media of the memory 354 may include one or both of system storage provided integrally (i.e., substantially non-removable) with the network computing device processing system 350 and / or removable storage (which may be removably connected to the processing system 350 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.). In various embodiments, the memory 354 may include one or more charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy disk drives, etc.), and / or other electronically readable storage media.

[0144] The memory 354 may include one or more virtual storage resources (e.g., cloud storage, a virtual private network, and / or other virtual storage resources). The memory 354 may store software algorithms, information determined by the processor(s) 352, 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 processing system 350 to function as described herein.

[0145] Processor 352 may include one or more local processors that may be configured to provide information processing capabilities in processing system 350. Thus, processor 352 may include one or more of 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. Figure 3C 352 is shown as a single entity, but this is for illustration purposes only. In some embodiments, processor 352 may include multiple processing units. These processing units may be physically located within the same device, or processor 352 may represent processing functionality of multiple devices distributed in the vehicle and operating in coordination.

[0146] The network computing device processing system 350 may be configured by machine-readable instructions 358, 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 misbehavior report (MBR) receiving module 360, an inconsistency identification module 362, a misbehavior status module 364, a response action module 366, a TX / RX module 368, and / or other modules.

[0147] The MBR receiving module 360 ​​may be configured to receive a plurality of misbehavior reports from a plurality of vehicles indicating MCM misbehavior.

[0148] The inconsistency identification module 362 may be configured to identify inconsistencies between multiple misconduct reports.

[0149] The misconduct condition module 364 may be configured to identify a misconduct condition in response to identifying an inconsistency between the plurality of misconduct reports.

[0150] The responsive action module 366 may be configured to take action in response to identifying the execution misconduct condition.The responsive action module 366 may be configured to send a request to the second network computing device for information related to the identified inconsistencies between the plurality of misconduct reports.

[0151] The TX / RX module 368 may be configured to control the operation of communication devices of the network computing device processing system 350 , such as the communication interface 356 .

[0152] Processor 352 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 .

[0153] The description of the functionality provided by the different modules 360-368 is for purposes of illustration and not limitation, as any of the modules 360-368 may provide more or less functionality than described. For example, one or more of the modules 360-368 may be excluded, and some or all of their functionality may be provided by another module 360-368. As another example, the processor 352 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 360-368.

[0154] Figure 4A is a block diagram illustrating elements of a slave MCM 400 suitable for implementing various embodiments. Figures 1A to 4A , MCM is a V2X message (e.g., Maneuver Sharing and Coordination Message) that vehicles equipped with a V2X processing system can send, receive, and / or exchange to coordinate vehicle maneuvers. Figure 4A As shown in FIG. 4 , the MCM 400 may include various information fields 402-470d. Some fields may be used for other V2X messages (e.g., BSM, CAM, etc.). Examples of fields that may be used in other V2X messages include a message timestamp field 402, a host vehicle three-dimensional position field 404, a position accuracy field 406, an MCM type 408, a source ID 410, a destination ID 412, a maneuver ID 414, a maneuver 416, a reason code 418, a maneuver execution status field 420, a performer ID field 430, and an affected connected vehicle (CV) ID field 432, a current state field 434, a minimum speed field 442, and a maximum speed field 444. Subfields of the current state field 434 may include a performer position field 448a, a performer position confidence field 448b, a speed field 448c, a heading field 448d, a four-way acceleration (accel4way) field 448e, and a size field 448f. Other fields of the MCM 400 may be unique or specific to the MCM 400, such as the MCM type field 408, the reason code field 418, the maneuver execution status field 420, the target road resource (TRR) field 436, and various subfields of the TRR field 436, such as the TRR type field 450a, the TRR width field 450b, the TRR location field 450c, and the TRR movement field 450d.

[0155] Figure 4B is a flow chart illustrating a basic MCM protocol 460 suitable for implementing various embodiments. Figures 1A to 4B, the MCM protocol can be a host vehicle (HV) and a remote vehicle (RV) exchanging messages to perform a handshake operation or negotiation on a requested or proposed maneuver. The basic MCM protocol 460 can propose a series of MCM messages or MCM message types. For example, message type 0-maneuver intention can be followed by message type 1-message request, and then message type 2-maneuver response. The next message in the sequence according to the basic MCM protocol 460 can be message type 3-maneuver reservation, message type 5-RV maneuver cancellation, or message type 4-HV maneuver cancellation. Message type 5-RV maneuver cancellation may also be followed by message type 3-maneuver reservation. Message type 4-HV maneuver cancellation may also be followed by message type 5-RV maneuver cancellation. In addition, message type 7-maneuver execution status can be after message type 3-maneuver reservation, message type 5-RV maneuver cancellation, or message type 4-HV maneuver cancellation. The message sequence can be repeated, starting with message type 0-maneuver intention.

[0156] Figure 4C 4 is a flow chart showing an emergency MCM protocol 470 suitable for implementing various embodiments. Figures 1A to 4C , the emergency MCM protocol 470 may include similar messages as the basic MCM protocol 460, but certain messages, such as message type 2 maneuver response and message type 3 maneuver reservation, may not be required.

[0157] Figure 4D is a message flow diagram and accompanying schematic diagram illustrating vehicles performing a maneuver negotiation 480 (eg, a handshake operation) of an example lane change maneuver facilitated by an MCM between an HV and an RV.

[0158] refer to Figures 1A to 4D At time (a), the host vehicle (HV) may send an MCM requesting or suggesting that the HV perform a lane change (Msg_Intention: Lane change request) to the first remote vehicle (RV1) and the second remote vehicle (RV2). Each of RV1 and RV2 may decide to accept the HV requested or proposed lane change maneuver (decide to accept).

[0159] At time (b), RV1 and RV2 may send an MCM to the HV accepting the proposed lane change (Msg_Response: Lane change accept). The HV may make a decision on the details of the maneuver.

[0160] At time (c), the HV may send a message notifying RV1 and RV2 of the details of the HV's maneuver (Msg_confirmation: Maneuver decision). The HV may be performing the maneuver (Perform Maneuver). Optionally, after performing the maneuver, the HV may send a message to RV1 and RV2 indicating that the HV has completed the maneuver (Msg_Complement). Maneuver negotiation 480 represents only one example of a maneuver negotiation that may be performed between a HV and a RV.

[0161] In operation, vehicles may play different roles from time to time, so a vehicle acting as an HV at one time acts as an RV at another time, and so on. Maneuver negotiation 480 may be performed extremely quickly between multiple vehicles, enabling the vehicles to coordinate various maneuvers quickly and efficiently.

[0162] Figure 5A is a process flow diagram of an example method 500a for misbehavior detection in an MCM performed by a processor of a V2X processing system in a vehicle according to various embodiments. Figures 1A to 5A , method 500a can be performed by one or more processors of the V2X processing system (e.g., 205, 300) or other vehicle processors (e.g., 205, 220, 300), which can be implemented in hardware elements, software elements, or a combination of hardware and software elements.

[0163] In block 502, the V2X processing system may receive an MCM. In some embodiments, the MCM may include a first field and a second field. The means for performing the operations of block 502 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM receiving module 334 and the radio module 218.

[0164] In block 504, the V2X processing system may perform a misbehavior test on the MCM. In various embodiments, a plurality of different tests may be performed in block 504. The means for performing the operations of block 504 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM misbehavior test module 336.

[0165] In some embodiments, performing a misbehavior test on the MCM in block 504 may include determining whether information in the MCM type field is inconsistent with the presence or absence of one or more second fields. In some embodiments, performing a misbehavior test on the MCM in block 504 may include determining whether information in the TRR location field is inconsistent with information in the TRR type field. In some embodiments, performing a misbehavior test on the MCM in block 504 may include determining whether information in a performer identifier (ID) field is inconsistent with information in a source ID field or information in a destination ID field. In some embodiments, performing a misbehavior test on the MCM in block 504 may include determining whether information in a maximum speed field is inconsistent with the TRR location field.

[0166] In some embodiments, performing the misbehavior test on the MCM in block 504 may include determining whether first information in one or more fields associated with a scheduled maneuver of the vehicle is inconsistent with second information in one or more second fields associated with the scheduled maneuver of the vehicle. In some embodiments, the first information in one or more fields associated with a scheduled maneuver of the vehicle or the second information in one or more second fields associated with the scheduled maneuver of the vehicle may exceed a threshold. In some embodiments, the first information in one or more fields associated with a scheduled maneuver of the vehicle or the second information in one or more second fields associated with the scheduled maneuver of the vehicle may indicate an overlap of the TRRs.

[0167] In block 506, the V2X processing system may take action in response to the test identifying misbehavior associated with the MCM. In some embodiments, the V2X processing system may send a misbehavior report to the network computing device in response to determining the misbehavior condition. Means for performing the operations of block 506 may include executing a processor (e.g., 205, 303, 304, 306, 307, 308, 310) of the response action module 338 and the radio module 218.

[0168] The V2X processing system may repeat the operations of blocks 502 - 506 from time to time, such as periodically or in response to received one or more MCMs.

[0169] Figures 5B to 5G is a process flow diagram of example operations 500b-500g that may be performed by a processor of a vehicle V2X processing system as part of a method 500a for misbehavior detection in an MCM in accordance with various embodiments. Figure 1A to Figure 5G , operations 500b-500g may be performed by a processor of the V2X processing system (e.g., 205, 300) or other vehicle processors (e.g., 104, 205, 220, 300), which may be implemented in hardware elements, software elements, or a combination of hardware and software elements.

[0170] refer to Figures 1A to 5B ,exist Figure 5B In operation 500b shown in FIG. 5 , the V2X processing system may receive an MCM including a first field and a second field in block 510. The means for performing the operations of block 510 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM receiving module 334.

[0171] In block 512, the V2X processing system may send a message associated with the received MCM including an indication that the information in the first field is inconsistent with the information in the second field. Means for performing the operations of block 512 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the TX / RX module 342 and the radio module 218.

[0172] The V2X processing system may repeat the operations of blocks 510 and 512 .

[0173] refer to Figures 1A to 5C , as described in block 502 ( Figure 5A ) after receiving MCM Figure 5C In operation 500c shown in FIG. 5 , the V2X processing system may determine whether the first information in one or more first fields of the received MCM is inconsistent with the second information in one or more second fields of the received MCM in block 514. The means for performing the operations of block 514 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM misbehavior test module 336.

[0174] In block 516, the V2X processing system may determine that a misbehavior condition exists in the received MCM in response to determining that the first information in the one or more first fields of the received MCM is inconsistent with the second information in the one or more second fields of the received MCM. Means for performing the operations of block 516 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM misbehavior test module 336.

[0175] In block 506 of the method 500a, the V2X processor may take action in response to the test identifying inappropriate behavior associated with the MCM as described in block 506 of the method 500a.

[0176] refer to FIG. 1A to FIG. 5D ,exist Figure 5DIn operation 500d shown in FIG. 5 , the V2X processing system may receive the first MCM and the second MCM in block 520. The means for performing the operations of block 520 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM receiving module 334 and the radio module 218.

[0177] In block 522, the V2X processing system may determine whether the first information in the first MCM is inconsistent with the second information in the second MCM. For example, the first MCM and the second MCM may not be in sequence, such as a sequence of MCM messages or a sequence of MCM message types. For example, the first MCM may include a message type 5-RV maneuver canceled, while the second MCM may include a message type 3-maneuver reserved. As another example, the first MCM may include a message type 4-HV maneuver canceled, while the second MCM may include a message type 3-maneuver reserved. In these examples, according to a protocol such as the basic MCM protocol 460 ( Figure 4B ), the first and second MCMs are not in order. The means for performing the operations of block 522 may include a processor (eg, 205, 303, 304, 306, 307, 308, 310) executing the MCM misbehavior test module 336.

[0178] In block 524, the V2X processing system may identify a misbehavior condition in response to determining that the first information in the first MCM is inconsistent with the second information in the second MCM. Means for performing the operations of block 524 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM misbehavior test module 336.

[0179] In block 506 of the method 500a, the V2X processor may take action in response to the test identifying inappropriate behavior associated with the MCM.

[0180] refer to Figures 1A to 5E ,exist Figure 5E In operation 500e shown in FIG. 1 , the V2X processing system may send one or more MCM requests to the remote vehicle to perform the maneuver in block 530. The components for performing the operations of block 530 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the TX / RX module 342 and the radio module 218.

[0181] In block 532, the V2X processing system may determine a number of maneuver request rejections received from the remote vehicle associated with one or more MCM requests to perform a maneuver sent by the vehicle to the remote vehicle. The means for performing the operations of block 532 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the RV response evaluation module 344.

[0182] In determination block 534, the V2X processing system may determine whether the number of maneuver request rejections satisfies a request rejection threshold. Means for performing the operations of determination block 534 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the RV response evaluation module 344.

[0183] In response to determining that the number of maneuver request rejections does not satisfy the request rejection threshold (ie, determination block 534 = “No”), the V2X processing system may continue to send MCM requests to the remote vehicle to perform the maneuver in block 530 .

[0184] In response to determining that the number of maneuver request rejections satisfies the request rejection threshold (i.e., determination block 534 = "Yes"), the V2X processing system may identify a misbehavior condition in block 536. Means for performing the operations of determination block 536 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the MCM misbehavior test module 336.

[0185] In block 506 of the method 500a, the V2X processing system may take action in response to identifying inappropriate behavior associated with the MCM.

[0186] refer to Figures 1A to 5F ,exist Figure 5E In operation 500f shown in FIG. 5 , the V2X processing system may send one or more MCM requests to the remote vehicle to perform the maneuver as described in block 530 .

[0187] In block 542, the V2X processing system may start a timer associated with one or more MCM requests to perform a maneuver sent to the remote vehicle. Means for performing the operations of block 542 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing a response timer module 340.

[0188] In block 544, the V2X processing system may count maneuver request rejections upon expiration of a timer without receiving a response to one or more requests from the remote vehicle. For example, the V2X processing system may increase or add to a counter of the number of maneuver request rejections received from the remote vehicle. Means for performing the operations of block 544 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the RV response evaluation module 344.

[0189] The V2X processing system may then determine in block 532 a number of maneuver request rejections received from the remote vehicle associated with one or more MCM requests sent by the vehicle to the remote vehicle to perform a maneuver and perform the operations in block 506 of method 500a as described.

[0190] refer to Figure 1A to Figure 5G ,exist Figure 5G In operation 500g shown in FIG. 5 , the V2X processing system may determine whether the number of maneuver request rejections satisfies a request rejection threshold as described in determination block 534 .

[0191] In response to determining that the number of maneuver request rejections satisfies the request rejection threshold (i.e., determination block 534 = "Yes"), in determination block 546 the V2X processing system may determine whether the remote vehicle (RV) is unable to respond to one or more MCM requests to perform the maneuver. For example, the V2X processing system may determine whether wireless communication link conditions allow or prevent V2X communication. For example, the V2X processing system may determine that wireless communication link interference, message or signal congestion, or other factors are interfering with V2X communication with the remote vehicle. As another example, the V2X processing system may determine whether the remote vehicle is within communication range based on, for example, information in another V2X message (such as a BSM or CAM), or based on information from one or more sensors of the vehicle (e.g., information from a camera, radar, lidar, and / or the like). Components for performing the operations of determination block 546 may include a processor (e.g., 205, 303, 304, 306, 307, 308, 310) executing the RV response evaluation module 344.

[0192] In response to determining that the remote vehicle is unable to respond (ie, determination block 546 = "Yes"), the V2X processing system may send one or more MCM requests to the remote vehicle to perform the maneuver in block 530 .

[0193] In response to determining that the remote vehicle is able to respond (i.e., determination block 546 = "No", not unable to respond), the V2X processing system may determine whether the remote vehicle is unable to perform operations associated with one or more requests to perform the maneuver in determination block 548. For example, the V2X processing system may determine whether road conditions permit or prevent completion or performance of the maneuver (e.g., based on information in another V2X message, information from vehicle sensors, information from a digital map such as a high-definition map, and / or the like).

[0194] Means for performing the operations of determination block 548 may include a processor (eg, 205 , 303 , 304 , 306 , 307 , 308 , 310 ) executing the RV response assessment module 344 .

[0195] In response to determining that the remote vehicle cannot perform operations associated with the one or more requests to perform the maneuver (ie, determination block 546 = “Yes”), the V2X processing system may send one or more MCM requests to perform the maneuver to the remote vehicle in block 530 .

[0196] In response to determining that the remote vehicle is able to perform operations associated with one or more requests to perform the maneuver (i.e., determination block 546 = "No", not unable to perform the operation), in block 536 the V2X processing system may identify the misbehavior condition and perform operations in block 506 of method 500a as described.

[0197] Figure 6 is a process flow diagram of an example method 600 for misbehavior detection in MCM performed by a processor of a network computing device processing system of a V2X network according to various embodiments. Figures 1A to 6 , method 600 may be performed by one or more processors (e.g., 303, 304, 306, 307, 308, 310, 352) of a network computing device (132, 350), which may be implemented in hardware elements, software elements, or a combination of hardware and software elements.

[0198] In block 602, the network computing device processing system may receive a plurality of misbehavior reports indicating MCM misbehavior from a plurality of vehicles. The components for performing the operations of block 502 may include a processor (e.g., 303, 304, 306, 307, 308, 310, 352) executing the MCM receiving module 334 and the communication interface 356.

[0199] In block 604, the network computing device processing system may identify inconsistencies between the multiple misconduct reports. In some embodiments, identifying inconsistencies between the multiple misconduct reports may include determining that the vehicle is imitating multiple vehicles. In some embodiments, identifying inconsistencies between the multiple misconduct reports may include determining that the vehicle identified in the multiple MCMs did not send misconduct reports to the network computing device. The components for performing the operations of block 502 may include a processor (e.g., 303, 304, 306, 307, 308, 310, 352) executing the inconsistency identification module 362.

[0200] In block 606, the network computing device processing system may identify an inappropriate behavior condition in response to identifying an inconsistency between the plurality of inappropriate behavior reports. The means for performing the operations of block 502 may include a processor (e.g., 303, 304, 306, 307, 308, 310, 352) executing the inappropriate behavior condition module 364.

[0201] In block 608, the network computing device processing system may take action in response to identifying the misbehavior condition. For example, the network computing device processing system may revoke the digital certificate of the determined attacker vehicle to deny the attacker access to the V2X communication network. The means for performing the operations of block 502 may include a processor (e.g., 303, 304, 306, 307, 308, 310, 352) executing the response action module 366.

[0202] In optional block 610, the network computing device processing system may send a request for information related to the identified inconsistencies between the plurality of misconduct reports to the second network computing device. Means for performing the operations of optional block 610 may include a processor (e.g., 303, 304, 306, 307, 308, 310, 352) executing the MCM receiving module 334 and the communication interface 356.

[0203] Figure 7 is a component block diagram of a network computing device 700 suitable for use in various embodiments. Figures 1A to 7 , various embodiments (including but not limited to reference FIG. 4A to FIG. 6 The described embodiments may be implemented on various computing devices. Figure 7An example of which is shown in the form of a server device. The network computing device 700 may include a processor 701 coupled to a volatile memory 702 and a large capacity non-volatile storage such as a disk drive 703. The network computing device 700 may also include a peripheral memory access device such as a floppy disk drive, a compact disk (CD) or a digital video disk (DVD) drive 706 coupled to the processor 701. The network computing device 700 may also include a network access port 704 (or interface) coupled to the processor 701 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 700 may include one or more transceivers 705 for sending and receiving electromagnetic radiation that can be connected to a wireless communication link. The network computing device 700 may include additional access ports for coupling to peripheral devices, external storage or other devices, such as USB, FireWire, Thunderbolt, and the like.

[0204] The following paragraphs describe embodiments. Although some of the following embodiments are described in terms of example methods, further example implementations may include: the example methods discussed in the following paragraphs are implemented by a V2X processing system, which may be a vehicle-mounted unit, a mobile device unit, or a mobile computing unit, or a processing system of a network computing device, including a processor configured with processor-executable instructions to perform the following operations of the method implementing the embodiment; the example methods discussed in the following paragraphs implemented by a vehicle V2X processing system or a processing system of a network computing device include components for performing the functions of the method implementing the embodiment; and the example methods 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 processing system or the processing system of the network computing device to perform the following operations of the method implementing the embodiment.

[0205] Embodiment 1. A method for detecting improper behavior of mobile coordination messages performed by a vehicle's vehicle-to-everything (V2X) processing system, comprising: receiving a first mobile coordination message; performing a improper behavior test on the first mobile coordination message; and taking action in response to the test identifying improper behavior associated with the first mobile coordination message.

[0206] Embodiment 2. A method according to embodiment 1, wherein: receiving a first mobile coordination message includes receiving a first mobile coordination including a first field and a second field; and performing a misbehavior test on the first mobile coordination message, and taking action in response to the test identifying misbehavior associated with the first mobile coordination message includes: sending a message associated with the received first mobile coordination message, which includes an indication that information in the first field is inconsistent with information in the second field.

[0207] Embodiment 3. A method according to any one of embodiments 1 to 2, wherein performing a misbehavior test on a first mobile coordination message comprises: determining whether first information in one or more first fields of the first mobile coordination message is inconsistent with second information in one or more second fields of the first mobile coordination message; and in response to determining that the first information in one or more first fields of the first mobile coordination message is inconsistent with the second information in one or more second fields of the first mobile coordination message, determining that a misbehavior condition exists in the first mobile coordination message.

[0208] Embodiment 4. A method according to any one of embodiments 1 to 3, wherein performing a misbehavior test on the first motor coordination message comprises: determining whether information in a first motor coordination message type field is inconsistent with the presence or absence of one or more second fields.

[0209] Embodiment 5. The method according to any one of embodiments 1 to 4, wherein performing a misbehavior test on the first maneuver coordination message comprises: determining whether information in a TRR location field is inconsistent with the message in a TRR type field.

[0210] Embodiment 6. A method according to any one of embodiments 1 to 5, wherein performing a misbehavior test on the first mobile coordination message includes: determining whether information in the performer ID field is inconsistent with information in the source ID field or information in the destination ID field.

[0211] Embodiment 7. The method according to any one of embodiments 1 to 6, wherein performing a misbehavior test on the first maneuver coordination message comprises: determining whether information in the maximum speed field is inconsistent with the TRR position field.

[0212] Embodiment 8. A method according to any one of embodiments 1 to 7, wherein performing a misbehavior test on a first maneuver coordination message includes: determining whether first information in one or more fields related to a scheduled maneuver of the vehicle is inconsistent with second information in one or more second fields related to the scheduled maneuver of the vehicle.

[0213] Embodiment 9. A method according to any one of embodiments 1 to 8, wherein performing a misbehavior test on a first maneuver coordination message includes: determining whether first information in one or more fields related to a scheduled maneuver of the vehicle or second information in one or more second fields related to a scheduled maneuver of the vehicle exceeds a threshold.

[0214] Embodiment 10. A method according to any one of embodiments 1 to 9, wherein performing a misbehavior test on a first maneuver coordination message includes: determining whether first information in one or more fields related to a scheduled maneuver of the vehicle or second information in one or more second fields related to a scheduled maneuver of the vehicle indicates an overlap of TRRs.

[0215] Embodiment 11. The method according to any one of embodiments 1 to 9 further includes: receiving a second mobile coordination message; determining whether the first information in the first mobile coordination message is inconsistent with the second information in the second mobile coordination message; and identifying an inappropriate behavior condition in response to determining that the first information in the first mobile coordination message is inconsistent with the second information in the second mobile coordination message.

[0216] Embodiment 12. The method according to any one of embodiments 1 to 11, wherein the first motorized coordination message and the second motorized coordination message are not in sequence.

[0217] Embodiment 13. A method according to any one of embodiments 1 to 12, wherein performing a misbehavior test on a first maneuver coordination message includes determining a number of maneuver request rejections received from a remote vehicle associated with one or more requests to perform a maneuver sent by the vehicle to the remote vehicle; and identifying a misbehavior condition in response to determining that the number of maneuver request rejections satisfies a request rejection threshold.

[0218] Embodiment 14. The method according to embodiment 13 further includes: starting a timer associated with one or more requests to perform a maneuver sent to a remote vehicle; and increasing the number of maneuver request rejections when the timer expires without receiving a response to the one or more requests from the remote vehicle.

[0219] Embodiment 15. The method according to embodiment 13 further includes: determining whether the remote vehicle is unable to respond to one or more requests to perform a maneuver; and determining whether the remote vehicle is unable to perform operations related to one or more requests to perform a maneuver, wherein identifying the improper behavior condition in response to determining that the number of maneuver request rejections meets a request rejection threshold includes: identifying the improper behavior condition in response to determining that the remote vehicle is able to respond to one or more requests to perform a maneuver, and the remote vehicle is able to perform operations related to one or more requests to perform a maneuver.

[0220] Embodiment 16. A method for detecting misbehavior in maneuvering coordination messages performed by a network computing device processing system of a vehicle-to-everything (V2X) network, comprising: receiving multiple misbehavior reports indicating misbehavior in maneuvering coordination messages from multiple vehicles; identifying inconsistencies between the multiple misbehavior reports; identifying a misbehavior condition in response to identifying the inconsistency between the multiple misbehavior reports; and taking action in response to identifying the misbehavior condition.

[0221] Embodiment 17. The method of embodiment 16, wherein identifying inconsistencies between multiple reports of misconduct includes: identifying a vehicle that imitates multiple vehicles.

[0222] Embodiment 18. The method of any one of Embodiments 16 to 17, wherein identifying inconsistencies between multiple misbehavior reports includes identifying that a vehicle identified in multiple maneuver coordination messages did not send a misbehavior report to the network computing device.

[0223] Embodiment 19. The method of any one of Embodiments 16 to 18 further comprises sending a request to a second network computing device for information related to inconsistencies between the identified plurality of misconduct reports.

[0224] The various embodiments shown and described are provided as examples only to illustrate the various features of 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 by any one example embodiment. For example, one or more operations of the method may replace or be combined with one or more operations of the method.

[0225] The foregoing method description and process flow chart are provided only as illustrative embodiments, and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. 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 "afterwards", "then", "next step", etc. are not intended to limit the order of operations; these words are only used to guide the reader to understand the description of the method. In addition, any reference to a claim element in the singular, for example, the use of the article "one", "an" or "the" should not be interpreted as limiting the element to the singular.

[0226] The various illustrative 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 illustrative components, blocks, modules, circuits, and operations have been generally described above with respect to their functions. Whether these functions are implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The technician may implement the described functions in various ways for each specific application, but such implementation decisions should not be interpreted as resulting in a departure from the scope of the claims.

[0227] The hardware for implementing the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a 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. A general purpose processor may be a microprocessor, but alternatively, 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 in combination with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.

[0228] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transitory computer-readable medium or a non-transitory 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-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. As an example and not limitation, such non-transitory 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 devices, or any other medium that can be used to store the required program code in the form of instructions or data structures and can be accessed by a computer. The disks and optical disks used herein include CDs (CDs), laser optical disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where disks typically copy data magnetically, while optical disks copy data optically by lasers. The above combinations are also included within the scope of non-transitory computer-readable and processor-readable media. Furthermore, 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.

[0229] The foregoing description of the disclosed embodiments is provided to enable those 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. Therefore, the present disclosure is not intended to be limited to the embodiments shown herein, but is to be consistent with the widest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A vehicle-to-everything (V2X) processing system, comprising: a transceiver configured to receive a maneuver coordination message; as well as a processor coupled to the transceiver and configured to: receiving a first maneuver coordination message; performing a misbehavior test on the first mobile coordination message; and In response to the test identifying inappropriate behavior associated with the first motor coordination message, an action is taken.

2. The V2X processing system according to claim 1, wherein the processor is further configured to: performing a misbehavior test on the first motor coordination message by determining whether the first field and the second field are inconsistent; and The action is taken in response to the test identifying improper behavior associated with the first motor coordination message by sending a message associated with the first motor coordination message that includes an indication that information in the first field is inconsistent with information in the second field.

3. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by: determining whether first information in one or more first fields of the first motor coordination message is inconsistent with second information in one or more second fields of the first motor coordination message; and In response to determining that the first information in the one or more first fields of the first motor coordination message is inconsistent with the second information in the one or more second fields of the first motor coordination message, it is determined that a misbehavior condition exists in the first motor coordination message.

4. The V2X processing system of claim 1 , wherein the processor is further configured to perform the misbehavior test on the first maneuver coordination message by determining whether information in the first maneuver coordination message type field is inconsistent with the presence or absence of one or more second fields.

5. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by determining whether information in a target road resource (TRR) location field is inconsistent with the message in a TRR type field.

6. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by determining whether information in a performer ID field is inconsistent with information in a source ID field or information in a destination ID field.

7. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by determining whether information in a maximum speed field is inconsistent with a target road resource (TRR) location field.

8. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by determining whether first information in one or more fields associated with a scheduled maneuver of a vehicle is inconsistent with second information in one or more second fields associated with the scheduled maneuver of the vehicle.

9. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by determining whether first information in one or more fields related to a scheduled maneuver of a vehicle or second information in one or more second fields related to the scheduled maneuver of the vehicle exceeds a threshold.

10. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by determining whether first information in one or more fields associated with a predetermined maneuver of a vehicle or second information in one or more second fields associated with the predetermined maneuver of the vehicle indicates an overlap of a target road resource (TRR).

11. The V2X processing system according to claim 1, wherein the processor is further configured to: receiving a second maneuver coordination message; determining whether first information in the first maneuvering coordination message is inconsistent with second information in the second maneuvering coordination message; and In response to determining that the first information in the first maneuver coordination message is inconsistent with the second information in the second maneuver coordination message, a misbehavior condition is identified.

12. The V2X processing system of claim 11, wherein the first maneuvering coordination message and the second maneuvering coordination message are out of sequence.

13. The V2X processing system of claim 1 , wherein the processor is further configured to perform a misbehavior test on the first maneuver coordination message by: determining a number of maneuver request rejections received from a remote vehicle associated with one or more requests sent by the vehicle to perform a maneuver to a remote vehicle; and In response to determining that the number of maneuver request denials satisfies a request denial threshold, a misbehavior condition is identified.

14. The V2X processing system according to claim 13, wherein the processor is further configured to: starting a timer associated with the one or more requests sent to the remote vehicle to perform a maneuver; and The number of maneuver request denials is increased upon expiration of a timer without receiving a response to the one or more requests from the remote vehicle.

15. The V2X processing system according to claim 13, wherein the processor is further configured to: determining whether the remote vehicle is unable to respond to the one or more requests to perform the maneuver; and determining whether the remote vehicle is unable to perform operations associated with the one or more requests to perform the maneuver, The processor is further configured to identify the misbehavior condition in response to determining that the remote vehicle is capable of responding to the one or more requests to perform the maneuver and that the remote vehicle is capable of performing operations related to the one or more requests to perform the maneuver, and further identify the misbehavior condition in response to determining that the number of maneuver request rejections satisfies the request rejection threshold.

16. A method for misbehavior detection in maneuver coordination messages performed by a vehicle-to-everything (V2X) processing system of a vehicle, comprising: receiving a first maneuver coordination message; performing a misbehavior test on the first mobile coordination message; as well as In response to the test identifying the inappropriate behavior associated with the first maneuver coordination message, an action is taken.

17. The method of claim 16, wherein: Receiving the first motorized coordination message includes: receiving a first motorized coordination message including a first field and a second field; and Performing the misbehavior test on the first mobile coordination message, and taking the action in response to the test identifying misbehavior associated with the first mobile coordination message includes: sending a message associated with the received first mobile coordination message, which includes an indication that information in the first field is inconsistent with information in the second field.

18. The method of claim 16, wherein performing the misbehavior test on the first maneuver coordination message comprises: determining whether first information in one or more first fields of a first motorized coordination message is inconsistent with second information in one or more second fields of the first motorized coordination message; as well as In response to determining that the first information in the one or more first fields of the first motor coordination message is inconsistent with the second information in the one or more second fields of the first motor coordination message, it is determined that a misbehavior condition exists in the first motor coordination message.

19. The method of claim 16, wherein performing the misbehavior test on the first maneuver coordination message comprises: A determination is made as to whether information in the first motor coordination message type field is inconsistent with the presence or absence of one or more second fields.

20. The method of claim 16, wherein performing a misbehavior test on the first maneuver coordination message comprises: Determine if the information in the Target Road Resource (TRR) Location field is inconsistent with the message in the TRR Type field.

21. The method of claim 16, wherein performing a misbehavior test on the first maneuver coordination message comprises: It is determined whether the information in the performer ID field is inconsistent with the information in the source ID field or the information in the destination ID field.

22. The method of claim 16, wherein performing the misbehavior test on the first maneuver coordination message comprises: A determination is made as to whether information in the Maximum Speed ​​field is inconsistent with a Target Road Resource (TRR) Location field.

23. The method of claim 16, wherein performing the misbehavior test on the first maneuver coordination message comprises: A determination is made as to whether first information in one or more fields associated with a scheduled maneuver of the vehicle is inconsistent with second information in one or more second fields associated with the scheduled maneuver of the vehicle.

24. The method of claim 16, wherein performing the misbehavior test on the first maneuver coordination message comprises: A determination is made as to whether first information in one or more fields associated with a scheduled maneuver of the vehicle or second information in one or more second fields associated with the scheduled maneuver of the vehicle exceeds a threshold.

25. The method of claim 16, wherein performing the misbehavior test on the first maneuver coordination message comprises: A determination is made as to whether first information in one or more fields associated with the scheduled maneuver of the vehicle or second information in one or more second fields associated with the scheduled maneuver of the vehicle indicates an overlap of target road resources (TRRs).

26. The method of claim 16, further comprising: receiving a second maneuver coordination message; determining whether first information in the first mobility coordination message is inconsistent with second information in the second mobility coordination message; as well as In response to determining that the first information in the first maneuver coordination message is inconsistent with the second information in the second maneuver coordination message, a misbehavior condition is identified.

27. The method of claim 26, wherein the first motorized coordination message and the second motorized coordination message are out of sequence.

28. The method of claim 16, wherein performing a misbehavior test on the first maneuver coordination message comprises: determining a number of maneuver request rejections received from the remote vehicle associated with one or more requests sent by the vehicle to perform a maneuver to a remote vehicle; as well as In response to determining that the number of maneuver request denials satisfies a request denial threshold, a misbehavior condition is identified.

29. The method according to claim 28, further comprising: starting a timer associated with the one or more requests sent to the remote vehicle to perform a maneuver; as well as The number of maneuver request denials is increased upon expiration of a timer without receiving a response to the one or more requests from the remote vehicle.

30. The method of claim 28, further comprising: determining whether the remote vehicle is unable to respond to the one or more requests to perform the maneuver; as well as determining whether the remote vehicle is unable to perform operations associated with the one or more requests to perform the maneuver, Wherein identifying the improper behavior condition in response to determining that the number of maneuver request rejections satisfies the request rejection threshold includes: identifying the improper behavior condition in response to determining that the remote vehicle is capable of responding to the one or more requests to perform the maneuver and the remote vehicle is capable of performing operations related to the one or more requests to perform the maneuver.

31. A network computing device for a vehicle-to-everything (V2X) network, comprising: The processor is configured as: receiving a plurality of misconduct reports from a plurality of vehicles indicating maneuver coordination message misconduct; identifying inconsistencies among the multiple reports of misconduct; identifying a misconduct condition in response to identifying the inconsistency between the plurality of misconduct reports; as well as Action is taken in response to identifying the inappropriate behavior condition.

32. The network computing device of claim 31, wherein the processor is further configured to identify the inconsistencies between the plurality of misconduct reports by identifying a vehicle that mimics a plurality of vehicles.

33. The network computing device of claim 31, wherein the processor is further configured to identify the inconsistency between the plurality of misbehavior reports by identifying that a vehicle identified in the plurality of maneuver coordination messages did not send a misbehavior report to the network computing device.

34. The network computing device of claim 31, wherein the processor is further configured to send a request to a second network computing device for information related to the identified inconsistencies between the plurality of misconduct reports.

35. A method for misbehavior detection in maneuver coordination messages performed by a network computing device processing system of a vehicle-to-everything (V2X) network, comprising: receiving a plurality of misconduct reports from a plurality of vehicles indicating maneuver coordination message misconduct; identifying inconsistencies among the multiple reports of misconduct; identifying a misconduct condition in response to identifying the inconsistency between the plurality of misconduct reports; as well as Action is taken in response to identifying the inappropriate behavior condition.

36. The method of claim 35, wherein identifying the inconsistencies between the plurality of misconduct reports comprises: Identifies a vehicle that mimics multiple vehicles.

37. The method of claim 35, wherein identifying the inconsistencies between the plurality of misconduct reports comprises: Identify that a vehicle identified in the plurality of maneuver coordination messages has not sent a misbehavior report to the network computing device.

38. The method of claim 35, further comprising sending a request to a second network computing device for information related to the identified inconsistencies between the plurality of misconduct reports.

Images