Method and apparatus for vehicle-to-vehicle communication

Abstract

Methods and apparatus for vehicle-to-vehicle communications. Logic may implement protocols and processes for vehicle-to-vehicle communications to perform platooning. Logic may implement a communication topology to distinguish time-critical communications from non-time-critical communications. Logic may sign time-critical communications with a message authentication code (MAC) algorithm with a hash function, such as a Keccak MAC or a password-based MAC. Logic may generate a MAC based on a pairwise symmetric key to sign time-critical communications. Logic may sign non-time-critical communications with a digital signature. Logic may encrypt non-time-critical communications. Logic may attach a certificate to non-time-critical communications. Logic may attach a header to a message to create a data packet and may include a packet type to identify a time-critical communication. Logic may decode and verify time-critical messages with a pairwise symmetric key. And logic may prioritize time-critical communications to meet specified delays.

Description

Technical Field

[0001] Embodiments are in the field of secure wireless communications. More particularly, embodiments may implement communication protocols and processes for vehicle-to-vehicle communications. Background Art

[0002] Institute of Electrical and Electronics Engineers (IEEE) 1609.2 TM The standard "Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages", IEEE Vehicular Technology Society, January 29, 2016, defines secure message formats and processes for use by Wireless Access in Vehicular Environments (WAVE) devices, including methods for protecting WAVE management messages and methods for protecting application messages. IEEE 1609.2 TM A security architecture for vehicle networks is proposed to protect vehicle communications from cyber attacks. More specifically, IEEE 1609.2 TM The use of digital signatures to protect the authenticity and integrity of vehicle-to-everything (V2X) messages and the use of certificates to guarantee peer authentication are proposed.

[0003] One application for vehicle-to-vehicle (V2V) communications involves platooning. Platooning refers to vehicles (such as cars or trucks) forming a group (usually in a row) on a road to reduce fuel consumption, improve traffic management, reduce road congestion, improve the commuting experience, and / or increase safety. Platooning requires participating vehicles to coordinate through V2V communications to form a platoon of closely spaced vehicles driving at nearly the same speed. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1A An embodiment of a wireless network for supporting vehicle-to-vehicle communications for vehicle platooning is depicted;

[0005] Figure 1B Depicted is a vehicle comprising five vehicles (such as Figure 1A Embodiments of a convoy communication topology for a vehicle (as shown in FIG. 4 );

[0006] Figure 1C Depicts a vehicle controller (such as in Figure 1A An embodiment of the vehicle controller illustrated in FIG.

[0007] Figure 1D Describes a method for transmitting vehicle information (such as Figure 1A An embodiment of data packet of a vehicle controller as shown in FIG.

[0008] Figure 1E Describes a method for supporting a platoon of vehicles (such as in Figure 1B Embodiments of a platooning application architecture for vehicle-to-vehicle communication of a vehicle fleet (as shown in FIG. 1 );

[0009] Figure 1F -G describes the use for time-critical and non-time-critical messages (such as combined Figure 1A Embodiments of data packet security for transmission of data packets discussed above;

[0010] Figure 2 An embodiment of an apparatus for supporting vehicle-to-vehicle communications for vehicle platooning is depicted;

[0011] Figure 3A -B depicts an embodiment of a flow chart for encoding and decoding vehicle-to-vehicle communications for vehicle platooning; and

[0012] Figure 4-5 Embodiments of a storage medium for storing code to support vehicle-to-vehicle communications for vehicle platooning and a computing platform for executing vehicle-to-vehicle communications for vehicle platooning are depicted. DETAILED DESCRIPTION

[0013] The following is a detailed description of the embodiments depicted in the accompanying drawings. The detailed description covers all modifications, equivalents, and alternatives coming within the scope of the appended claims.

[0014] Embodiments may include fleet logic circuitry for performing the fleet-related functions discussed herein. The fleet logic circuitry includes hardware and possibly code, such as fleet platooning logic for a vehicle, a processor for executing code for the fleet platooning logic, a microcontroller for executing microcode for the fleet platooning logic, an application specific integrated circuit, a state machine, a wireless network interface, and / or the like. The fleet platooning logic may include any one or more forms of code, such as software, firmware, microcode, or the like, to perform some or all of the fleet-related functions discussed herein in conjunction with the fleet logic circuitry.

[0015] Some embodiments include vehicles such as cars or trucks. The platooning logic circuit system can implement vehicle-to-vehicle (V2V) communications according to the platooning application architecture. In some embodiments, the architecture includes a hybrid system for security of platooning communications. In one embodiment, the platooning logic circuit system includes a first system for security of time critical messages and a second system for security of non-time critical messages. The message is a data packet that includes a header for identifying the data packet and a payload that includes mission-related data (such as sensor data or fleet data).

[0016] The fleet application architecture may include a fleet startup layer, an operations layer, and a management layer. In many embodiments, the fleet application architecture includes a fleet startup layer, an operations layer, a basic mobility layer, and a management layer. In other embodiments, the fleet application architecture includes a fleet startup layer, an operations layer, a basic mobility layer, an advanced mobility layer, and a management layer.

[0017] In many embodiments, the operational layer may use the BSM data packets standardized by SAE 2735 to transmit basic safety information related to the platoon. In other embodiments, the operational layer includes the basic information required to maintain the relative longitudinal and lateral positions of the vehicles participating in the platoon. The operational layer tasks may involve the transmission of high priority information (such as position, speed, velocity, acceleration, heading, road curvature) in the data packets. Other embodiments may include different data from vehicle sensors so that the vehicles participating in the platoon maintain their longitudinal and lateral control as deemed necessary by the vehicle controller 1020.

[0018] Several embodiments impose a 100 millisecond end-to-end latency (E2EL) requirement on communications of operational layer tasks based on generating data packets related to time-critical operational layer tasks by decoding the data packets by participating vehicles of the convoy. Other embodiments impose different E2ELs on operational layer tasks. Some embodiments impose E2ELs on one or more of basic maneuvering tasks, advanced maneuvering tasks, and / or management layer tasks. In many embodiments, the fleet logic circuit system performs operational layer tasks continuously or periodically (such as 10 times per second or a 10 Hertz (Hz) information refresh rate in the fleet) to ensure fine granularity of control over the positioning of each of the vehicles in the fleet and maintain stability of the fleet.

[0019] Some embodiments define non-time critical information as all communications related to a platoon of vehicles. Some embodiments may distinguish data packets related to an operational layer task by assigning a packet type to a data packet transmission related to an operational layer task. The value included for the packet type may distinguish data packets related to an operational layer task from data packets related to a different layer task. For example, a fleet logic circuit system may transmit a data packet related to an operational layer task, the data packet including a packet type field having a value that identifies the data packet as a time critical packet type, a BSM packet type, an operational layer task, or a task that a recipient fleet logic circuit system may identify as an operational layer task. In some embodiments, multiple packet types are associated with an operational layer task and each packet type identifies the data packet as a time critical packet. In other embodiments, one packet type is associated with an operational layer task. In other embodiments, the data packet includes a packet type field in a header of the data packet or a bit in another position in a header or frame body of the data packet indicating that the data packet is time critical.

[0020] The basic maneuvering layer may include tasks for changing the basic operation of the fleet, such as changing gaps, changing speeds, moving laterally, and / or moving longitudinally. Some of these tasks include longitudinal and lateral movements performed by operational layer tasks, and some of these tasks are time critical even though the basic maneuvering tasks are generally not time critical. Data packets associated with basic maneuvering layer tasks may include a packet type that identifies the data packet as non-time critical, as a non-operational layer task, as a time critical operational layer task, or as a time critical operational layer task that is part of the basic maneuvering layer task. In one embodiment, the packet type identifies the data packet associated with the basic maneuvering layer task as a basic maneuvering layer task. In some embodiments, generally, an upper layer task may invoke an operational layer task that is time critical, and therefore, the data packet associated with the time critical task includes an indication, such as a value in the packet type that identifies the data packet as time critical despite being invoked by an upper layer.

[0021] The high-level maneuvering layer may include tasks for merging convoys and / or splitting convoys. While some of these tasks include longitudinal and lateral movements performed by the high-level maneuvering layer tasks that are time-critical, some data packets associated with the high-level maneuvering layer tasks may be non-time-critical because the overall maneuver is not time-critical. Therefore, data packets associated with the high-level maneuver may also include a packet type that identifies the data packet as non-time-critical.

[0022] The management layer may include tasks for fleet admission, fleet removal, leader change, and / or member management that are not time critical. Data packets associated with management layer tasks may include packet types that identify the data packets as not time critical, but may also include data packets that are time critical, such as data packets that implement operational layer tasks.

[0023] During convoy startup, the convoy platoon logic circuit system can identify one vehicle as the leader and the remaining vehicles by location within the convoy. In several embodiments, the leader communicates with all other vehicles participating in the convoy and exchanges pairwise symmetric keys with each of the vehicles participating in the convoy. In other words, the leader can exchange different symmetric keys with each of the follower vehicles. For security reasons, the convoy platoon logic circuit system can perform the key exchange over an out-of-band communication network or via another secure communication process. Such a key exchange can occur during convoy startup or in response to changes to participating vehicles in the convoy via communications related to management tasks.

[0024] Vehicles in a convoy that are not the leader are follower vehicles and can communicate with at least one other vehicle in the convoy. For security, the convoy platooning logic circuitry of each follower vehicle can exchange pairwise symmetric keys with at least one other vehicle via communications related to management tasks during convoy startup or if a vehicle is added to the convoy, removed from the convoy, or changes position within the convoy. In several embodiments, each vehicle in the convoy communicates with the leader vehicle and the following vehicles except the last vehicle in the convoy.

[0025] During operation of the convoy, the convoy continuously or periodically adjusts speed and acceleration to maintain a target inter-vehicle distance and a target convoy speed. The convoy platoon logic circuit system receives sensor data related to longitudinal and lateral motion, and periodically generates and transmits communications related to operational layer tasks to maintain convoy speed and formation. In several embodiments, the lead vehicle generates communications related to operational layer tasks for transmission to all follower vehicles. In such an embodiment, the lead vehicle may determine a data packet to be transmitted, and perform one or more hash operations for each follower vehicle to generate a message authentication code (MAC) using a cryptographic hash function and a secret cryptographic key associated with the follower vehicle. For example, if 20 vehicles participate in the convoy, the convoy logic circuit system of the lead vehicle may have 19 pairwise symmetric keys, one for each follower vehicle, may generate data packets for sharing with each of the follower vehicles, and may sign the data packets using 19 different message authentication codes (MACs), one MAC for each of the 19 follower vehicles. The leader's platooning logic circuitry may generate a MAC for each follower vehicle using the pairwise symmetric key associated with the follower vehicle and include the MAC when transmitting data packets.

[0026] The follower vehicles may have a pairwise symmetric key for the leader vehicle and a pairwise symmetric key for at least one other vehicle participating in the platoon. Upon receiving a data packet from the leader vehicle, each follower vehicle may verify a MAC associated with the follower vehicle's pairwise symmetric key for the leader vehicle and process data in a payload of the data packet if the MAC verifies the data packet. In several embodiments, the leader's platooning logic circuitry does not encrypt data packets for operational layer tasks. In other embodiments, the platooning logic circuitry encrypts data packets for operational layer tasks.

[0027] The platoon logic circuitry of the follower vehicle may generate a data packet, sign the data packet with a MAC based on a pairwise symmetric key for at least one other vehicle, and transmit the data packet with the MAC to at least one other vehicle in the participating platoon. For example, each follower vehicle may transmit a data packet with a MAC to the vehicle using a pairwise symmetric key shared with the vehicle immediately behind. In some embodiments, the platoon logic circuitry hashes the concatenation of the data packet and the symmetric key with a Keccak MAC (KMAC), such as Keccak-224, Keccak-256, Keccak-384, Keccak-512, SHA3-224, SHA3-256, SHA3-384, and / or SHA3-512.

[0028] Embodiments may include wireless communications within a frequency band of about 5.9 GHz and may vary between 5.855 GHz and 5.905 GHz, between 5.855 GHz and 5.925 GHz, between 5.770 GHz and 5.850 GHz, between 715 MHz and 725 MHz, or a combination thereof, where GHz represents gigahertz and MHz represents megahertz. Other embodiments focus on other bandwidths in the same or other frequency bands. However, embodiments are not limited to the bandwidths and frequency bands described herein.

[0029] Some embodiments are particularly directed to improvements to V2V and V2X wireless communications, such as one or more Institute of Electrical and Electronics Engineers (IEEE) standards. Such standards may include, for example, Institute of Electrical and Electronics Engineers (IEEE) 1609.2 TM Standard “Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages”, IEEE Vehicular Technology Society, January 29, 2016. The embodiments are not limited to these.

[0030] Many embodiments facilitate wireless communications according to multiple standards. Some embodiments may include low-power wireless communications such as Bluetooth, cellular communications, Wi-Fi, roadside units (RSUs), backend networks (BENs), and other messaging systems. In addition, some wireless embodiments may include a single antenna, while other embodiments may employ multiple antennas or antenna elements.

[0031] Although some of the specific embodiments described below will refer to embodiments having specific configurations, those skilled in the art will recognize that the embodiments of the present disclosure may be advantageously implemented with other configurations having similar issues or problems.

[0032] Various embodiments may be designed to address different technical issues associated with platooning. Other technical issues may include implementing security measures for time-critical messages; ensuring, for example, 100 milliseconds of end-to-end latency E2EL for time-critical messages; tightly coupled collective behavior of vehicles in a platoon such that the behavior of one vehicle triggers a nearly instantaneous response in all other vehicles of the platoon; handling of various road and traffic conditions by the platoon; performing multiple driving maneuvers by the platoon; managing the platoon such that the collective benefits of the platoon outweigh the costs of establishing and maintaining the platoon; implementing security measures for vehicle-to-vehicle (V2V) communications within the platoon to protect the platoon from adversarial attacks; maintaining a stable platoon during the performance of time-critical and non-time-critical tasks; implementing a security architecture that meets security goals, performs multiple time-critical tasks within the E2EL, and / or maintains a stable platoon; and / or the like.

[0033] Different technical problems, such as those discussed above, can be solved by one or more different embodiments. For example, some embodiments that solve problems associated with platooning can do so by one or more different technical means, such as implementing a communication topology that distinguishes between time-critical and non-time-critical data packets; implementing a communication topology that facilitates E2EL for multiple data packets during, for example, 100 milliseconds of E2EL for the stability of the platoon; signing time-critical communications with a message authentication code (MAC) algorithm; generating a MAC based on a pairwise symmetric key to sign time-critical communications; signing non-time-critical communications with a digital signature; encrypting non-time-critical communications; attaching a certificate to non-time-critical communications; attaching a header including a packet type to identify time-critical communications; decoding time-critical data packets with a pairwise symmetric key; prioritizing time-critical communications to meet specified delays; and the like.

[0034] Several embodiments include systems with multiple processor cores such as a central server, access points and / or stations (STAs) such as modems, routers, switches, servers, workstations, netbooks, mobile devices (laptops, smartphones, tablets, and the like), sensors, meters, controls, instruments, monitors, Internet of Things (IoT) devices (watches, glasses, headphones, and the like), and the like. In various embodiments, these devices relate to specific applications, such as vehicle applications (cars, autonomous vehicles, aircraft, and the like), and the like.

[0035] Now go to Figure 1A and Figure 1B , Figure 1AAn embodiment 1000 of a wireless network 1000 for supporting vehicle-to-vehicle (V2V) communications for vehicle platooning is illustrated. A plurality of vehicles 1010, 1030, 1090, 1092, and 1094 illustrate embodiments of wireless communication devices installed in or that may be installed in vehicles to facilitate communication of platoon data packets between vehicles and active or passive control of vehicle operations such as acceleration, deceleration, braking, and / or steering. For purposes of discussion, the wireless communication devices are labeled "vehicles" to describe examples of functionality and operation for situations encountered during the establishment, maintenance, and termination of a platoon.

[0036] Vehicles 1010 and 1030 illustrate embodiments of wireless communication devices for installation in cars, trucks, or other vehicles to facilitate wireless V2V communications for platooning. Vehicles 1010 and 1030 include processor(s) 1001 and 1031, TSF timers 1005 and 1035, memories 1011 and 1041, platoon logic circuitry 1018 and 1048, wireless network interfaces 1022 and 1052, and out-of-band network interfaces 1029 and 1059, respectively. Some embodiments do not include out-of-band network interfaces 1029 and 1059 or at least do not implement these out-of-band network interfaces 1029 and 1059 in V2V communications for platooning. Other embodiments may implement out-of-band network interfaces 1029 and 1059 to facilitate, for example, the exchange of symmetric keys between vehicles.

[0037] Fleet logic circuitry (such as fleet logic circuitry 1018 and 1048) of vehicles 1010, 1030, 1090, 1092, and 1094 may include media access control layer logic circuitry or higher communication layer circuitry operating with the media access layer logic circuitry to implement fleet startup and safety protocols for V2V communications. Fleet startup and safety protocols for V2V communications may differ based on the participants in fleet 1100. If fleet 1100 includes vehicles that are part of or members of an organization (such as a company), the fleet startup process may begin before the vehicles move, and the safety protocols may involve fewer or no privacy considerations when compared to an ad hoc fleet of vehicles currently operating on road 1110 or an ad hoc fleet of vehicles that are members of a platooning service. In addition, vehicles in an organization may have fewer vehicle-to-vehicle variations, such as size, acceleration capabilities, weight, braking capabilities, and the like, when compared to an ad hoc fleet that may have to share more detailed information about each vehicle involved in the fleet.

[0038] The convoy initiation involves determining that a convoy is formed by a group of vehicles 1010, 1030, 1090, 1092, and 1094 that are or will be on road 1110. Each vehicle that will participate in convoy 1100 may receive and store a pairwise symmetric key from two or more other vehicles that will participate in convoy. The keys may facilitate the security of communication of time-critical data packets between vehicles. For example, Figure 1B An embodiment of a convoy 1100 of vehicles 1010, 1030, 1090, 1092, and 1094 on a road 1110 driving from left to right is illustrated. In the convoy 1100, vehicle 1010 is a leader vehicle having a vehicle ID equal to one, vehicle 1030 is a follower vehicle having a vehicle ID equal to two, vehicle 1090 is a follower vehicle having a vehicle ID equal to three, vehicle 1092 is a follower vehicle having a vehicle ID equal to four, and vehicle 1094 is a follower vehicle having a vehicle ID equal to five. To start the convoy 1100, vehicles 1010, 1030, 1090, 1092, and 1094 may exchange or receive pairwise symmetric keys for the other vehicles that each vehicle will use to communicate.

[0039] In some embodiments, the leader vehicle 1010 communicates with each of the follower vehicles in the convoy 1100. In such an embodiment, vehicles 1010 and 1030 receive key 12 of a pairwise symmetric key shared by vehicles 1010 and 1030 to facilitate V2V communication. Similarly, vehicles 1010 and 1090 receive key 13, vehicles 1010 and 1092 receive key 14, and vehicles 1010 and 1094 receive key 15. In other embodiments, the leader vehicle does not communicate with all other vehicles in the convoy 1100. For example, each vehicle may communicate with neighboring vehicles. In other embodiments, the convoy 1100 may include a leader vehicle, one or more sub-leader vehicles, and one or more follower vehicles for each sub-leader vehicle. In such an embodiment, the leader vehicle may communicate with each of the sub-leader vehicles, and each sub-leader vehicle may communicate with a different sub-group of the follower vehicles of the convoy. In such an embodiment, the leader vehicle 1010 may be a sub-leader of a larger convoy, and the follower vehicles 1030, 1090, 1092, and 1094 in the convoy 1100 may include a sub-group of followers that are part of the larger convoy, wherein the larger convoy includes two or more sub-leaders, and in some embodiments, the leader vehicle is used to communicate with each of the sub-leader vehicles and coordinate the convoy movement of each of the sub-leader vehicles.

[0040] In this embodiment, each of vehicles 1010, 1030, 1090, 1092, and 1094 can also communicate with the preceding vehicle in convoy 1100, so each of the neighboring vehicles receives a pairwise symmetric key. In particular, vehicles 1030 and 1090 receive key 23, vehicles 1090 and 1092 receive key 34, and vehicles 1092 and 1094 receive key 45. In some embodiments, the symmetric keys of the pair are the same. For example, vehicle 1010 may receive key 12, which is the same as key 12 received by vehicle 1030.

[0041] The platoon logic circuitry (such as platoon logic circuitry 1018 and 1048) of vehicles 1010, 1030, 1090, 1092, and 1094 may implement platoon formation. Platoon formation involves a series of platoon maneuvers to achieve a desired platoon formation. The platoon logic circuitry may perform platoon formation by a series of vehicle movements in a manual, semi-automatic, or automatic manner. The complexity of the maneuvers that the vehicles perform to form platoon 1100 varies depending on the circumstances. For example, forming a platoon from cars or trucks in a garage involves different actions than forming a platoon from vehicles already in motion on a road or highway.

[0042] In several embodiments involving ad hoc convoy formation, the lead vehicle 1010 of the convoy may be the vehicle in the forward-most position on the road 1110, and the convoy logic circuitry 1018 of the lead vehicle 1010 may coordinate and establish the convoy 1100 by coordinating a series of longitudinal and lateral vehicle maneuvers by each of the vehicles participating in the convoy 1100. In other embodiments, the convoy logic circuitry of the vehicles participating in the convoy 1100 may select the lead vehicle 1010 based on other criteria, such as based on the destinations of the vehicles participating in the convoy 1100, the presence of which may maintain the lead vehicle throughout the convoy 1100. As another example, an organization or convoy platooning service may select a leader based on the destination of the vehicle or other criteria.

[0043] After forming platoon 1100, platoon logic circuitry 1018 may coordinate changes in speed, direction, acceleration, deceleration, and braking of platoon 1100. In addition, the platoon logic circuitry of each vehicle 1010, 1030, 1090, 1092, and 1094 participating in platoon 1100 may handle its own basic safety maneuvers. In many embodiments, each of follower vehicles 1030, 1090, 1092, and 1094 also provides updates to lead vehicle 1010 and one or more of the other follower vehicles regarding their position, speed, acceleration, velocity, gap 1115, and / or the like. Gap 1115 is the distance between vehicles. For example, platoon logic circuitry 1048 of vehicle 1030 may receive sensor data from the vehicle's sensors and may group the data (such as in Figure 1D The data packet 1300 shown in FIG. 1 is transmitted to the lead vehicle 1010 and / or to the follower vehicle 1090 .

[0044] The data packet 1300 may include fields such as a vehicle identifier (ID) 1310, a packet type 1320, and a payload 1330. The fields preceding the payload 1330 are generally referred to as a packet header. The vehicle ID 1310 field may include a value that uniquely identifies the vehicle that is transmitting the data packet 1300 (referred to herein as the source vehicle). In other embodiments, the data packet 1300 may include the vehicle ID of the vehicle of the intended recipient of the data packet 1300 (referred to herein as the recipient vehicle) in the packet header. In some embodiments, the vehicle ID 1310 field may include a pseudonym for identifying the source vehicle to maintain the anonymity of the vehicle.

[0045] The packet type 1320 field may include a value describing the type of data packet 1300, the layer of the communication topology that generated the data packet 1300, and / or the task that generated the data packet 1300. For example, the data packet 1300 may include vehicle information of the source vehicle for the vehicle controller of the recipient vehicle, new gap information for a gap change task to be performed by the recipient vehicle, new gap information about the gap 1115 between the source vehicle and the recipient vehicle, a new speed and new acceleration or deceleration task for adjusting the speed of the fleet 1100, a new speed and / or acceleration of the source vehicle, and / or the like. The fleet logic circuitry of the recipient vehicle may then identify a priority (such as a time-critical data packet or a non-time-critical data packet) for the data packet 1300 based on the value in the packet type 1320 field. Some embodiments include additional priority levels for data packets.

[0046] The payload 1330 field may include one or more values ​​describing information about the vehicle or about the fleet, such as speed, position, acceleration, heading, driving space or clearance 1115, elevation, steering wheel angle, brake system status, traction control status, transmission status, stability control status, heading speed, combinations thereof, or the like. The contents of the payload 1330 may depend on the task. The recipient vehicle of the data packet 1300 has the following tasks: processing the data in the payload 1320 field, determining whether the data in the payload 1320 requires the recipient vehicle to make adjustments to longitudinal and / or lateral movement, and if necessary, implementing adjustments to longitudinal and / or lateral movement in response to the receipt and processing of the data packet 1300.

[0047] The fleet logic circuitry of the source vehicle may also generate and append some verification value or values ​​before transmitting the data packet 1300. The verification may be a cryptographic verification of the validity and integrity of the data packet 1300. In many embodiments, the verification is based on the contents of the entire data packet 1300 and not just the payload 1330.

[0048] Other data packets may include more fields, fewer fields, and / or different fields. For example, some embodiments of data packet 1300 include a timestamp. The timestamp is a value from a timing synchronization function (TSF) timer, such as TSF timer 1005 in vehicle 1010 or TSF timer 1035 in vehicle 1030. The timestamp allows vehicles to synchronize their TSF timers so that the vehicles can synchronize actions or tasks and can determine, for example, changes in speed based on acceleration information from the time the data packet is sent to the time the data packet payload 1330 is processed.

[0049] Vehicles 1010 and 1030 may include processor(s) 1001 and 1031, respectively, and memories 1011 and 1041. Processor(s) 1001 and 1031 may include any data processing device, such as a microprocessor, a microcontroller, a state machine, and / or the like, and may execute instructions or codes in memories 1011 and 1041. Memories 1011 and 1041 may include storage media, such as dynamic random access memory (DRAM), read-only memory (ROM), buffers, registers, caches, flash memory, hard disk drives, solid-state drives, or the like. Memories 1011 and 1041 may store keys (such as key 12 and key 23), frames, frame structures, frame headers (such as the frame structure of data packet 1300), communication topology information (such as the tasks and layers of communication associated with each of the tasks), or the like, and may also include fleet codes for fleet logic circuit systems 1018 and 1048, respectively.

[0050] TSF timer (such as in Figure 1A The TSF timers 1005 and 1035 in the vehicle may reside in a chipset of the vehicle (such as vehicles 1010 and 1030) or may reside elsewhere in the vehicle.

[0051] The leader vehicle 1010 may periodically transmit, for example, a beacon or heartbeat as part of the data packet 1300 or the payload 1330 in the data packet 1300 (such as longitudinal and lateral motion information) and capture the value in the timing synchronization function (TSF) timer at, simultaneously with, or contemporaneously with the transmission to include in the payload 1330 or frame body of the data packet as a timestamp. Figure 1A The vehicle 1030 in the convoy 1100 may receive the beacon via the wireless network interface 1052 and may calibrate the TSF timer 1035 of the vehicle 1030. The calibration of the TSF timer 1035 of the vehicle 1030 synchronizes the vehicle with the leader vehicle 1010 and other vehicles in the participating convoy 1100 by updating the value in the TSF timer 1035.

[0052] Fleet logic circuit systems 1018 and 1048 may include one or more circuits for implementing fleet tasks and / or fleet maintenance. Fleet logic circuit systems 1018 and 1048 may include one or more processors to execute fleet layer code stored in memories 1011 and 1041, respectively. In other embodiments, fleet logic circuit systems 1018 and 1048 may include interface circuit systems to execute code on one or more processors 1001 and 1031, respectively.

[0053] Fleet logic circuitry 1018 and 1048 may communicate with the media access control (MAC) layer and physical layer (PHY) logic circuitry of wireless network interfaces 1022 and 1052, respectively, to transmit PHY frames, such as acknowledgements (ACKs) or data packets 1300 in PHY frames, for transmission to vehicle 1030 and vehicle 1010, respectively.

[0054] After processing the PHY frame, radios 1026 and 1056, each including an RF transmitter and an RF receiver, can impress digital data onto subcarriers of RF frequencies for transmission by electromagnetic radiation via antenna arrays or elements of antennas 1028 and 1058, respectively. The RF receiver receives the electromagnetic energy, extracts the digital data, and decodes the data packet 1300.

[0055] Fleet logic circuitry 1018 and 1048 may include vehicle controllers 1020 and 1050, respectively. Each vehicle in fleet 1100 includes a vehicle controller, such as vehicle controllers 1018 and 1048. These vehicle controllers process data (or information) about the vehicle in which they reside, data about one or more other vehicles participating in fleet 1100, and data about the lead vehicle or more generally about fleet 1100. Using this data, vehicle controllers (such as vehicle controllers 1018 and 1048) may output signals to adjust the longitudinal and lateral movement of the corresponding vehicle and optionally notify the task generator of the fleet logic circuitry about the adjustments. The output signals for adjusting the longitudinal and lateral movement of the vehicle may automatically perform all adjustments.

[0056] Figure 1C An embodiment of a vehicle controller 1020 is illustrated and generally represents a vehicle controller in each of the vehicles participating in the convoy 1100. In many embodiments, the convoy logic circuit system can maintain the stability of the convoy by providing reference information, information about the vehicle itself, and information about surrounding cars participating in the convoy to the vehicle controller 1020. The information for the vehicle itself and for one or more surrounding vehicles may include position, speed, velocity, acceleration, heading, road curvature, vehicle size, steering wheel angle, gap, transmission state, brake system state, traction control state, stability control state, and / or the like. The reference information for the vehicle controller 1020 may include a target speed for the convoy 1100 and a target gap 1115 between the vehicle and other vehicles participating in the convoy 1100, such as adjacent vehicles directly in front and behind. The vehicle controller 1020 may determine the information about the vehicle itself as sensor data from sensors in the vehicle or data about the vehicle stored in the memory 1011. The vehicle controller 1020 may determine the information about other vehicles based on data in the payload of a data packet, such as the data packet 1300.

[0057] The basic information that the vehicle controller 1020 may need about the surrounding vehicles is position, speed, and acceleration. The vehicle controller 1020 may also need information about a subset of the other vehicles in the fleet 1100. The specific set of vehicles may depend on the communication topology implemented for the fleet 1100 or assumed when the vehicle controller 1020 was designed. Figure 1BAn example of a communication topology 1100 assuming a one plus leader look-ahead communication topology is illustrated. Other communication topologies include one look-ahead, one plus leader look-ahead with sub-convoy, R look-ahead, and bidirectional. In a look-ahead communication topology, each vehicle receives information about the vehicle directly in front of the vehicle. In a one plus leader look-ahead communication topology, each vehicle receives information about the vehicle directly in front of the vehicle and from the leader vehicle. In a one plus leader look-ahead communication topology with sub-convoy, each vehicle receives information about the vehicle directly in front of the vehicle and from the sub-leader, and each sub-leader receives information from the leader vehicle. In an R look-ahead communication topology, each vehicle receives information about the R vehicles in front of the vehicle. In a bidirectional communication topology, each vehicle receives information about the vehicles in front of and behind the vehicle.

[0058] To ensure the safety of the vehicles, the platoon logic circuitry of each of the vehicles periodically transmits a basic safety message (BSM) to the vehicle controller in each of the vehicles 1010, 1030, 1090, 1092, and 1094 participating in the platoon 1100 according to the communication topology. The BSM is a standardized data packet (such as data packet 1300) that includes at least basic information (such as speed, position, and acceleration) required to maintain the safety of the vehicles participating in the platoon 1100. In many embodiments, the platoon logic circuitry of each of the vehicles transmits, receives, and decodes the BSM within 100 milliseconds. When using a one-plus-leader look-ahead communication topology, each following vehicle receives at least two BSMs and transmits at least one BSM within 100 milliseconds. The leader vehicle 1100 may transmit a packet to all vehicles, which requires additional time to generate verification information, and depending on the communication topology implemented, the packet may be received from each of the vehicles 1010, 1030, 1090, 1092, and 1094 in the convoy 1100 within 100 milliseconds. In many embodiments, the E2EL of the BSM is less than 100 milliseconds. Experimental evaluation of these systems indicates that a 10 Hz (hertz) information refresh rate can ensure the stability of the convoy 1100 via vehicle controllers (such as 1020 and 1050).

[0059] Figure 1E The diagram shows support for platooning (such as in Figure 1B1400). Fleet architecture 1400 includes multiple layers of logical operations or tasks to control the movement of vehicles in fleet 1100. Each layer represents a collection of one or more tasks that can be performed by the fleet logic circuit system of each vehicle. In addition, the fleet logic circuit system of each vehicle can transmit information related to each of the tasks to one or more other vehicles participating in fleet 1100 to promote safety and facilitate the formation and maintenance of fleet 1100.

[0060] The convoy architecture 1400 includes a convoy initiation layer 1405, an operation layer 1410, a basic maneuvering layer 1420, an advanced maneuvering layer 1430, and a management layer 1440. The leader vehicle 1010 or a sub-leader vehicle can initiate more complex tasks or all tasks above the operation layer 1410. Each vehicle in the participating convoy can initiate an operation layer 1410 task to maintain the target speed, target acceleration, and target gap of the convoy 1100. In special cases, non-leader vehicles can also initiate tasks above the operation layer 1410. For example, when the traffic light changes from green to red, when only part of the convoy successfully crosses the intersection and the rest is blocked and separated. The tail end of the convoy will be forced to temporarily initiate a "split" operation.

[0061] The operational layer 1410 includes tasks for controlling or regulating the longitudinal and lateral movement of the vehicle. Other layers support more complex movements that the platoon logic circuit system can achieve with multiple longitudinal and / or lateral vehicle adjustments coordinated by one or more of the vehicles in the participating platoon 1100. In many embodiments, the vehicles in the platoon 1100 complete the more complex movement in multiple stages of longitudinal and lateral adjustments of one or more vehicles in the platoon 1100. In several embodiments, the leader vehicle 1010 or a sub-leader vehicle initiates the more complex movement by transmitting a data packet with longitudinal and lateral adjustments for each stage, waiting for the receipt of the data packet to confirm the completion of each stage from each affected vehicle, and then transmitting the longitudinal and lateral adjustments for the subsequent stage. In many embodiments, the packet type in each of the data packets distinguishes the basic safety message (BSM) initiated via the operational layer 1410 from the more complex tasks initiated by other layers including the operational layer 1410 subtasks.

[0062] The fleet initiation layer 1405 tasks may form a fleet from any collection of vehicles on the road or at rest by negotiating the formation of the fleet among the fleet logic circuitry of each of the vehicles. In other embodiments, the fleet initiation layer 1405 communications may involve receiving instructions from an organization or fleet service that specify the formation of a fleet among a collection of vehicles rather than negotiating the formation. In other embodiments, the organization may dictate the formation of the fleet, and the vehicles in the participating fleet may negotiate some or all of the remaining details regarding the formation of the fleet via the fleet initiation layer 1405 tasks and communications.

[0063] The operational layer 1410 may include tasks for maintaining proper longitudinal and lateral motion of the fleet 1100. In many embodiments, the operational layer 1410 includes tasks for regulating and for communicating adjustments to the position, velocity, and acceleration of the fleet, the vehicle itself, and surrounding vehicles. The vehicle controller of each vehicle may process data packets for the operational layer 1410 ten times per second.

[0064] The operational layer 1410 may include a platoon longitudinal control 1412 task and a platoon lateral control 1414 task. The platoon longitudinal control 1412 task involves adjustments to the speed and gap of the vehicle to maintain a target speed and target gap for the platoon or a target speed and gap specified by the lead vehicle 1010 for the vehicles or a subgroup of vehicles in the participating platoon 1100. The platoon logic circuit system of the vehicle may perform tasks such as the platoon longitudinal control 1412, transmit a data packet with data or bits in the header to confirm the completion of the task to the lead vehicle, and transmit a data packet with information about the task to one or more vehicles in the platoon according to the communication topology. The platoon lateral control 1414 task involves adjustments (e.g., lateral movement 1426) for keeping the vehicle in the center of the lane unless a lane change is being requested by a higher layer. To achieve more advanced maneuvers, the speed and gap of one or more vehicles may be changed relative to the target for the platoon, and such maneuvers are initiated by layers above the maneuvering layer 1410.

[0065] Basic maneuvering layer 1420 may include tasks for implementing simple maneuvers that convoy 1100 may perform. In many embodiments, invoking tasks in this layer involves the execution of some tasks in operation layer 1410. Basic maneuvering layer 1420 may include a change gap 1422 task, a change speed 1424 task, a lateral move 1426 task, and a longitudinal move 1428 task. The change gap 1422 task may change all or some of the gaps 1115 between vehicles in convoy 1100. The convoy logic circuitry of the affected vehicle may receive the change gap 1422 task from the leader vehicle 1010 and may perform or attempt to perform the change. If the convoy logic circuitry is able to perform the change toward the new gap, the convoy logic circuitry may respond with a data packet 1300 indicating that the change was completed. If the convoy logic circuitry is unable to perform the change toward the new gap, the convoy logic circuitry may respond with a data packet 1300 indicating that the change failed. In some embodiments, the response may also include information about the failure, such as a safety override in the payload 1330 of the data packet 1300, a manual override, a driver failure to respond, and / or the like.

[0066] The change speed 1424 task may involve changing the speed of one or more vehicles in fleet 1100. Fleet logic circuitry of the affected vehicles may receive the change speed 1424 task from lead vehicle 1010 and may perform or attempt to perform the change. If the fleet logic circuitry is able to perform the change to the new speed, the fleet logic circuitry may respond with a data packet 1300 indicating that the change was completed. If the fleet logic circuitry is unable to perform the change to the new speed, the fleet logic circuitry may respond with a data packet 1300 indicating that the change failed. In some embodiments, the response may also include information about the failure, such as a safety override, a manual override, a driver failure to respond, and / or the like.

[0067] The lateral move 1426 task may involve changing the left-to-right positioning of one or more vehicles in the convoy 1100, such as to change lanes on the road 1110 or to prepare for splitting the convoy. The convoy logic circuitry of the affected vehicle may receive the lateral move 1426 task from the lead vehicle 1010 and may perform or attempt to perform the change. If the convoy logic circuitry is able to perform the lateral move, the convoy logic circuitry may respond with a data packet 1300 indicating that the move was completed. If the convoy logic circuitry is unable to perform the lateral move, the convoy logic circuitry may respond with a data packet 1300 indicating that the lateral move failed. In some embodiments, the response may also include information about the failure, such as a safety override, a manual override, a driver failure to respond, and / or the like.

[0068] The longitudinal move 1428 task may involve changing the acceleration of one or more vehicles in the convoy 1100 in the longitudinal direction. The convoy logic circuitry of the affected vehicle may receive the longitudinal move 1428 task from the lead vehicle 1010 and may perform or attempt to perform the change. If the convoy logic circuitry is able to perform the longitudinal move 1428, the convoy logic circuitry may respond with a data packet 1300 indicating that the move was completed. If the convoy logic circuitry is unable to perform the longitudinal move 1428, the convoy logic circuitry may respond with a data packet 1300 indicating that the longitudinal move failed. In some embodiments, the response may also include information about the failure, such as a safety override, a manual override, a driver failure to respond, and / or the like.

[0069] The advanced maneuvering layer 1430 may include tasks for implementing a collection of advanced maneuvers by the convoy 1100. Typically, calling a task in this layer involves the execution of a task from a lower layer. The advanced maneuvering layer 1430 may include tasks such as merging convoys 1432 and splitting convoys 1434. The merging convoy 1432 task may involve merging the convoy 1100 with a second convoy. The convoy logic circuitry of the leader of the second convoy may receive the merging convoy 1432 task from the leader vehicle 1010 and may perform or attempt to perform the merge. The convoy logic circuitry of the leader of the second convoy may thereafter act as a sub-leader of the leader vehicle 1010 or may transmit a new leader designation to a follower vehicle in the second convoy. If the convoy logic circuitry of the leader of the second convoy is able to merge the convoys, the convoy logic circuitry may respond with a data packet 1300 indicating that the merge is complete. If the convoy logic circuitry of the leader of the second convoy is unable to perform the merge, the convoy logic circuitry may respond with a data packet 1300 indicating that the convoy merge failed. In some embodiments, the response may also include information about the failure, such as a safety override, a manual override, a driver failure to respond, and / or the like. In several embodiments, the merge convoy 1432 task may involve instructions by the lead vehicle 1010 to a follower vehicle, such as the last follower vehicle 1094, to relay data packets 1300 or other communications to the leader of the second convoy to facilitate communication between the lead vehicles of the two convoys when the leader of the second convoy is out of range of the wireless network interface 1022.

[0070] The split convoy 1434 task may involve dividing the convoy 1100 into two or more sub-convoys. The convoy logic circuit system of the new sub-convoy leader(s) may receive the split convoy 1434 task from the leader vehicle 1010 and may perform or attempt to perform the split. The convoy logic circuit systems of the affected follower vehicles may also receive the new leader designation in the form of a data packet 1300. If the convoy logic circuit system of the new sub-leader is able to split the convoy, the convoy logic circuit system may respond with a data packet 1300 indicating that the split was completed. If the convoy logic circuit system of the new sub-leader is unable to perform the split convoy 1434 task, the convoy logic circuit system may respond with a data packet 1300 indicating that the convoy split failed. In some embodiments, the response may also include information about the failure, such as a safety override, a manual override, a driver failure to respond, and / or the like.

[0071] Management layer 1440 may contain tasks that are primarily focused on the management of fleet 1100. Typically, invoking a task in this layer involves executing some tasks from lower layers. Management layer 1440 may include tasks such as fleet admission 1442, fleet removal 1444, change leader 1446, and member manager 1448. Fleet logic circuit system 1018 of leader vehicle 1010 may perform management layer tasks. Fleet admission 1442 tasks may involve, for example, receiving a join request from a vehicle, determining whether the joining vehicle will exceed the maximum fleet size, determining whether other safety conditions are met, and determining whether traffic management considerations are met. If fleet logic circuit system 1018 determines to join a new vehicle, fleet logic circuit system 1018 may execute merge fleet command 1432.

[0072] Fleet removal 1444 tasks may involve removing one or more vehicles from fleet 1100. Fleet logic circuitry 1018 may determine whether conditions allow for safe removal of a vehicle from fleet 1100, and if so, invoke lower layer communications as needed to remove the vehicle from fleet 1100.

[0073] Fleet logic circuitry 1018 may implement a change leader 1446 task to, for example, allow the lead vehicle 1010 to leave the fleet 1100 or to switch the lead vehicle. Fleet logic circuitry 1018 of the lead vehicle 1010 may determine one or more factors, such as safety conditions, traffic management issues, and trip information issues for the fleet 1100. If fleet logic circuitry 1018 determines that the task is acceptable, then the fleet logic circuitry 1018 of the lead vehicle 1010 may perform one or more lower-level tasks to perform the change and transmit the new leader designation to the follower vehicles.

[0074] Fleet logic circuitry 1018 may implement member manager 1448 tasks to, for example, change the size of fleet 1100 if road conditions or traffic conditions cause safety issues with maintaining the current fleet size. For example, if fleet 1100 is split by a change in one or more traffic lights, fleet logic circuitry 1018 may determine to split fleet 1100 or disband the fleet.

[0075] Different layers of the fleet architecture 1400 may raise different security issues. Typically, the communication of information (such as information in the BSM in the operational layer 1410) is not confidential because the information (position, speed, acceleration, etc.) can be easily observed by other vehicles on the road (including but not limited to those in the fleet 1100), and therefore the confidentiality of such information is not considered critical. On the other hand, those messages are time-critical for maintaining the stability of the fleet and the safety of the vehicles in the fleet 1100. The integrity of such messages is of utmost importance so that the messages are not easily spoofed. Higher-level tasks (such as basic maneuvering layer 1420, advanced maneuvering layer 1430, and management layer 1440 tasks) may involve a series of lower-level tasks and task completion confirmation. Therefore, these higher-level tasks are subject to interruptions caused by other vehicles on the road, road users, and external factors (such as traffic light changes at intersections), etc., and are therefore inherently not time-critical. For example, the merge fleet 1432 task may be hindered by nearby vehicles that interfere with one or more of the stages involved in performing the merge fleet 1432 task. Similar to the information in the data packets related to the operational layer tasks, integrity is also important for these higher layer messages so that the messages are not spoofed to cause unsafe maneuvers. In addition, confidentiality may also be important, at least for a subset of these operations. For example, sensitive information (such as a trip destination) may be required in order for a car to join a fleet, but such information should not be shared widely with any car. In order to share the economic benefits of fuel savings among the fleet, it may also be necessary to share financial account information among the fleet members and obviously the confidentiality of such information must be protected.

[0076] Figure 1F -G describes the use for time-critical and non-time-critical messages (such as combined Figure 1A An embodiment of data packet security for transmission of data packets discussed above. Figure 1F An embodiment 1500 of a MAC calculation and authentication security protocol for time-critical data packets is illustrated. Time-sensitive or time-critical data packets are sent by a vehicle controller (such as at a Figure 1AThe vehicle controller 1020 shown in FIG. 10 is required to maintain a basic level of safety and stability for each vehicle participating in the convoy 1100. Assuming the leader plus the previous communication topology for this embodiment, the two types of data packets that can be generated by the convoy logic circuit system of each vehicle include data packets 1300 from the vehicle to the vehicles behind it and data packets 1300 from the leader vehicle 1010 to all vehicles in the convoy 1100. Follower vehicles can also transmit acknowledgments in the form of data packets 1300.

[0077] For time-sensitive data packets, the fleet logic circuitry of each vehicle 1010, 1030, 1090, 1092, and 1094 in fleet 1100 may implement an authentication technique that employs a MAC algorithm with a hash function (such as SHA3-256) based on the use of symmetric keys. By doing so, the architecture avoids the use of time-expensive digital signatures, and thus the encoding / decoding time is approximately 1 millisecond based on benchmark performance evaluations. The architecture assumes pairwise symmetric keys (such as in Figure 1B ), including one pairwise key between each vehicle and the vehicle behind it and one pairwise key between the leader vehicle 1010 and each of the vehicles 1030, 1090, 1092, and 1094 in the participating convoy 1100.

[0078] exist Figure 1F , the encoding process 1500 is part of the MAC calculation process and is used to generate or receive a data packet 1505 (such as Figure 1D If data packet 1505 is not evenly divided into multiple blocks for the MAC algorithm, the fleet logic circuit system can pad data packet 1505 to increase the bytes from, for example, 50 bytes to a number of bytes compatible with the MAC calculation process (such as 64 bytes).

[0079] After padding data packet 1505 to create data packet plus padding 1510, the fleet logic circuitry may perform a cryptographic hash according to, for example, Keccak SHA3-256 with a pairwise key for the intended recipient or destination vehicle. If the fleet logic circuitry is in leader vehicle 1010 and the leader is sending (e.g., broadcasting) the same message to each vehicle in the fleet, fleet logic circuitry 1018 may create a single multicast packet to the entire fleet with a separate MAC for each vehicle in fleet 1100 using the corresponding key for each vehicle in fleet 1100. In many embodiments, the fleet logic circuitry generates the MAC by applying a MAC algorithm with a pairwise symmetric key k (e.g., using Keccak SHA3-256 as a hash function) to the padded data packet m.

[0080] For example, the MAC 1530 for data packets plus padding 1510 transmitted from the platoon logic circuitry 1018 of the lead vehicle 1010 to the follower vehicle 1030 may use a method such as described in Figure 1B 15. If fleet logic circuitry 1018 transmits the data packet plus padding 1510 to all vehicles in fleet 1100, fleet logic circuitry 1018 may append a MAC for each vehicle. A MAC for vehicle 1090 is created using key 13, a MAC for vehicle 1092 is created using key 14, and a MAC for vehicle 1094 is created using key 15. MAC 1535 represents the MAC for the last vehicle 1094 in fleet 1100.

[0081] Decoding handles part of the verification process. The fleet logic circuitry of the recipient vehicle receives the data packet plus padding 1510 along with the MACs 1530 through 1535 for each of the vehicles in fleet 1100. The fleet logic circuitry of the recipient vehicle may be able to determine which MAC is associated with it based on the order of the MACs or by another method to avoid additional time spent decoding all MACs. For data packets from one vehicle to a following vehicle (such as vehicle 1030 to vehicle 1090), the fleet logic circuitry of the source vehicle may transmit the data packet plus padding 1510 with a single MAC.

[0082] If the MAC verifies the data packet plus padding 1510, the fleet logic circuitry may remove the padding and process the data packet 1505 by passing the payload 1330 to the controller's vehicle. If the fleet logic circuitry cannot verify the data packet plus padding with the MAC, the data packet is discarded.

[0083] Figure 1GAn embodiment 1600 of an encryption / signature and decryption / verification security protocol for non-time critical data packets is illustrated. The encoding process begins with the fleet logic circuit system of the source vehicle signing the data packet 1605, for example, using the elliptic curve digital signature algorithm (ECDSA) to create a digital signature 1615. ECDSA is a digital signature mechanism based on the elliptic curve discrete logarithm problem and standardized in the Federal Information Processing Standard (FIPS) 186-4. The public key is then authenticated by using a certificate 1620.

[0084] To achieve confidentiality, the fleet logic circuit system may also encrypt the data packet 1605 along with the signature 1615 to create an encrypted data packet 1610. In many embodiments, the fleet logic circuit system performs the encryption operation using Advanced Encryption Standard (AES) symmetric key encryption. In some embodiments, the payload of the data packet is encrypted to maintain confidentiality, but the header of the data packet is not encrypted to facilitate identification of the data packet by the recipient vehicle. If the symmetric key used for data encryption is not available at the recipient, the symmetric key is encrypted using a public key encryption scheme such as the Elliptic Curve Integrated Encryption Scheme (ECIES). ECIES is a public key encryption mechanism based on the elliptic curve discrete logarithm problem. The public key is then authenticated by using a certificate 1620.

[0085] The source vehicle's fleet logic circuitry may transmit the encrypted data packet 1610 with the digital signature 1615 and the certificate 1620 to the recipient vehicle. And the decoding process begins with the recipient vehicle's fleet logic circuitry verifying the certificate, such as via a third-party certificate authority, and in some embodiments, via an out-of-band network interface, such as at Figure 1A An out-of-band network interface 1059 of the vehicle 1030.

[0086] The recipient vehicle's fleet logic circuitry may then decrypt encrypted data packet 1610 to obtain data packet 1605 and digital signature 1615. The recipient vehicle's fleet logic circuitry may then verify digital signature 1615 using the public key carried in certificate 1620. If the fleet logic cannot verify the digital signature, the data packet is discarded.

[0087] Figure 2 An embodiment of a platoon logic circuit system 2000 for supporting vehicle-to-vehicle communications for a platoon of vehicles is depicted. The platoon logic circuit system 2000 includes a task generator 2010 for generating tasks and corresponding messages (such as in Figure 1EIn many embodiments, the mission generator 2010 may output reference signals to the vehicle controller 2060, including, for example, fleet or target speed and fleet or target gap. In other embodiments, the reference signals may include signals transmitted via the wireless network interface 2030 (such as at Figure 1A Information received by the wireless network interface 1052 shown in FIG.

[0088] Task generator 2010 may output data packets to transmission queue 2012. Transmission queue 2012 may include a buffer for holding data packets until packet determiner 2014 determines whether the data packets include a time-critical data packet. In some embodiments, packet determiner 2014 determines whether the data packets include a time-critical data packet by determining whether the data packets include a time-critical data packet. Figure 1D Whether a data packet is time critical is determined based on the value in the packet type field of the data packet 1300 shown in FIG. 14. A data packet including a packet type associated with the operating layer 1410 is time critical.

[0089] The packet determiner 2014 may move the time-critical data packets into the time-critical queue 2016 and may move the non-time-critical data packets into the non-time-critical queue 2018 to await transmission. The transmission arbiter 2020 may select data packets for transmission from the time-critical queue 2016 and from the non-time-critical queue 2018. The transmission arbiter 2020 may give priority to the time-critical data packets to ensure that the E2EL is less than, for example, 100 milliseconds.

[0090] The packet determiner 2014 may output a data packet from one of the queues to a vehicle ID 2022. The vehicle ID 2022 may add a vehicle ID for the fleet logic circuit system 2000 to the data packet to identify the source vehicle of the data packet. In other embodiments, the vehicle ID 2022 may also add a vehicle ID for a recipient vehicle of the data packet.

[0091] After adding the vehicle ID, the security operation mechanism 2024 can perform security operations so the recipient vehicle can verify that the contents of the data packet are valid and from a valid source. For non-time critical packets, the security operation mechanism can generate a digital signature, optionally encrypt the data packet, and in some embodiments, attach a certificate. For time critical data packets, the security operation mechanism 2024 can optionally add padding and can generate one or more MACs by using a MAC algorithm with a hash function (such as Keccak).

[0092] After secure operation, the wireless network interface 2030 may transmit the data packets to one or more recipient vehicles.

[0093] The wireless network interface 2030 may also include a wireless receiver for receiving data packets from other vehicles. The wireless network interface 2030 may transmit the data packet it receives from another vehicle to the header decoder 2040. If the data packet is a time-critical packet, the data packet may not be encrypted, so the header decoder 2040 may determine whether the data packet is from a fleet in which the fleet logic circuit system 2000 participates and whether the data packet is from a vehicle in the fleet from which the fleet logic circuit system 2000 expects to receive data packets. In some embodiments, the header decoder 2040 may determine both based on the header of the packet including the vehicle ID value and the packet type value. The header decoder 2040 may determine that the data packet is from the correct fleet based on matching the vehicle ID and packet type of the corresponding vehicle and the mission of the correct fleet. In other embodiments, the header decoder 2040 may determine whether the data packet is from the correct fleet based on other information included in the data packet or based on the MAC. If the data packet is from the correct fleet and from the vehicle from which the fleet logic circuit system expects to receive data packets, the fleet logic circuit system 2000 determines that the packet should be decoded and passes the data packet to the packet receiver queue 2042. If the data packet is not from the correct fleet and from a vehicle that the fleet logic circuitry expects to receive the data packet from, then the data packet is discarded.

[0094] If the data packet is not time critical, the data packet may be encrypted and the header decoder 2040 may pass the data packet to the packet recipient queue 2042 .

[0095] The packet receiver queue 2042 can buffer the data packet until the packet determiner 2044 determines whether the data packet is time critical. If the data packet is time critical, such as BSM, the packet determiner 2044 can move the data packet to the time critical queue 2046. If the data packet is not time critical or is encrypted, the packet determiner 2044 can move the data packet to the non-time critical queue 2048.

[0096] After the data packets are moved to the time-critical queue 2046 or the non-time-critical queue 2048, the task arbiter 2050 can ensure E2EL processing of the time-critical data packets by giving the data packets in the time-critical queue 2046 a higher priority than the data packets in the non-time-critical queue 2048 while continuing to process the non-time-critical data packets. Upon selecting the data packets, the task arbiter 2050 can pass the data packets to the validator 2055.

[0097] If the data packet is time sensitive, the verifier 2055 can verify the MAC, or decrypt the encrypted packet, and then verify the certificate and digital signature if the data packet is not time critical. After all verifications, the verifier 2055 passes the payload to the vehicle controller 2060 to perform the task(s). In some embodiments, the verifier 2055 notifies the task generator about the adjustments made in response to the task. If the verifier 2055 does not verify the data packet, the data packet is discarded.

[0098] Figure 3A -B depicts an embodiment of a flow chart for encoding and decoding vehicle-to-vehicle communications for platooning. Figure 3A A flowchart 3000 is shown of a process for encoding data packets for V2V communications used for platooning. Flowchart 3000 begins by determining a data packet to be transmitted (element 3005). The platoon logic circuitry of each vehicle may submit data related to each task completed or being performed by the vehicle in the data packet for transmission. The platoon logic circuitry also identifies each data packet or task as "time critical" or non-"time critical". In some embodiments, data packets are marked as time critical or non-time critical based on the type of packet included in the data packet. In other embodiments, the platoon logic circuitry may include different bits in the packet header to indicate whether the data packet includes data related to a time critical task.

[0099] After generating the data packet, the fleet logic may add the data packet to a time critical queue (element 3015) if the task represented by the data packet is time critical (element 3010), and add the data packet to a non-time critical queue (element 3020) if the task is not time critical (element 3010). The fleet logic circuitry may process data packets added to the time critical queue at a higher rate than data packets added to the non-time critical queue.

[0100] The fleet logic circuitry may select and remove data packets from both critical and non-critical queues at an appropriate rate to ensure end-to-end delay (E2EL) for time-critical data packets (element 3025). Time-critical packets are sent frequently enough and non-time-critical packets are not stuck indefinitely. In some embodiments, the fleet logic circuitry dynamically adjusts the rate and / or heuristically learns the appropriate rate based on the measured E2EL rate.

[0101] Once the fleet logic circuit system selects a data packet for transmission, the fleet logic circuit system may append a vehicle ID to the data packet to identify the source vehicle of the data packet (element 3030). The fleet logic circuit system also signs the data packet (element 3035). If the data packet is time critical, the fleet logic circuit system may calculate a MAC for the data packet using a MAC algorithm with a hash function (e.g., SHA3) and append the MAC to the data packet. In many embodiments, the fleet logic circuit system adds padding to the data packet as needed to increase the size of the data packet to a size that is divided into an even number of blocks for MAC calculation. In addition, if the vehicle is a leader or sub-leader, the fleet logic circuit system may calculate multiple MACs for the data packet (each MAC is calculated using a symmetric key for each of the vehicles in the fleet or sub-fleet) and append the resulting MACs to the data packet. In several embodiments, the fleet logic circuit system appends the MACs for the vehicles in the participating fleet in the same order each time, so that the recipient vehicles can determine the MACs corresponding to their respective keys based on the order of the MACs. In some embodiments, the order of the MACs is based on ascending or descending order of the vehicle IDs associated with the vehicles in the participating fleet.

[0102] If the data packet is not time critical, the fleet logic circuitry may generate a digital signature and encrypt the data packet. In some embodiments, the fleet logic circuitry may encrypt only the payload of the non-time critical data packet, leaving the header or at least a portion of the header unencrypted. Additionally, if the intended recipient vehicle does not have the symmetric key, the fleet logic circuitry may include the symmetric key encrypted with the public key and add a certificate to authenticate the public key.

[0103] After signing and optionally encrypting the data packet, the fleet logic circuitry may pass the data packet to the wireless network interface for transmission to the recipient vehicle (3040). If the fleet logic circuitry performs more tasks and therefore more data packets (element 3050), the flowchart 3000 returns to element 3005.

[0104] Figure 3B Flowchart 3100 of a decoding process of a data packet is illustrated. Flowchart 3100 begins with receiving a data packet (element 3105). The convoy logic circuitry may receive the data packet from a lead vehicle in the convoy or another follower vehicle in the convoy. After receiving the data packet, the convoy logic circuitry may determine a vehicle ID and a packet type from the data packet (element 3110).

[0105] A non-time critical data packet may have an unencrypted header and an encrypted payload. In such an embodiment, the fleet logic circuitry may determine whether the packet type is a fleet mission and whether the vehicle ID in the header is a vehicle ID from which the fleet logic circuitry expects to receive data packets according to the communication topology implemented by the fleet. If so, the fleet logic circuitry stores the data packet in a non-time critical data queue (element 3120). Otherwise, the fleet logic circuitry discards the data packet (element 3150), meaning that the fleet logic circuitry does not process the data packet but instead clears the packet from the queue or overwrites the data packet with a subsequent data packet.

[0106] If the data packet is not encrypted, the fleet logic circuit system determines whether the data packet is from a fleet queuing task of a vehicle participating in a fleet and whether the vehicle ID relates the source of the data packet to a source vehicle from which the fleet logic circuit system expects to receive the data packet. If the data packet is not from a fleet, the data packet is passed to other corresponding applications (element 3117). If the data packet is not from a fleet source from which the fleet logic circuit system expects to receive the data packet, the data packet is discarded (element 3150). Otherwise, the fleet logic circuit system determines whether the data packet is time critical (element 3120), and if the data packet is time critical, the data packet is added to a time critical data packet queue (element 3125).

[0107] The fleet logic circuitry may select data packets to be processed from either the time-critical queue or the non-time-critical queue (element 3135) and may process time-critical data packets at a higher rate than non-time-critical data packets to process time-critical data packets within an E2EL of, for example, 100 milliseconds or less. If the data packet is time-critical, it may carry one or more MACs generated with a pairwise symmetric key. If the data packet is non-time-critical, it may carry a digital signature.

[0108] If the signature or MAC is valid (element 3140), the fleet logic circuitry passes the payload of the data packet to the vehicle controller to process the packet (element 3145). Otherwise, the fleet logic circuitry discards the data packet (element 3150). If more data packets are available, the fleet logic circuitry returns to element 3115.

[0109] Figure 4An example of a storage medium 4000 for storing a processor data structure is illustrated. Storage medium 4000 may include an article of manufacture. In some examples, storage medium 4000 may include any non-temporary computer-readable medium or machine-readable medium, such as an optical, magnetic or semiconductor storage device. Storage medium 4000 may store various types of computer-executable instructions, such as instructions for implementing the logic flow and / or technology described herein. Examples of computer-readable or machine-readable storage media may include any tangible medium capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of computer-executable instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Examples are not limited to this context.

[0110] Figure 5 An example computing platform 5000 is illustrated. In some examples, such as in Figure 5 As shown in FIG. 5 , the computing platform 5000 may include a processing component 5010, other platform components, or a communication interface 5030. According to some examples, the computing platform 5000 may be implemented in a computing device, such as a server in a system, such as a data center or server farm that supports a manager or controller for managing configurable computing resources as mentioned above. In addition, the communication interface 5030 may include a wake-up radio (WUR) and may be able to wake up the main radio of the computing platform 5000.

[0111] According to some examples, the processing component 5010 can perform processing operations or logic on the device 5015 described herein. The processing component 5010 may include various hardware elements, software elements, or a combination of the two. Examples of hardware elements may include devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and the like), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, and the like. Examples of software elements that may reside in the storage medium 5020 may include software components, programs, applications, computer programs, applications, device drivers, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether to use hardware elements and / or software elements to implement an example can vary depending on any number of factors, such as desired computing rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints, as desired for a given example.

[0112] In some examples, other platform components 5025 may include common computing elements such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input / output (I / O) components (e.g., digital displays), power supplies, and the like. Examples of memory cells may include, but are not limited to, various types of computer-readable and machine-readable storage media in the form of one or more higher speed memory cells, such as read-only memory (ROM), random access memory (RAM), dynamic RAM (DRAM), double data rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, arrays of devices such as redundant arrays of independent disks (RAID) drives, solid-state memory devices (e.g., USB memory), solid-state drives (SSDs), and any other type of storage medium suitable for storing information.

[0113] In some examples, the communication interface 5030 may include logic and / or features for supporting the communication interface. For these examples, the communication interface 5030 may include one or more communication interfaces that operate according to various communication protocols or standards to communicate through direct or network communication links. Direct communication may occur via the use of communication protocols or standards described in one or more industry standards (including descendants and variants) (such as those associated with the PCI Express specification). Network communication may occur via the use of communication protocols or standards (such as those described in one or more Ethernet standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE)). For example, one such Ethernet standard may include IEEE 802.3-2012, a carrier sense multiple access with collision detection (CSMA / CD) access method and physical layer specification (hereinafter referred to as "IEEE 802.3"), published in December 2012. Network communication may also occur according to one or more OpenFlow specifications (such as the OpenFlow hardware abstraction API specification). The network communications may also be in accordance with the Infiniband Architecture Specification Volume 1 Version 1.3, released in March 2015 (the "Infiniband Architecture Specification").

[0114] The computing platform 5000 may be part of a computing device, which may be, for example, a server, a server array or server farm, a web server, a network server, an Internet server, a workstation, a microcomputer, a mainframe computer, a supercomputer, a network device, a web device, a distributed computing system, a multiprocessor system, a processor-based system, or a combination thereof. Therefore, the functions and / or specific configurations of the computing platform 5000 described herein may be included or omitted in various embodiments of the computing platform 5000 as appropriate.

[0115] The components and features of computing platform 5000 may be implemented using any combination of discrete circuit systems, ASICs, logic gates, and / or single-chip architectures. In addition, where appropriate, the features of computing platform 5000 may be implemented using microcontrollers, programmable logic arrays, and / or microprocessors, or any combination of the foregoing. Note that hardware, firmware, and / or software elements may be collectively or individually referred to herein as "logic."

[0116] It should be understood that Figure 5 The exemplary computing platform 5000 shown in the block diagram of can represent a functional descriptive example of many potential implementations. Therefore, the division, omission or inclusion of block functions depicted in the drawings does not mean that the hardware components, circuits, software and / or elements used to implement these functions will necessarily be divided, omitted or included in the embodiments.

[0117] One or more aspects of at least one example may be implemented by representative instructions stored on at least one machine-readable medium, which represent various logic within the processor, and when read by a machine, computing device or system, the representative instructions cause the machine, computing device or system to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible machine-readable medium and supplied to various customers or manufacturing facilities to load into a manufacturing machine that actually fabricates the logic or processor.

[0118] Various examples can be implemented using hardware elements, software elements, or a combination of the two. In some examples, hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and the like), integrated circuits, application specific integrated circuits (ASICs), programmable logic devices (PLDs), digital signal processors (DSPs), field programmable gate arrays (FPGAs), memory cells, logic gates, registers, semiconductor devices, chips, microchips, chipsets, and the like. In some examples, software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and / or software elements can vary depending on any number of factors, such as desired computational rates, power levels, thermal tolerances, processing cycle budgets, input data rates, output data rates, memory resources, data bus speeds, and other design or performance constraints, as desired for a given implementation.

[0119] Some examples may include articles of manufacture or at least one computer-readable medium. Computer-readable media may include non-transitory storage media for storing logic. In some examples, non-transitory storage media may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. In some examples, logic may include various software elements, such as software components, programs, applications, computer programs, applications, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, APIs, instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof.

[0120] According to some examples, a computer-readable medium may include a non-transitory storage medium for storing or maintaining instructions, which, when executed by a machine, a computing device, or a system, causes the machine, the computing device, or the system to perform methods and / or operations according to the described examples. Instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Instructions may be implemented according to a predefined computer language, manner, or syntax to instruct a machine, a computing device, or a system to perform a certain function. Instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled, and / or interpreted programming language.

[0121] Some examples may be described using the expression "in an example" or "example" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one example. The appearances of the phrase "in an example" in various places in the specification are not necessarily all referring to the same example.

[0122] Some examples may be described using the expressions "coupled" and "connected," along with their derivatives. These terms are not necessarily intended to be synonymous with each other. For example, descriptions using the terms "connected" and / or "coupled" may indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0123] In addition, in the foregoing detailed description, it can be seen that various features are combined together in a single example for the purpose of simplifying the present disclosure. The disclosed method should not be interpreted as reflecting the intention that the claimed example requires more features than those explicitly stated in each claim. Instead, as reflected in the following claims, the subject matter of the invention lies in less than all the features of a single disclosed example. Therefore, the following claims are thus incorporated into the detailed description, with each claim independently serving as a separate example. In the appended claims, the terms "including" and "wherein" are used as the plain English equivalents of the corresponding terms "comprising" and "wherein", respectively. In addition, the terms "first", "second", "third" and the like are used only as labels and are not intended to impose numerical requirements on their objects.

[0124] Although the subject matter has been described in language specific to structural features and / or methodological acts, it will be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

[0125] The data processing system suitable for storing and / or executing program code will include at least one processor directly or indirectly coupled to the memory element by the system bus.The memory element may include a local memory, a mass storage device and a cache memory adopted during the actual execution of the program code, and the cache memory provides the temporary storage of at least some program codes to reduce the number of times that the code must be retrieved from the mass storage device during execution.The term "code" covers a wide range of software components and structures, including applications, drivers, processes, routines, methods, modules, firmware, microcodes and subroutines.Therefore, the term "code" can be used to refer to any set of instructions, and the instruction performs the desired (one or more) operations when executed by the processing system.

[0126] The logic circuit systems, devices, and interfaces described herein may perform functions implemented in hardware and also implemented with code executed on one or more processors. Logic circuit systems refer to hardware or hardware and code that implement one or more logic functions. Circuit systems are hardware and may refer to one or more circuits. Each circuit may perform a specific function. The circuits of the circuit system may include discrete electrical components, integrated circuits, chip packages, chipsets, memories, or the like interconnected with one or more conductors. Integrated circuits include circuits created on substrates (such as silicon wafers) and may include components. And integrated circuits, processor packages, chip packages, and chipsets may include one or more processors.

[0127] The processor may receive signals (such as instructions and / or data) at (one or more) inputs and process the signals to generate at least one output. When the code is executed, the code changes the physical state and characteristics of the transistors that make up the processor pipeline. The physical state of the transistors is converted into logical bits of ones and zeros stored in registers within the processor. The processor may transfer the physical state of the transistors into registers and transfer the physical state of the transistors into another storage medium.

[0128] A processor may include circuitry for performing one or more sub-functions that are implemented to perform the overall function of the processor. An example of a processor is a state machine or an application specific integrated circuit (ASIC) that includes at least one input and at least one output. The state machine may manipulate at least one input to generate at least one output by performing a predetermined series of serial and / or parallel manipulations or transformations on at least one input.

[0129] Logic as described above can be part of a design for an integrated circuit chip. The chip design is created in a graphical computer programming language and stored in a computer storage medium or a data storage medium (such as a disk, tape, physical hard drive, or a virtual hard drive such as in a storage access network). If the designer has not manufactured the chip or the photolithography masks used to manufacture the chip, the designer transmits the resulting design to such an entity directly or indirectly by physical means (e.g., by providing a copy of the storage medium storing the design) or electronically (e.g., via the Internet). The stored design is then converted to an appropriate format (e.g., GDSII) for manufacturing.

[0130] The resulting integrated circuit chips can be distributed by the manufacturer in raw wafer form (i.e., as a single wafer with multiple unpackaged chips), as a bare die, or in a packaged form. In the latter case, the chip is mounted in a single chip package (such as a plastic carrier with leads attached to a motherboard or other higher-level carrier) or in a multi-chip package (such as a ceramic carrier with either or both surface interconnects or buried interconnects). In any case, the chip is then integrated with other chips, discrete circuit elements, and / or other signal processing devices as part of (a) an intermediate product (such as a processor board, server platform, or motherboard) or (b) a final product.

[0131] Several embodiments have one or more potential advantageous effects. For example, implementing a hybrid security approach for time-critical data packets and non-time-critical data packets advantageously reduces encoding and decoding time for time-critical data packets and improves manageability of end-to-end delay (E2EL) for time-critical data packets. Encoding / decoding a message authentication code (MAC) for a data packet and a first cryptographic key advantageously reduces encoding / decoding time for the data packet. Receiving a data packet with a second MAC from a second vehicle signed with a second cryptographic key advantageously reduces the E2EL for the time-critical data packet. Generating a third MAC with a third cryptographic key and appending the third MAC to the data packet with the MAC prior to transmission of the data packet advantageously reduces encoding time for data packets destined for more than one vehicle in a participating fleet. Generating a hash with a MAC algorithm advantageously reduces encoding time for time-critical data packets. Generating a MAC using a hash function (such as Keccak) advantageously reduces encoding time for time-critical data packets by reducing the number of hashes required to generate the MAC. Verifying the third MAC with a third cryptographic key appending the third MAC to the data packet with the MAC advantageously reduces decoding time for data packets received by more than one vehicle in a participating fleet. Verifying the hash with a MAC algorithm advantageously reduces the decoding time for time-critical data packets over using a digital signature.Verifying the KeccakMAC advantageously reduces the decoding time for time-critical data packets by reducing the number of hashes required to generate the MAC.

[0132] This application provides the following technical solutions:

[0133] 1. An apparatus for performing vehicle-to-vehicle communications for a fleet of vehicles, the apparatus comprising:

[0134] a platooning logic circuit system for receiving information about longitudinal and lateral movement of a first vehicle for transmission to a second vehicle, the first vehicle and the second vehicle being used to participate in a platoon; generating a data packet including the information; generating a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key configured to encrypt communications to the second vehicle and decrypt communications from the second vehicle; and

[0135] A physical layer device is used to transmit the data packet with the MAC to the second vehicle.

[0136] 2. The apparatus of technical solution 1 further comprises a processor, a memory coupled to the processor, a radio coupled to the physical layer device, and one or more antennas, wherein the one or more antennas are coupled to the radio to transmit an orthogonal frequency division multiple access (OFDMA) modulated signal.

[0137] 3. The apparatus of claim 1, wherein the fleet logic circuit system is configured to receive a data packet having a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

[0138] 4. The apparatus of claim 1, wherein the convoy logic circuit system is configured to generate a third MAC using a third cryptographic key and append the third MAC to a data packet having the MAC before transmission of the data packet, wherein the first vehicle is a leader of the convoy and the transmission of the data packet includes transmitting the data packet to the second vehicle and the third vehicle.

[0139] 5. The apparatus of claim 1, wherein the fleet logic circuit system is configured to generate a third MAC using a third cryptographic key, append the third MAC to the data packet, and transmit the data packet with the third MAC to a third vehicle, wherein the first vehicle is a follower vehicle.

[0140] 6. The device of claim 1, wherein the MAC comprises a Keccak message authentication code (KMAC).

[0141] 7. The device as described in technical solution 6, wherein the MAC includes a SHA3-256 MAC.

[0142] 8. The apparatus of claim 1, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet.

[0143] 9. The device as described in technical solution 1, wherein information is received periodically, the information includes longitudinal and lateral motion information and is associated with end-to-end delay requirements.

[0144] 10. A method for performing vehicle-to-vehicle communications for a fleet of vehicles, the method comprising:

[0145] receiving, by the convoy logic circuitry system, information regarding longitudinal and lateral movement of a first vehicle in a participating convoy for transmission to a second vehicle in the participating convoy;

[0146] generating, by the fleet logic circuit system, a data packet including information;

[0147] generating, by the fleet logic circuitry, a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key comprises a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; and

[0148] The data packet with the MAC is transmitted by the physical layer device to the second vehicle.

[0149] 11. The method of technical solution 10 further includes receiving a second data packet with a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

[0150] 12. The method of technical solution 10 further includes generating a third MAC using a third cryptographic key and appending the third MAC to the data packet before transmitting the data packet with the MAC, wherein the first vehicle is the leader of the convoy and transmitting the data packet includes transmitting the data packet to the second vehicle and the third vehicle.

[0151] 13. The method of technical solution 10 further includes decoding a second data packet from the second vehicle by the fleet logic circuit system of the first vehicle, the fleet logic circuit system being used to decode a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and whether a vehicle ID in the header indicates a vehicle in a participating fleet that communicates with the first vehicle according to a communication topology associated with the fleet.

[0152] 14. The method of claim 10, wherein the MAC comprises a Keccak message authentication code (KMAC).

[0153] 15. The method of claim 10, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet.

[0154] 16. The method of claim 10, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with end-to-end delay requirements.

[0155] 17. A computer program product comprising a non-transitory computer readable medium, comprising instructions that, when executed by a processor, cause the processor to perform operations comprising:

[0156] receiving information regarding longitudinal and lateral movement of a first vehicle in a participating convoy for transmission to a second vehicle in the participating convoy;

[0157] generating a data packet including information;

[0158] generating, by the fleet logic circuitry, a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key comprises a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; and

[0159] The data packet with the MAC is output by the fleet logic circuitry to the physical layer device for transmission to the second vehicle.

[0160] 18. The computer program product of claim 17, wherein the operation further comprises receiving a second data packet having a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

[0161] 19. The computer program product of solution 17, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet.

[0162] 20. The computer program product of claim 17, wherein the information includes sensor data regarding acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof.

[0163] 21. A system for performing vehicle-to-vehicle communications for a fleet of vehicles, the system comprising:

[0164] a platooning logic circuit system for receiving information about longitudinal and lateral movement of a first vehicle for transmission to a second vehicle, the first vehicle and the second vehicle being used to participate in a platoon; generating a data packet including the information; generating a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key configured to encrypt communications to the second vehicle and decrypt communications from the second vehicle;

[0165] a physical layer device for transmitting the data packet with the MAC to a second vehicle;

[0166] a radio coupled to the physical layer device; and

[0167] One or more antennas coupled to the radio.

[0168] 22. The system as described in technical solution 21 further includes a processor and a memory coupled to the processor.

[0169] 23. The system of claim 21, wherein the fleet logic circuit system is configured to generate a third MAC using a third cryptographic key, append the third MAC to the data packet, and transmit the data packet with the third MAC to a third vehicle, wherein the first vehicle is a follower vehicle.

[0170] 24. A system as described in technical solution 21, wherein the MAC includes a SHA3-256 MAC.

[0171] 25. A system as described in technical solution 21, wherein the information includes heading, acceleration, pitch angle, steering wheel angle, braking system status, traction control status, transmission status, stability control status, heading, heading speed or a combination thereof for the first vehicle.

[0172] Other Examples of Embodiments

[0173] The following examples relate to other embodiments. The details in the examples may be used anywhere in one or more embodiments.

[0174] Example 1 is an apparatus for performing vehicle-to-vehicle communications for a convoy. The apparatus includes a convoy logic circuit system for receiving information about longitudinal and lateral movement of a first vehicle for transmission to a second vehicle, the first vehicle and the second vehicle participating in a convoy; generating a data packet including the information; generating a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key configured to encrypt communications to the second vehicle and decrypt communications from the second vehicle; and a physical layer device for transmitting the data packet with the MAC to the second vehicle. In Example 2, the apparatus of Example 1 further includes a processor, a memory coupled to the processor, a radio coupled to the physical layer device, and one or more antennas coupled to the radio to transmit an orthogonal frequency division multiple access (OFDMA) modulated signal. In Example 3, the apparatus of Example 1, wherein the convoy logic circuit system is configured to receive a data packet with a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

[0175] In Example 4, the apparatus of Example 1, wherein the convoy logic circuit system is configured to generate a third MAC with a third cryptographic key and append the third MAC to the data packet having the MAC before transmission of the data packet, wherein the first vehicle is a leader of the convoy and the transmission of the data packet includes transmitting the data packet to the second vehicle and the third vehicle. In Example 5, the apparatus of Example 1, wherein the convoy logic circuit system is configured to generate a third MAC with a third cryptographic key, append the third MAC to the data packet, and transmit the data packet having the third MAC to the third vehicle, wherein the first vehicle is a follower vehicle. In Example 6, the apparatus of Example 1, wherein the MAC comprises a Keccak message authentication code (KMAC). In Example 7, the apparatus of Example 6, wherein the hash comprises a Keccak HMAC. In Example 8, the apparatus of Example 6, wherein the MAC comprises a SHA3-256MAC. In Example 9, the apparatus of Example 1, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet. In Example 10, the apparatus of Example 1, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with an end-to-end delay requirement. In Example 11, the apparatus of Example 1, wherein the information comprises sensor data regarding an acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof. In Example 12, the apparatus of Example 11, wherein the information comprises a heading, an acceleration, an elevation angle, a steering wheel angle, a braking system state, a traction control state, a transmission state, a stability control state, a heading, a heading speed, or a combination thereof for the first vehicle. In Example 13, the apparatus of Example 11, wherein the fleet logic circuit system is configured to decode a second data packet from a second vehicle, the fleet logic circuit system being used to decode a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and to determine whether a vehicle ID in the header indicates a vehicle in a participating fleet that communicates with the first vehicle according to a communication topology associated with the fleet.

[0176] Example 14 is a method for performing vehicle-to-vehicle communications for a convoy. The method includes: receiving, by a convoy logic circuit system, information about longitudinal and lateral movement of a first vehicle participating in a convoy for transmission to a second vehicle participating in the convoy; generating, by the convoy logic circuit system, a data packet including the information; generating, by the convoy logic circuit system, a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; and transmitting, by a physical layer device, the data packet with the MAC to the second vehicle. In Example 15, the method of Example 14 further includes receiving a second data packet with a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key. In Example 16, the method of Example 14 further includes generating a third MAC with a third cryptographic key and appending the third MAC to the data packet before transmitting the data packet with the MAC, wherein the first vehicle is a leader of the convoy and transmitting the data packet includes transmitting the data packet to the second vehicle and the third vehicle. In Example 17, the method of Example 14, further includes generating a third MAC with a third cryptographic key, appending the third MAC to the data packet, and transmitting the data packet with the third MAC to a third vehicle, wherein the first vehicle is a follower vehicle.

[0177] In Example 18, the method of Example 14, wherein the MAC comprises a Keccak message authentication code (KMAC). In Example 19, the method of Example 18, wherein the hash comprises a Keccak HMAC. In Example 20, the method of Example 18, wherein the MAC comprises a SHA3-256 MAC. In Example 21, the method of Example 14, wherein the MAC comprises a hash of a concatenation of a first cryptographic key and a data packet. In Example 22, the method of Example 14, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with an end-to-end delay requirement. In Example 23, the method of Example 14, wherein the information comprises sensor data regarding an acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof. In Example 24, the method of Example 23, wherein the information comprises a heading, an acceleration, an elevation angle, a steering wheel angle, a braking system state, a traction control state, a transmission state, a stability control state, a heading, a heading speed, or a combination thereof for the first vehicle. In Example 25, the method of Example 24, further includes decoding, by a fleet logic circuit system of the first vehicle, a second data packet from the second vehicle, the fleet logic circuit system being configured to decode a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and to determine whether a vehicle ID in the header indicates a vehicle in a participating fleet communicating with the first vehicle according to a communication topology associated with the fleet.

[0178] In Example 26, a computer-readable medium having instructions stored thereon, the instructions, when executed, causing a computer to perform operations including the operations of any of Examples 14-25. In Example 27, an apparatus for performing vehicle-to-vehicle communications for a fleet of vehicles, the apparatus comprising means for performing any of Examples 14-25. In Example 28, a program for causing a computer to perform operations including the operations of any of Examples 14-25. In Example 29, a computer-readable storage medium for storing the program of Example 28.

[0179] Example 30 is a computer program product including a non-transitory computer-readable medium, including instructions that, when executed by a processor, cause the processor to perform operations. The operations include: receiving information about longitudinal and lateral movement of a first vehicle in a participating fleet for transmission to a second vehicle in the participating fleet; generating a data packet including the information; generating, by the fleet logic circuitry, a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key configured to encrypt communications to the second vehicle and decrypt communications from the second vehicle; and outputting, by the fleet logic circuitry, the data packet with the MAC to a physical layer device for transmission to the second vehicle. In Example 31, the computer program product of Example 30, wherein the operations further include receiving a second data packet with a second MAC from the second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key. In Example 32, the computer program product of Example 30, wherein the operations further include generating a third MAC with a third cryptographic key and appending the third MAC to the data packet before transmitting the data packet with the MAC, wherein the first vehicle is a leader of the convoy and transmitting the data packet includes transmitting the data packet to the second vehicle and the third vehicle. In Example 33, the computer program product of Example 30, wherein the operations further include generating a third MAC with a third cryptographic key, appending the third MAC to the data packet, and transmitting the data packet with the third MAC to the third vehicle, wherein the first vehicle is a follower vehicle.

[0180] In example 34, the computer program product of example 30, wherein the MAC comprises a Keccak message authentication code (KMAC). In example 35, the computer program product of example 30, wherein the hash comprises a Keccak HMAC. In example 36, the computer program product of example 30, wherein the MAC comprises a SHA3-256 MAC. In example 37, the computer program product of example 30, wherein the MAC comprises a hash of a concatenation of a first cryptographic key and a data packet. In example 38, the computer program product of example 30, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with an end-to-end delay requirement. In example 39, the computer program product of example 30, wherein the information comprises sensor data regarding an acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof. In example 40, the computer program product of example 39, wherein the information includes a heading, an acceleration, a pitch angle, a steering wheel angle, a brake system state, a traction control state, a transmission state, a stability control state, a heading, a heading speed, or a combination thereof for the first vehicle. In example 41, the computer program product of example 40, wherein the operations further include decoding, by a fleet logic circuitry of the first vehicle, a second data packet from the second vehicle, the fleet logic circuitry being operable to decode a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and to determine whether a vehicle ID in the header indicates a vehicle in a participating fleet communicating with the first vehicle according to a communication topology associated with the fleet.

[0181] Example 42 is a system for performing vehicle-to-vehicle communications for a convoy. The system includes: a convoy logic circuit system for receiving information about longitudinal and lateral movement of a first vehicle for transmission to a second vehicle, the first vehicle and the second vehicle participating in a convoy; generating a data packet including the information; generating a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key, the symmetric encryption key is configured to encrypt communications to the second vehicle and decrypt communications from the second vehicle; a physical layer device for transmitting the data packet with the MAC to the second vehicle; a radio coupled to the physical layer device; and one or more antennas coupled to the radio. In Example 43, the system of Example 42 further includes a processor and a memory coupled to the processor. In Example 44, the system of Example 42, wherein the convoy logic circuit system is configured to receive a second data packet with a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key, the symmetric encryption key is configured to encrypt communications that can be decrypted with the first cryptographic key. In Example 45, the system of Example 42, wherein the convoy logic circuit system is configured to generate a third MAC with a third cryptographic key and append the third MAC to the data packet having the MAC prior to transmission of the data packet, wherein the first vehicle is a leader of the convoy and the transmission of the data packet includes transmitting the data packet to the second vehicle and the third vehicle. In Example 46, the system of Example 42, wherein the convoy logic circuit system is configured to generate a third MAC with a third cryptographic key, append the third MAC to the data packet, and transmit the data packet having the third MAC to the third vehicle, wherein the first vehicle is a follower vehicle.

[0182] In example 47, the system of example 42, wherein the data packet includes padding. In example 48, the system of example 42, wherein the MAC includes a Keccak message authentication code (KMAC). In example 49, the system of example 48, wherein the hash includes a KeccakHMAC. In example 50, the system of example 49, wherein the MAC includes a SHA3-256 MAC. In example 51, the system of example 42, wherein the MAC includes a hash of a concatenation of a first cryptographic key and the data packet. In example 52, the system of example 42, wherein information is received periodically, the information includes longitudinal and lateral motion information, and is associated with an end-to-end delay requirement. In example 53, the system of example 42, wherein the information includes sensor data about an acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof. In example 54, the system of example 53, wherein the information includes a heading, an acceleration, a pitch angle, a steering wheel angle, a braking system state, a traction control state, a transmission state, a stability control state, a heading, a heading speed, or a combination thereof for the first vehicle. In Example 55, the system of Example 53, wherein the fleet logic circuit system is configured to decode a second data packet from the second vehicle, the fleet logic circuit system being used to decode a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and to determine whether a vehicle ID in the header indicates a vehicle in a participating fleet that communicates with the first vehicle according to a communication topology associated with the fleet.

[0183] Example 56 is an apparatus for performing vehicle-to-vehicle communications for a convoy. The apparatus includes: means for receiving information about longitudinal and lateral motion of a first vehicle participating in a convoy for transmission to a second vehicle participating in the convoy; means for generating a data packet including the information; means for generating a message authentication code (MAC) for the data packet and a first cryptographic key, wherein the first cryptographic key includes a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; and means for transmitting the data packet with the MAC to the second vehicle. In Example 57, the apparatus of Example 56 further includes means for a second data packet with a second MAC from the second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key. In Example 58, the apparatus of Example 56 further includes means for generating a third MAC with a third cryptographic key and appending the third MAC to the data packet before transmitting the data packet with the MAC, wherein the first vehicle is a leader of the convoy and transmitting the data packet includes transmitting the data packet to the second vehicle and the third vehicle. In Example 59, the apparatus of Example 56, further comprising means for generating a third MAC with a third cryptographic key, appending the third MAC to the data packet, and transmitting the data packet with the third MAC to a third vehicle, wherein the first vehicle is a follower vehicle. In Example 60, the apparatus of Example 56, wherein the MAC comprises a Keccak message authentication code (KMAC).

[0184] In Example 61, the apparatus of Example 60, wherein the hash comprises a Keccak HMAC. In Example 62, the apparatus of Example 60, wherein the MAC comprises a SHA3-256 MAC. In Example 63, the apparatus of Example 56, wherein the MAC comprises a hash of a concatenation of a first cryptographic key and a data packet. In Example 64, the apparatus of Example 56, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with an end-to-end delay requirement. In Example 65, the apparatus of Example 56, wherein the information comprises sensor data regarding an acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof. In Example 66, the apparatus of Example 65, wherein the information comprises a heading, an acceleration, an elevation angle, a steering wheel angle, a braking system state, a traction control state, a transmission state, a stability control state, a heading, a heading speed, or a combination thereof for the first vehicle. In Example 67, the apparatus of Example 65, further includes a component for decoding, by the first vehicle, a second data packet from the second vehicle, the first vehicle for decoding a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and to determine whether a vehicle ID in the header indicates a vehicle in a participating fleet that communicates with the first vehicle according to a communication topology associated with the fleet.

Claims

1. An apparatus for performing vehicle-to-vehicle communications for a fleet of vehicles, the apparatus comprising: The fleet logic circuit system is configured to: receiving information regarding longitudinal and lateral movement of a first vehicle for transmission to a second vehicle, the first vehicle and the second vehicle being used to participate in a convoy; generating a data packet including said information; determining whether the data packet is time critical; In response to determining that the data packet is time critical, generating a message authentication code (MAC) with a first cryptographic key and appending the MAC to the data packet, wherein the first cryptographic key comprises a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; as well as In response to determining that the data packet is not time critical, generating a digital signature and encrypting a payload of the data packet; A physical layer device is used to transmit the data packet to the second vehicle.

2. The apparatus of claim 1, further comprising a processor, a memory coupled to the processor, a radio coupled to the physical layer device, and one or more antennas coupled to the radio to transmit an orthogonal frequency division multiple access (OFDMA) modulated signal.

3. The apparatus of claim 1 , wherein the fleet logic circuit system is configured to receive a data packet having a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

4. The apparatus of claim 1 , wherein the convoy logic circuitry is configured to generate a third MAC with a third cryptographic key and append the third MAC to a data packet prior to transmitting the data packet with the MAC, wherein the first vehicle is a leader of the convoy and the transmission of the data packet includes transmitting the data packet to the second vehicle and the third vehicle.

5. The apparatus of claim 1 , wherein the convoy logic circuitry is configured to generate a third MAC with a third cryptographic key, append the third MAC to the data packet, and transmit the data packet with the third MAC to a third vehicle, wherein the first vehicle is a follower vehicle.

6. The apparatus of claim 1, wherein the MAC comprises a Keccak message authentication code (KMAC).

7. The apparatus of claim 6, wherein the MAC comprises a SHA3-256 MAC.

8. The apparatus of claim 1, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet.

9. The apparatus of claim 1, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with an end-to-end delay requirement.

10. An apparatus for performing vehicle-to-vehicle communications for a fleet of vehicles, the apparatus comprising: means for receiving information regarding longitudinal and lateral movement of a first vehicle in a participating convoy for transmission to a second vehicle in the participating convoy; means for generating a data packet comprising said information; means for determining whether the data packet is time critical, in response to determining that the data packet is time critical, generating a message authentication code (MAC) with a first cryptographic key and appending the MAC to the data packet, and in response to determining that the data packet is not time critical, generating a digital signature and encrypting a payload of the data packet, wherein the first cryptographic key comprises a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; as well as Means for transmitting the data packet to a second vehicle.

11. The apparatus of claim 10, further comprising means for receiving a second data packet having a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

12. The apparatus of claim 10, further comprising means for generating a third MAC with a third cryptographic key and appending the third MAC to the data packet before transmitting the data packet with the MAC, wherein the first vehicle is a leader of the convoy and transmitting the data packet comprises transmitting the data packet to the second vehicle and the third vehicle.

13. The apparatus of claim 10, further comprising means for decoding, by a fleet logic circuit system of the first vehicle, a second data packet from the second vehicle, the fleet logic circuit system being configured to decode a header of the second data packet to determine whether a packet type in the header indicates a fleet mission and to determine whether a vehicle ID in the header indicates a vehicle in a participating fleet that is communicating with the first vehicle according to a communication topology associated with the fleet.

14. The apparatus of claim 10, wherein the MAC comprises a Keccak message authentication code (KMAC).

15. The apparatus of claim 10, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet.

16. The apparatus of claim 10, wherein information is received periodically, the information comprising longitudinal and lateral motion information and associated with an end-to-end delay requirement.

17. A computer program product comprising a computer readable medium, comprising instructions which, when executed by a processor, cause the processor to perform operations comprising: receiving information regarding longitudinal and lateral movement of a first vehicle in a participating convoy for transmission to a second vehicle in the participating convoy; generating a data packet including said information; determining whether the data packet is time critical; In response to determining that the data packet is time critical, generating a message authentication code (MAC) with a first cryptographic key and appending the MAC to the data packet, wherein the first cryptographic key comprises a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; In response to determining that the data packet is not time critical, generating a digital signature and encrypting a payload of the data packet; as well as The data packets are output to a physical layer device for transmission to a second vehicle.

18. The computer program product of claim 17, wherein the operations further comprise receiving a second data packet having a second MAC from a second vehicle signed with a second cryptographic key, wherein the second cryptographic key is a symmetric encryption key configured to encrypt communications that can be decrypted with the first cryptographic key.

19. The computer program product of claim 17, wherein the MAC comprises a hash of a concatenation of the first cryptographic key and the data packet.

20. The computer program product of claim 17, wherein the information includes sensor data regarding acceleration of the first vehicle, a heading of the first vehicle, a driving space of the first vehicle, or a combination thereof.

21. A system for performing vehicle-to-vehicle communications for a fleet of vehicles, the system comprising: A fleet logic circuit system configured to: receiving information regarding longitudinal and lateral movement of a first vehicle for transmission to a second vehicle, the first vehicle and the second vehicle being used to participate in a convoy; generating a data packet including information; determining whether the data packet is time critical; In response to determining that the data packet is time critical, generating a message authentication code (MAC) with a first cryptographic key and appending the MAC to the data packet, wherein the first cryptographic key comprises a symmetric encryption key configured to encrypt communications to and decrypt communications from the second vehicle; as well as In response to determining that the data packet is not time critical, generating a digital signature and encrypting a payload of the data packet; a physical layer device for transmitting the data packet to a second vehicle; a radio, which is coupled to the physical layer device; as well as One or more antennas coupled to the radio.

22. The system of claim 21, further comprising a processor, and a memory coupled to the processor.

23. The system of claim 21, wherein the fleet logic circuit system is configured to generate a third MAC with a third cryptographic key, append the third MAC to the data packet, and transmit the data packet with the third MAC to a third vehicle, wherein the first vehicle is a follower vehicle.

24. The system of claim 21, wherein the MAC comprises a SHA3-256 MAC.

25. The system of claim 21, wherein the information includes heading, acceleration, pitch angle, steering wheel angle, brake system status, traction control status, transmission status, stability control status, heading speed, or a combination thereof for the first vehicle.

Images