Quandle-based secure cryptographic system in dynamic network environments

Abstract

This disclosure relates to a Quandle-based secure cryptographic system for dynamic network environments. The document describes systems, computer program products, and methods for Quandle-based secure cryptography in dynamic network environments. An example system may include multiple entities, wherein a first entity is configured to detect the presence of a second entity in immediate vicinity and transmit a first communication request to the second entity. Upon receiving the first communication request, the second entity may encrypt primary information associated with itself using a Quandle-based cryptographic framework. The encrypted second primary information, along with second supplementary information, may then be transmitted to the first entity as a response to the communication request.

Description

Technical Field

[0001] Exemplary embodiments of this disclosure relate to secure communication in dynamic network environments, and more specifically, to methods and systems for establishing and maintaining secure data exchange between computing devices (e.g., autonomous vehicles, drones, or mobile computing units) using Quandle-based cryptographic techniques. Background Technology

[0002] In modern network environments, secure communication between entities is crucial, especially in dynamic and self-organizing networks where devices frequently connect and disconnect based on proximity, changing conditions, or ad-hoc needs. Traditional encryption techniques often rely on complex key management and pre-established trust relationships, making them unsuitable for self-organizing scenarios where entities may not know each other beforehand. Autonomous vehicles, drones, and other mobile computing devices frequently operate in such environments, requiring secure information exchange to perform tasks such as coordinated movement, sharing sensor data, and responding to emergencies. Therefore, secure data exchange in dynamic networks is essential, enabling entities to encrypt sensitive information using enhanced security measures and adjust encryption levels based on contextual factors such as trust levels or communication urgency.

[0003] The applicant has identified numerous deficiencies and problems related to secure communication in dynamic network environments. Many of these identified problems have been addressed by developing solutions included in the embodiments of this disclosure, many examples of which will be described in detail herein. Summary of the Invention

[0004] Therefore, systems, methods, and computer program products for secure communication in dynamic network environments are provided.

[0005] In one aspect, this paper proposes a Quandle-based secure cryptographic system for dynamic network environments. The system includes: a first entity; and a second entity; wherein the first entity is configured to: detect the presence of the second entity in the immediate vicinity of the first entity; and, in response, transmit a first communication request to the second entity to establish communication with the second entity; and wherein the second entity is configured to:, in response to the first communication request, encrypt a second primary message (sp) associated with the second entity using a second public key (e2) within a Quandle-based cryptographic framework; and transmit the encrypted second primary message (esp) and a second supplementary message (ss) associated with the second entity to the first entity.

[0006] In some embodiments, the second public key (e2) is associated with the second entity.

[0007] In some embodiments, the second entity is one of a second group of entities associated with the second owner, and the second public key (e2) is associated with the second group of entities.

[0008] In some embodiments, the second entity is further configured to send a second communication request to the first entity after sending the encrypted second primary information (ESP) and second supplementary information (SS).

[0009] In some embodiments, the first entity is further configured to: encrypt first primary information (fp) associated with the first entity using the first public key (e1) with the first public key (e1) in the Quandle-based cryptographic framework, wherein the first public key (e1) is associated with the first entity; and, in response to the second communication request, transmit the encrypted first primary information (efp) and first supplementary information (fs) associated with the second entity to the first entity.

[0010] In some embodiments, the first entity is one of a first group of entities associated with the first owner, and the first public key (e1) is associated with the first group of entities.

[0011] In some embodiments, the second entity is further configured to generate the encrypted second main information (esp) based on the second main information (sp), the encoded variable (y), and the second public key (e2), wherein esp = sp y ,in It is a binary operation that satisfies the Quandle axiom, where ,in It is shaped like Composite numbers, and among them and It is a prime number.

[0012] In some embodiments, sp y = ,in ,in Let be the Euler totient function, and where .

[0013] In some embodiments, the second entity is further configured to: establish an initial communication link with the first entity, and wherein transmitting the encrypted second primary information (ESP) includes using the initial communication link.

[0014] In some embodiments, the second public key (e2) is a short encryption key with a length of less than or equal to 1024 bits.

[0015] In some embodiments, the second entity is configured to: after successfully transmitting the encrypted second primary information (esp) and second supplementary information (ss) to the first entity, switch from the initial communication link to a persistent communication link, wherein the switch further includes converting the second public key (e2) from the short encryption key to a long encryption key with a length greater than or equal to 2048 bits.

[0016] In some embodiments, the second primary information (sp) includes operational information associated with the second entity, wherein the operational information includes at least one of internal system information, monetizable operational information, control commands, or security protocols and procedures.

[0017] In some embodiments, the second supplementary information (SS) includes status information associated with the second entity, wherein the status information includes at least one of location information, functional status, or captured sensor information.

[0018] In some embodiments, the first entity is further configured to: continuously monitor the presence of one or more entities in the immediate vicinity of the first entity; detect that the second entity is no longer in the immediate vicinity of the second entity; and terminate the established communication with the second entity.

[0019] In some embodiments, the first entity is further configured to: detect the presence of a third entity in the immediate vicinity of the first entity based on the monitoring; and transmit a third communication request to the third entity to establish communication with the third entity.

[0020] On the other hand, this paper proposes a Quadle-based secure cryptographic method for dynamic network environments. The method includes: receiving a first communication request from a first entity to establish communication with a second entity; the second entity, in response to the first communication request, encrypting second primary information (sp) associated with the second entity using a second public key (e2) within a Quadle-based cryptographic framework; and the second entity transmitting the encrypted second primary information (esp) and second supplementary information (ss) associated with the second entity to the first entity, wherein the first communication request is received in response to detecting the presence of the second entity in the immediate vicinity of the first entity. Attached Figure Description

[0021] The foregoing has provided a general description of some exemplary embodiments of this disclosure, and further explanation will follow with reference to the accompanying drawings. The components shown in the drawings may or may not be present in some of the embodiments described herein. Some embodiments may contain fewer (or more) components than those shown in the drawings.

[0022] Figure 1 An exemplary network environment according to an embodiment of the present disclosure is illustrated; Figure 2 The illustration shows an exemplary autonomous vehicle circuit according to an embodiment of the present invention, which may be partially or wholly included in an autonomous vehicle. Figure 3 The illustration shows a schematic diagram of an exemplary circuit according to an embodiment of the present disclosure, which may be partially or wholly included in the computing unit of an autonomous vehicle. Figure 4 The illustration depicts an exemplary method for direct authentication between two entities in a dynamic network environment according to embodiments of the present disclosure; and Figure 5 An exemplary method for converting connections between entities is illustrated according to an embodiment of the present invention. Detailed Implementation

[0023] Overview Secure communication between unknown or temporarily connected participants presents significant challenges in the realm of dynamic, self-organizing, or ad hoc networks. These networks typically emerge in scenarios such as disaster response operations, self-organizing communications, or ad hoc sensor networks involving autonomous vehicles and drones. In such contexts, the transient and decentralized nature of these networks necessitates the use of secure encryption methods to ensure data integrity and security without prior knowledge of the participating entities.

[0024] Embodiments of this invention employ Quad-based cryptography to achieve secure communication in dynamic, self-organizing, or ad hoc networks. Quad-based cryptography leverages the unique properties of Quads and rack axioms to enhance cryptographic security. Unlike traditional cryptographic algorithms that rely on correlated operations, the non-correlated nature of Quad operations introduces an additional layer of complexity, thereby strengthening the cryptographic process. In dynamic, self-organizing, or ad hoc networks, Quad-based cryptography can be used to facilitate secure communication. Furthermore, Quad-based cryptography allows for flexible adjustment of security levels by controlling the length of the encryption key and encoded variables. This flexibility provides a high degree of freedom, allowing for trade-offs between key length and desired security strength.

[0025] An example system can create a secure information exchange platform where entity identities are protected by cryptographic keys. For example, in a disaster response scenario, various emergency responders can communicate and share critical information without unauthorized access to their identities or data outside of intended self-organized communication. This example system can use quantum-based cryptography to protect primary information associated with each entity. For example, each drone or autonomous vehicle in the network can use a unique cryptographic key to protect its sensor data. Secondary information (such as status updates) can be shared, ensuring that primary data remains isolated and protected from unauthorized access. Furthermore, the example system can use a short public key and a low level of encryption for the initial handshake (e.g., the initial communication link), thereby accelerating the process of establishing a secure connection. For example, when a drone first connects to a temporary network established at a disaster site, it uses a short public key for rapid authentication. Once a secure communication link is established, the system can switch to a higher level of encryption with a longer private key for continuous data transmission, ensuring robust security during continuous operation. In this way, the example system can allow different entities to use the same temporary network infrastructure without the risk of data breaches. In ad-hoc communication networks, multiple entities can share the same network without compromising the confidentiality of their communications. Each entity's data remains encrypted and isolated, thus facilitating secure and efficient communication in dynamic environments. The example system can also enable secure data sharing between different entities, such as autonomous vehicles and drones, that may belong to different owners (e.g., different vendors). For example, in smart city scenarios, automated delivery vehicles from different owners can share traffic data without revealing their proprietary information, thereby optimizing performance and communication. In specific applications, the example system can support the sharing of sensor information, threat detection data, current direction and speed, and other relevant data. For instance, in a fleet of autonomous vehicles, the system can facilitate the sharing of threat detection information and current speed among vehicles to enhance security and efficiency. Furthermore, it can enable collaborative measures, such as collaboratively reducing wind resistance, thereby saving energy.

[0026] Where possible, unless otherwise expressly stated, any term expressed in the singular should be understood to include the plural form as well, and vice versa. Furthermore, as used herein, the terms “a” and / or “an” should mean “one or more”, even if the phrase “one or more” is used herein. Additionally, when something is referred to herein as being “based on” another thing, it may also be based on one or more other things. In other words, unless otherwise expressly stated, as used herein, “based on” means “at least partially based on” or “at least partially based on”. The same numbers throughout refer to the same elements.

[0027] In this document, "operationally coupled" can mean that components are coupled electronically or optically and / or communicate electrically or optically with each other. Furthermore, "operationally coupled" can mean that components can be integrally formed with each other, or can be separately formed and coupled together. Additionally, "operationally coupled" can mean that components can be directly connected to each other, or can be interconnected through one or more components (e.g., connectors) located between operably coupled components. Furthermore, "operationally coupled" can mean that components are detachable from each other, or that they are permanently coupled together.

[0028] In this paper, "determine" can encompass a variety of actions. For example, "determine" can include calculation, operation, processing, derivation, investigation, and ascertainment. Furthermore, "determine" can also include receiving (e.g., receiving information), accessing (e.g., accessing data in memory), and / or similar operations. Additionally, "determine" can include parsing, selecting, choosing, calculating, building, and / or similar operations. Determining can also include ascertaining whether a parameter meets predetermined criteria, including whether it reaches, exceeds, exceeds, or satisfies a threshold.

[0029] Furthermore, as will be apparent to those skilled in the art based on this disclosure, the terms “basically” and “about” indicate that the referenced elements or related descriptions are accurate within applicable engineering tolerances.

[0030] Quandle-based cryptographic framework Knot theory, a branch of topology, focuses on the study of knots and their properties, particularly how to distinguish and classify knots, and how to transform knots into each other through continuous transformations without cutting or connecting the ends. This theoretical framework can provide a concrete mathematical foundation for developing cryptographic methods that are inherently resistant to known quantum computing threats. Applying knot theory to cryptography leverages the concept that knots and their transformations can represent data, encryption processes, and cryptographic keys. Invariants in knot theory (such as Jones polynomials) are properties that remain unchanged under knot transformations, providing a way to encode and protect information. These invariants can serve as the basis for cryptographic algorithms, where analyzing the complexity and difficulty of knot transformations provides security against unauthorized decryption. A closely related concept is the braid, which consists of a set of strands that can be interwoven vertically but do not intersect or overlap when viewed from above. Any knot can be represented as a closed braid, where closure involves connecting the corresponding upper and lower ends of the braid without introducing new intersections. This operation transforms an open braid into a closed loop or knot while preserving the topological features encoded in the braid structure.

[0031] The principle that two knots are equivalent if they can be transformed into each other through continuous transformations without cutting or stitching supports the security model of this cryptographic approach and helps to traverse noisy communication channels without losing encoded information. In this context, the encryption process can be conceptualized as the “knotting” of data, where data is wrapped in a complex knotted structure. Conversely, decryption involves the “untying” of data, a process that requires understanding specific transformations, analogous to possessing a cryptographic key. The challenge of determining whether two knots are equivalent, especially as knot complexity increases, illustrates the difficulty of breaking cryptographic schemes without the correct key. This highly complex task provides a significant barrier against both conventional and quantum computing attacks.

[0032] The Reidmeister move forms the basis for determining when two knot diagrams represent the same knot (in other words, when two knots are equivalent). Type I moves (twist and untwist) add or remove twists in a knot diagram. It involves creating or eliminating single loops, effectively altering the local twist of the strands. Although simple, Type I moves strongly demonstrate that a single twist does not change the fundamental properties of a knot. Type II moves (poke, cross) involve the two strands of a knot passing over or under each other twice. It can introduce or remove a pair of crossings while maintaining the integrity of the strands and preserving the overall topology of the knot. This move is particularly helpful in illustrating how the interaction between different parts of a knot can be altered without affecting its fundamental characteristics. Type III moves (slide) involve sliding one strand across the crossings of two other strands. Type III moves do not change the number of crossings but alter the position of the strands around the crossings. Type III transformations demonstrate the flexibility of a knot in three-dimensional space, showing that even if some parts of the knot are rearranged, the overall structure of the knot can remain unchanged. In cryptography, the idea of ​​knot equivalence provides a metaphor for encryption and decryption processes through Redmeister transformations. Just as a knot can be transformed through a series of transformations without changing its fundamental characteristics, data can be encrypted into a complex form and then decrypted back to its original state, provided that the correct sequence of transformations (similar to a cryptographic key) is known.

[0033] A Quandle (Quandle) is a set of binary operations that satisfies axioms similar to those of the Redmeister transformation used to manipulate knot graphs. Embodiments of this invention envision a cryptographic framework that utilizes the algebraic structure of Quandles or racks to ensure a secure, reversible cryptographic process that allows for complex data manipulation while maintaining the integrity of the encrypted message. The axioms of Quandles and racks facilitate a framework for encryption that reflects operations on messages (plaintext) within a cryptographic domain. Specifically, idempotency (specific to Quandles) ensures that encrypting a message using the same message as the encoding variable results in the message itself, a property that can be used for consistency checks and maintaining structural patterns in encrypted data; reversibility allows the encryption process to be reversible, ensuring that encrypted data (ciphertext) can be decrypted back to its original form (message) without losing any information, crucial for any cryptographic scheme; self-distribution enables complex manipulations of encrypted data that are equivalent to operations on the message, allowing certain computations to be performed directly on the ciphertext without revealing its contents. Self-distribution enables operations such as partial homomorphic encryption, which require performing algebraic operations on the encrypted data.

[0034] By leveraging the quantile and framework axioms, the systems, methods, and computer program products described in this paper facilitate operations on ciphertext similar to those performed on messages without compromising confidentiality. Unlike traditional cryptographic algorithms that rely on associative operations (such as group operations), the non-associative nature of the quantile operation adds a level of complexity to the cryptographic process. Therefore, the novel cryptographic framework proposed in this paper enhances the level of security offered against both traditional and sophisticated attacks, thereby enabling secure data processing and transmission in digital environments. In the example described in this paper, x y and c y represents a binary operation. In practice, these two operations can be implemented in various ways, as long as they satisfy the axioms of the quantile and / or framework algebra. In one example embodiment, x... y= And c y= Here, x can refer to the message to be transmitted, y can be an encoded variable (which can be public or private depending on the application), e can refer to the public key, c can refer to the ciphertext, and f can refer to the private key. Unlike many other cryptographic frameworks, x, y, and c are rational numbers, not just integers. In the proposed cryptographic framework, the choice of variables (such as e and f) can be compared to the established methodology applied in the Rivest-Shamir-Adleman (RSA) algorithm, particularly in terms of the choice of specific parameters and mathematical properties. Specifically, the choice of e should satisfy... And e and Coprime, which means e and It has no common divisor other than 1. This ensures that e has a multiplicative inverse modulus. f can be calculated as e in the modulus. The multiplicative inverse of f. This means that f satisfies the equation The number. In other words, the choice of f makes the product of f and e divided by... The remainder is 1. Here, n is the product of two (usually larger) prime numbers p and q. It is the Euler totient function, defined as follows: Similar to the RSA algorithm, the Carmichael's totient function can be used in place of Euler's totient function for the same or similar purposes.

[0035] In addition, x y and c y can be complementary (based on the reversibility mentioned above), thus ensuring a symmetric relationship and supporting its application in cryptography. Specifically, x y is used to encrypt the message (x), that is, to generate ciphertext (c), and c y is used for decryption, recovering the message (x) from the ciphertext (c). In traditional cryptographic algorithms (such as RSA), the message (x) is an integer. However, the proposed x... y and c The relation between x and y allows both x and y to be non-integer or rational numbers, increasing the complexity of the encryption. Compared to RSA, the proposed relation not only allows the message (x) to be a rational number but also includes an encoded variable (y), which does not exist in RSA and can be any integer or rational number. This further increases the complexity of the encryption, making unauthorized decryption more difficult and enhancing security. In fact, when x is an integer and y=1, the resulting relation is consistent with the RSA algorithm, representing a specific instance of the proposed cryptographic framework. More importantly, it can be obtained by applying the existing relation x... Additional encoded variables (such as a second encoded variable (z) (or multiple such variables as described herein)) are introduced into y to further enhance the encryption complexity. Specifically, x y z is used to encrypt the message (x) to generate ciphertext (c), and c z y can be used to decrypt and recover the previously encrypted message (x). Here, the second encoded variable (z) is decoded first, then the encoded variable (y) is decoded, and finally the message (x) is recovered. Similar to x and y, z can also be an integer or a rational number, which further increases the complexity of the encryption. In addition to introducing encoded variables, the complexity of the encryption can be further enhanced by using multiple public-private key pairs (ef pairs) for each introduced encoded variable. Therefore, the complexity of the proposed encryption framework is at least comparable to RSA and has the potential to surpass it.

[0036] The subject matter disclosed in a previous Israeli application (titled "Quandle-based cryptographic Framework," application number 313045, filed May 22, 2024) focuses on a Quandle-based cryptographic framework and is incorporated herein by reference in its entirety, as if listed in its entirety. This reference is intended to provide further details, features, and embodiments relating to the cryptographic methods and systems discussed in this disclosure, and any modifications or adjustments within the scope of this application are to be considered applicable to the systems and methods.

[0037] Example network environment Figure 1 An example network environment 100 according to an embodiment of the present disclosure is illustrated. Figure 1 As shown, the network environment 100 may include multiple autonomous vehicles 110, roadside units (RSUs) 120, a central management unit 130, one or more temporary nodes 140 (e.g., drones or mobile command units), and a network 150.

[0038] Multiple autonomous vehicles 110 may be equipped with onboard sensors, computing units, and communication modules to enable autonomous operation and interaction with other components in the network environment 100. These autonomous vehicles 110 may use sensors such as cameras, LiDAR, radar, GPS, and ultrasonic sensors to collect environmental data to detect obstacles, road conditions, and other relevant information. The onboard computing unit can process this sensor data to perform tasks such as path planning, target detection, and decision-making. The autonomous vehicles 110 may be able to communicate via wireless communication protocols such as Dedicated Short Range Communication (DSRC), 5G New Radio (NR) V2X, or Wi-Fi-based V2X for vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communication. This capability allows each autonomous vehicle to share data with other vehicles, RSU 120, or the central management unit 130, thereby facilitating cooperative driving, collision avoidance, and real-time traffic management.

[0039] RSU 120 can be a fixed communication device located along roads, intersections, or other strategic locations to facilitate data exchange between autonomous vehicle 110 and central management unit 130. RSU 120 can act as a data collection point, receiving information from passing vehicles (such as traffic density, detected hazards, or environmental conditions) and relaying it to central management unit 130 for further processing. RSU 120 can also send information (such as traffic light status, road construction notices, or dynamic speed limits) back to vehicle 110, enabling the vehicle to make informed navigation decisions. RSU 120 can be equipped with communication modules compatible with multiple protocols (such as DSRC, Wi-Fi, and 5G) to support various vehicle-to-infrastructure (V2I) and vehicle-to-everything (I2V) applications.

[0040] The central management unit 130 can serve as a data aggregation and coordination hub within the network environment 100. The central management unit 130 can collect data from RSU 120, autonomous vehicles 110, and other network nodes to perform tasks such as traffic analysis, congestion management, and navigation optimization. By processing the aggregated data, the central management unit 130 can generate instructions or recommendations and send them back to vehicles 110 or RSU 120, such as route replanning suggestions, coordinating maneuvering instructions, or adjusting traffic signals. The central management unit 130 can also integrate data from external sources, such as weather stations, public transportation systems, or emergency services, to improve decision-making and adjust traffic management strategies according to changing circumstances.

[0041] Network environment 100 may include one or more temporary nodes 140, such as drones or mobile command units, which can provide additional communication coverage or dedicated functions when needed. Temporary nodes 140 can be deployed in areas with limited fixed infrastructure, such as rural or remote areas, to extend network coverage. Temporary nodes 140 can also be used during events requiring temporary communication setups, such as emergency response, large public gatherings, or road construction. For example, drones can collect aerial data on traffic conditions or road accidents and relay this information to central management unit 130 or nearby vehicles 110. Mobile command units can operate as temporary RSUs, facilitating communication and data exchange in areas where permanent infrastructure is unavailable or damaged.

[0042] Network 150 serves as the central communication backbone within network environment 100, facilitating data exchange and coordination among various components, including multiple autonomous vehicles 110, roadside units (RSUs) 120, a central management unit 130, and temporary nodes 140. Network 150 can be composed of a combination of wired and wireless communication links, supporting various protocols such as DSRC, C-V2X, Wi-Fi-based V2X, and other related technologies. These communication links can support various data transmission modes, including unicast, multicast, and broadcast, to accommodate diverse communication needs within the network environment. Network 150 can dynamically manage bandwidth allocation, prioritize data based on urgency (e.g., safety-critical information), and use encryption and authentication measures to ensure secure data transmission. By integrating all components through network 150, the system can facilitate cooperative driving, real-time traffic management, and adaptive responses to changing conditions.

[0043] Various components within network environment 100, such as multiple autonomous vehicles 110, RSUs 120, a central management unit 130, and / or temporary nodes 140, can interact with network 150 in various configurations to support the communication and coordination required for autonomous vehicle operation. For example, multiple autonomous vehicles 110 can continuously exchange data with each other and with nearby RSUs 120 to share information about road conditions, traffic events, or navigation updates. RSUs 120 can be positioned at fixed locations along roads to collect data from vehicles 110 and relay it to other network elements, including the central management unit 130. The central management unit 130 can aggregate data from multiple RSUs 120 and vehicles 110 to provide centralized processing or coordination to optimize traffic flow or manage network resources. Temporary nodes 140, such as drones or mobile command units, can join the network to extend communication coverage, collect additional data, or provide temporary connectivity in areas where fixed infrastructure is limited or unavailable.

[0044] Network Environment 100 can operate in various configurations, including decentralized, centralized, or hybrid networks, each supporting the different communication and coordination needs of autonomous vehicles.

[0045] In a decentralized or self-organizing network configuration, autonomous vehicles 110 can communicate directly with each other via network 150 without relying on fixed infrastructure or centralized control. This configuration is suitable for scenarios where vehicles need to quickly form temporary networks to share data (such as location information, speed, sensor readings, or impending hazards). Decentralized or self-organizing networks can be useful in areas with limited infrastructure (such as rural areas) or in dynamic environments where fixed communication infrastructure may be unavailable or damaged (such as disaster areas). In this configuration, autonomous vehicles 110 can employ peer-to-peer communication protocols to establish connections and maintain network integrity. Each vehicle can act as a node, relaying data to nearby vehicles, thus enabling multi-hop communication to extend the effective range of the network.

[0046] In a decentralized or self-organizing network configuration, network environment 100 can support communication links that allow vehicle-to-vehicle (V2V) communication, where data can be directly transmitted between vehicles, thereby facilitating information sharing and coordination. In a particular embodiment, V2V communication can be conducted via wireless channels using short-range communication protocols such as DSRC, 5G NR V2X, or Wi-Fi-based V2X, enabling vehicles 110 to directly transmit data packets without relying on intermediate infrastructure such as RSU 120 or central management unit 130. DSRC can operate in the 5.9 GHz band and supports low-latency communication, making it ideal for exchanging time-sensitive information such as collision warnings, emergency braking notifications, or lane departure alerts. DSRC allows vehicles 110 to communicate directly with each other within a range of approximately 300 to 1000 meters, depending on environmental conditions. Compared to traditional DSRC, 5G NR V2X provides enhanced capabilities by utilizing cellular networks for direct vehicle-to-vehicle communication and network-assisted communication via cellular base stations. 5G NR V2X protocols can provide higher data throughput, higher reliability, and lower latency, enabling vehicles 110 to share more complex data, such as high-definition sensor maps or video streams from onboard cameras. Furthermore, 5G NR V2X can extend communication range beyond DSRC by utilizing network infrastructure for long-distance data transmission, which is very useful for coordinating maneuvers over long distances or when vehicles are not in direct line of sight. Wi-Fi-based V2X (IEEE 802.11p) can also enable short-range communication between vehicles 110, typically within a range of 100 to 300 meters. In some embodiments, V2V communication may involve multi-channel operation, where different types of data are transmitted on separate channels to avoid interference. For example, safety-critical messages may be sent on a high-priority channel, while non-critical information (such as status updates or infotainment data) may use a separate channel. Therefore, these communication protocols can be implemented flexibly, allowing vehicles 110 to switch between them based on factors such as network availability, signal strength, or communication range requirements. For example, vehicles can use DSRC for short-range communication in low-coverage areas and switch to 5G NR V2X when entering areas with robust cellular network support.

[0047] Information exchanged via V2V communication may include various types of data, such as position coordinates, speed, acceleration, braking status, trajectory prediction, and sensor data indicating road conditions, obstacles, or traffic density. The autonomous vehicle 110 can use this information to perform coordinated maneuvering functions such as collision avoidance, lane merging, adaptive cruise control, and platooning. Furthermore, V2V communication can support the sharing of situational awareness data, enabling vehicles to warn each other of sudden braking events, road hazards, or changes in driving conditions (e.g., slippery road surfaces or obstacles). To establish and maintain V2V communication, the autonomous vehicle 110 can employ protocols that support the formation of self-organizing networks, allowing vehicles to dynamically join or leave the network as they enter or leave communication range. These protocols may include message prioritization, data verification, and error correction mechanisms to ensure the reliable and timely transmission of critical information. For example, safety-related messages may receive a higher transmission priority than non-critical information such as status updates.

[0048] In some embodiments, V2V communication can implement multi-hop message relay, where vehicle 110 receives data from other vehicles and forwards it to other vehicles beyond its direct communication range. This multi-hop relay can extend the effective communication range of the network and ensure that information can be disseminated over a larger area, enabling vehicles to coordinate over greater distances, such as on highways or during emergency evacuations. Furthermore, V2V communication can support data aggregation and fusion, combining information from multiple vehicles to create a more comprehensive picture of the driving environment. For example, data from different vehicle sensors can be aggregated to detect patterns or trends, such as changes in traffic flow, emerging hazards, or road anomalies. The aggregated data can then be used to guide driving strategies or shared with other vehicles in the network environment 100 to improve overall safety and efficiency. Additionally, V2V communication can employ encryption and authentication measures to ensure data security and integrity. Each vehicle 110 can use a digital certificate or cryptographic key to verify the authenticity of transmitted messages, preventing unauthorized entities from injecting false information into the network.

[0049] In a centralized configuration, the central management unit 130 can facilitate communication and manage data flow within the network environment 100 via network 150. The central management unit 130 can collect data from multiple nodes, including vehicles 110 and RSUs 120, and then redistribute relevant information based on predefined rules or algorithms. Centralized configurations are likely most suitable for urban environments or smart city applications, where the central management unit 130 can optimize traffic flow, manage congestion, and dynamically update navigation routes based on real-time data. The central management unit 130 can also control network resources, such as bandwidth allocation or communication prioritization, to coordinate data transmission. Furthermore, in a centralized setup, RSUs 120 can act as data collection points, transmitting data back to the central management unit 130, which can process this data to make network-wide decisions, such as adjusting traffic light timings or sending alerts about road hazards ahead.

[0050] A centralized configuration can support various communication links, including vehicle-to-infrastructure (V2I) and infrastructure-to-vehicle (I2V) communication, where data can be exchanged between vehicle 110 and RSU 120 or central management unit 130. V2I communication may involve vehicle 110 sending data (such as its current location, speed, or detected road conditions) to a nearby RSU 120, which then relays this information to the central management unit 130 for processing. I2V communication can occur when the central management unit 130 or RSU 120 sends data back to vehicle 110, providing updates or instructions based on analysis of aggregated information from the network. For example, I2V communication can be used to inform vehicle 110 of impending traffic congestion, suggested detours, or dynamic speed limit information.

[0051] In certain embodiments, V2I and / or I2V communication can be conducted via wireless channels using Dedicated Short Range Communication (DSRC), Cellular V2X (C-V2X), or Wi-Fi-based V2X (IEEE 802.11p) protocols. These communication protocols can support low-latency, high-reliability data transmission between vehicles and infrastructure components, enabling real-time updates and responsive traffic management. DSRC provides short-range communication capabilities for instant data exchange with nearby RSUs 120, while C-V2X can leverage cellular networks to extend communication range and facilitate data transmission to the central management unit 130 via cellular base stations. Wi-Fi-based V2X (IEEE 802.11p) can be used in short-range communication scenarios, especially in environments with dense RSU deployments. In some cases, additional communication protocols, such as Bluetooth, Radio Frequency Identification (RFID), or satellite communication, can also be used for specific V2I and I2V applications. For example, Bluetooth can facilitate short-range data exchange in parking areas, while satellite communication can be used for remote monitoring in areas lacking traditional V2X infrastructure. These protocols can be selected based on factors such as communication range, data rate requirements, and environmental conditions to optimize the performance of the network environment.

[0052] To facilitate data exchange in a centralized configuration, the central management unit 130 can implement protocols for managing data flows between various network nodes. This may include prioritizing certain types of data, such as safety-critical information or real-time navigation updates, over low-urgency data, such as vehicle status reports. The central management unit 130 can dynamically allocate bandwidth or adjust communication parameters to ensure efficient and reliable transmission of high-priority data. Furthermore, the RSU 120 can act as an intermediary, preprocessing data before it is sent to the central management unit 130, such as filtering out redundant information or aggregating data from multiple vehicles to reduce network load.

[0053] The centralized configuration can also support the coordination of autonomous driving functions across multiple vehicles 110, enabling the central management unit 130 to facilitate cooperative maneuvering, such as synchronized lane changing or adaptive platooning, where the vehicle group maintains optimal spacing and speed. For example, the central management unit 130 can use data received from vehicles 110 to calculate the optimal driving trajectory for vehicles approaching an intersection and then send coordination instructions to each vehicle to ensure smooth traffic flow. In some embodiments, the central management unit 130 can integrate data from external sources, such as weather stations, emergency services, or public transportation systems, to further enhance the decision-making process. This additional information can be used to adjust traffic management strategies in response to changing circumstances, such as rerouting vehicles 110 or prioritizing emergency vehicles during severe weather. The central management unit 130 can continuously update its algorithms based on real-time data, enabling adaptive control of the network environment 100.

[0054] Security measures in a centralized configuration may include encryption, access control, and data integrity checks to ensure the secure and reliable exchange of data between vehicle 110, RSU 120, and central management unit 130, and to prevent unauthorized access. Central management unit 130 can manage the digital certificates or cryptographic keys of network participants and verify the authenticity of data before processing it. The centralized configuration can enable long-term data analysis by storing aggregated data collected from vehicle 110 and RSU 120 in a centralized database. The stored data can be used for historical analysis, such as identifying traffic flow patterns, planning infrastructure improvements, or training machine learning models for predictive maintenance or autonomous driving algorithms.

[0055] A hybrid configuration combines aspects of both decentralized and centralized networks, leveraging the advantages of direct V2V communication while also benefiting from centralized coordination. In this setup, vehicles 110 can communicate directly with each other, sharing time-sensitive information such as collision warnings or road condition changes, while also receiving broader updates and instructions from the central management unit 130. This hybrid configuration allows for greater flexibility in managing communication and data flows, enabling the network to adapt to changing conditions. For example, when the central management unit 130 is available, it can provide guidance and updates to vehicles based on aggregated data from RSU 120 and other sources. However, if the central management unit 130 becomes unavailable, the network can still maintain a basic level of functionality through decentralized peer-to-peer communication between vehicles 110.

[0056] In each configuration, the network can support various data exchange methods, such as broadcast, multicast, or unicast communication, depending on the vehicle's needs and network conditions. These configurations can be dynamically adjusted, enabling the network to switch between different operating modes in response to changing environmental factors or operational requirements.

[0057] Example of an autonomous vehicle circuit system Figure 2 An exemplary autonomous vehicle circuit 200 according to an embodiment of the present invention is illustrated, which may be partially or wholly included in an autonomous vehicle (e.g., autonomous vehicle 110). Figure 2 As shown, an autonomous vehicle may include onboard sensors 202, a communication module 204, a computing unit 206, an actuator 208, and a power management system 210.

[0058] Onboard sensors 202 can be configured to detect and collect data from the vehicle's surrounding environment and internal systems to enable autonomous driving functions. These sensors 202 can include various types of detection and measurement devices, such as LiDAR sensors, radar sensors, cameras, GPS receivers, ultrasonic sensors, inertial measurement units (IMUs), etc. LiDAR sensors can detect reflected signals by emitting laser pulses and measuring their time of flight, generating detailed 3D maps of the environment, which helps in identifying obstacles and road contours. Radar sensors can detect the speed and distance of surrounding objects, such as other vehicles and fixed structures, by emitting radio waves and analyzing reflected signals. Cameras can capture visual data for recognizing traffic signals, lane markings, and road signs, while GPS receivers can provide positioning information for navigation. Ultrasonic sensors can be used for short-range detection, such as when the vehicle is parked, and IMUs can measure acceleration and angular velocity to help maintain vehicle stability.

[0059] Communication module 204 enables autonomous vehicles to exchange data with external entities, including other vehicles, RSUs (e.g., RSU 120), and central management units (e.g., central management unit 130). Communication module 204 can support various V2X communication protocols, such as DSRC, cellular V2X (C-V2X), and Wi-Fi-based V2X (IEEE 802.11p). These protocols facilitate V2V, V2I, and I2V communication, enabling vehicles to share information such as location data, sensor readings, or emergency alerts. Communication module 204 includes a transceiver 204A, an antenna 204B, and a network interface 204C for sending and receiving data via a wireless channel. Transceiver 204A handles signal modulation and demodulation, while antenna 204B optimizes signal strength and communication range. Network interface 204C supports seamless switching between different communication protocols, depending on factors such as network availability or application requirements. In addition, the communication module 204 can integrate encryption and authentication mechanisms to ensure data security and integrity during transmission and prevent unauthorized access or tampering.

[0060] The computing unit 206 is responsible for processing data collected by the onboard sensors 202 and the communication module 204, making driving decisions, and managing the operation of various vehicle systems. The computing unit 206 may include a central processing unit (CPU), a graphics processing unit (GPU), and other components such as an artificial intelligence (AI) accelerator, data storage devices, etc. Figure 3 A more detailed description is provided. The CPU handles general computing tasks, including system management, network communication, and running control algorithms. The GPU can be used for parallel processing tasks such as image recognition, sensor data fusion, and real-time rendering of the environment. The AI ​​accelerator can be a dedicated hardware module optimized for deep learning and neural network inference, enabling the vehicle to perform tasks such as object detection, path planning, and predictive analytics with low latency. The computing unit 206 may also include data storage components, such as solid-state drives (SSDs) for long-term storage of maps, software, and historical data, and random access memory (RAM) for temporary data storage during processing tasks. These computing units 206 can work together to analyze sensor data in real time, plan driving routes, and generate control commands for the vehicle's actuators 208. In addition, the computing unit 206 can be equipped with software modules for different functions, including perception, localization, motion planning, and control, enabling the autonomous vehicle to operate safely and efficiently in various driving scenarios.

[0061] Actuator 208 is responsible for executing control commands generated by computing unit 206, enabling the autonomous vehicle to perform the physical actions required for driving. Actuator 208 may include components such as steering actuator 208A, brake actuator 208B, throttle actuator 208C, and transmission control 208D. Steering actuator 208A controls the vehicle's direction by adjusting the angle of the steering mechanism based on a calculated path. Brake actuator 208B can adjust the braking force applied to the wheels, allowing the vehicle to decelerate or come to a complete stop as needed. Throttle actuator 208C can control the vehicle's acceleration by adjusting the throttle position, thereby managing the power output of the engine or electric motor. For vehicles equipped with automatic transmissions, transmission control 208D can manage gear shifts to optimize performance and efficiency. Actuator 208 can be connected to various sensors that provide feedback on the current state of the vehicle's motion, such as wheel speed sensors or position sensors, enabling closed-loop control. This feedback allows computing unit 206 to adjust actuator commands in real time to improve stability and responsiveness, ensuring the vehicle maintains the required trajectory and speed. In addition, actuator 208 can support advanced vehicle dynamic control systems, such as electronic stability control (ESC) or adaptive suspension, to enhance the safety and comfort of autonomous vehicles.

[0062] The power management system 210 is responsible for supplying and regulating power to the autonomous vehicle. The power management system 210 may include components such as a battery 210A, an energy management controller 210B, a power distribution unit 210C, and a regenerative braking system 210D. The battery 210A can serve as the vehicle's primary power source, providing energy to the propulsion system, onboard sensors 202, computing unit 206, communication module 204, and other auxiliary systems. The energy management controller 210B monitors and optimizes power utilization in the vehicle subsystems to maximize efficiency and extend driving range. The energy management controller 210B can dynamically allocate power to different components based on current demand, such as increasing the power of computing unit 206 during intensive data processing tasks or adjusting the power level of actuator 208 under high-demand driving conditions. The power distribution unit 210C is responsible for delivering appropriate voltage and current to each subsystem to ensure stable operation under various conditions. The power distribution unit 210C may also include safety functions such as circuit protection and emergency power-off mechanisms. The regenerative braking system 210D can capture kinetic energy during braking events and convert it into electrical energy to charge the battery. In a specific embodiment, the regenerative braking system 210D can be integrated with a brake actuator to provide smooth deceleration while maximizing energy recovery.

[0063] The power management system 210 can also coordinate with external charging infrastructure (such as electric vehicle charging stations) to manage charging cycles and optimize battery health. In some embodiments, the power management system 210 can support vehicle-to-grid (V2G) communication, enabling vehicles to interact with the grid for functions such as load balancing or energy storage.

[0064] Example computational unit circuit system Figure 3 The illustration shows a schematic diagram of an example circuit according to an embodiment of the present disclosure, which may be partially or wholly included in a computing unit 206 of an autonomous vehicle (e.g., autonomous vehicle 110). The computing unit 206 may include a CPU 206A, a GPU 206B, and an AI accelerator 206C. The CPU 206A may include components such as processing circuitry 302, memory 304, input / output circuitry 306, communication circuitry 308, and encryption / decryption circuitry 310. The GPU 206B may include multiple multiprocessors 314, shared memory 316, device memory 318, and multiple processors for each multiprocessor 314. P_1 , P_2 … P_i322. Multiple registers 324 and constant memory 320 for each multiprocessor 324. The AI ​​accelerator 206C can be configured to perform dedicated computing for artificial intelligence tasks, such as deep learning and neural network inference. The AI ​​accelerator 206C may include components such as multiple TPUs 330, neural network cores 332, on-chip memory 334, and control circuitry 336. The AI ​​accelerator 206C can work in conjunction with the GPU 206B and CPU 206A to perform real-time processing of tasks such as object detection, sensor fusion, and decision-making in autonomous driving. It should be understood that... Figure 3 For exemplary embodiments only, computing unit 206 may contain more, fewer, or different components than those shown in the figures. The arrangement of components may also vary. Depending on specific implementation requirements, computing unit 206 may include additional components or omit certain components. For example, computing unit 206 may include a CPU operatively coupled to multiple GPUs and an AI accelerator, wherein the GPUs and AI accelerators are interconnected using high-speed interconnect technologies such as NVLink®, enabling efficient data sharing and parallel processing of AI tasks. Additionally or alternatively, computing unit 206 may include multiple CPUs, AI accelerators, or GPUs interconnected via PCIe links, enabling collaborative processing and workload distribution across components. In some configurations, CPUs, GPUs, and AI accelerators may be interconnected using a combination of PCIe, NVLink®, or other high-speed interconnect technologies, facilitating seamless communication and data transfer between processing units. Including an AI accelerator can improve the system's ability to perform complex machine learning and deep learning computations and reduce latency. Alternatively, depending on the specific processing requirements of the system, computing unit 206 may include only one CPU and one AI accelerator.

[0065] In computing unit 206, CPU 206A can serve as the primary processing unit, responsible for general computing and control operations (e.g., performing encryption / decryption) related to one or more functions described herein. For example, CPU 206A can execute instructions, manage data flow, and coordinate the activities of other components within computing unit 206. CPU 206A can include various circuits, such as processing circuitry 302 for performing arithmetic and logical operations, memory 304 for storing data and instructions, input / output circuitry system 306 for interfacing with external devices, communication circuitry 308 for handling data exchange with other systems or networks, and encryption / decryption circuitry 310 for performing cryptographic functions. Therefore, CPU 206A can be configured to handle various workloads, including data processing, task scheduling, and control functions, enabling it to support various applications depending on the specific needs of computing unit 206.

[0066] Although the term "circuit system" as used herein is described in some cases using functional language, it should be understood that a specific implementation necessarily involves using specific hardware to perform the functions associated with the various circuits described herein. It should also be understood that some components may contain similar or common hardware. For example, two sets of circuits may both utilize the same processing circuit system, communication circuit system, memory, etc., to perform their related functions, thus eliminating the need for redundant hardware for each set of circuits. In this regard, it should be understood that some components described in relation to system 400 may be housed together, while others may be housed separately. While the term "circuit" should be broadly understood to include hardware, in some embodiments, the term "circuit" may also include software for configuring the hardware. In some embodiments, other elements of computing unit 206 may provide or supplement the functionality of a particular circuit. For example, processing circuitry 302 may provide processing functionality, memory 404 may provide storage functionality, communication circuitry 408 may provide network interface functionality, and so on.

[0067] Processing circuitry 302 can be implemented in a variety of different ways; for example, it may include one or more processing circuits configured to operate independently. Additionally or alternatively, processing circuitry system 302 may include one or more processors configured in series via a bus to enable independent execution of instructions, pipelined operation, and / or multi-threaded processing. For example, processing circuitry system 302 can be implemented in various ways, including one or more microprocessors with accompanying digital signal processors, one or more processors without accompanying digital signal processors, one or more coprocessors, one or more multi-core processors, one or more controllers, processing circuitry systems, one or more computers, various other processing elements (including integrated circuits, such as, for example, ASICs (Application-Specific Integrated Circuits) or FPGAs (Field-Programmable Gate Arrays)), or some combination thereof. The term "processing circuitry" can be understood to include single-core processors, multi-core processors, multiple processors within a device, and / or remote or "cloud" processors. Therefore, although in Figure 3 The diagram illustrates a single processor; in some embodiments, processing circuitry 302 may include multiple processors. These processors may be implemented on a single computing device or distributed across multiple computing devices configured to work collaboratively. These processors may communicate operationally with each other and may be collectively configured to perform one or more functions of the system 400 described herein.

[0068] In one exemplary embodiment, processing circuitry 302 may be configured to execute instructions stored in memory 304 or other locations accessible to processing circuitry 302. Alternatively or additionally, processing circuitry 302 may also be configured to perform hard-coded functions. Thus, whether configured by a hardware approach, a software approach, or a combination of both, processing circuitry 302 may represent an entity (e.g., physically implemented in circuit form) capable of performing operations and being configured accordingly according to embodiments of this disclosure. Alternatively, as another example, when processing circuitry 302 is implemented as an executor of software instructions, these instructions may specifically configure processing circuitry 302 to perform one or more algorithms and / or operations described herein when the instructions are executed. For example, when processing circuitry 302 executes these instructions, these instructions may cause computing unit 206 to perform one or more of its functions described herein.

[0069] Memory 304 may be non-volatile and may include, for example, one or more volatile and / or non-volatile memories, or some combination thereof. In other words, memory 304 may be, for example, an electronic storage device (e.g., a non-volatile computer-readable storage medium). Memory 304 may be configured to store information, data, content, applications, instructions, etc., to enable a device (e.g., computing unit 206) to perform various functions according to exemplary embodiments of this disclosure. Although Figure 3 While shown as a single memory, memory 404 may include multiple memory components. These multiple memory components may be implemented on a single computing device or distributed across multiple computing devices. In various embodiments, memory 304 may include, for example, a hard disk, random access memory (RAM), virtual memory, non-volatile memory (NVRAM), cache memory, flash memory, compressed configured disk read-only memory (CD-ROM), digital versatile optical disc read-only memory (DVD-ROM), optical disc, circuitry for storing information, or some combination thereof. Memory 304 may be configured to store information, data, applications, instructions, etc., enabling computing unit 206 to perform various functions according to the exemplary embodiments discussed herein. For example, in at least some embodiments, memory 304 may be configured to buffer data for processing by processing circuitry system 302. Additionally or alternatively, in at least some embodiments, memory 304 may be configured to store program instructions for execution by processing circuitry system 302. Memory 404 may store information in the form of static and / or dynamic information. Computing unit 206 may store and / or use this stored information in the course of performing its functions.

[0070] In some embodiments, the processing device 302 further includes an input / output circuitry system 306 that can communicate with the processing circuitry 302 to provide audio, visual, mechanical, or other outputs, and / or, in some embodiments, receive input instructions from a user or other source. In this sense, the input / output circuitry 306 may include devices for performing analog-to-digital data conversion and / or digital-to-analog data conversion. The input / output circuitry 306 may support, for example, displays, touchscreens, keyboards, mice, image capture devices (e.g., cameras), microphones, and / or other input / output mechanisms. The input / output circuitry 306 may include a user interface and may include a web user interface, mobile applications, kiosks, etc. The input / output circuitry 306 may interface with one or more units, devices, sensors, actuators, communication modules, storage devices, external processing units, peripheral devices, etc. These outputs may then be transmitted to one or more destinations, such as display units, storage systems, control systems, processors (e.g., processing circuitry 302), network interfaces, peripheral devices, external systems, etc., for further processing.

[0071] In some embodiments, the input / output circuitry 306, used in conjunction with one or more components described herein (e.g., processing circuitry 302), can be configured to control one or more functions of a display or one or more user interface elements via computer program instructions (e.g., software and / or firmware) stored in memory accessible to the processing circuitry 302 (e.g., memory 304, etc.). In some embodiments, certain aspects of the input / output circuitry 306 can be simplified compared to cases where the computing unit 206 can be implemented as an end-user machine or other type of device designed for complex user interactions. In some embodiments (e.g., other components discussed herein), the input / output circuitry system 306 can be omitted from the computing unit 206. Although the computing unit 206 may contain more than one input / output circuit, Figure 3 Only one is shown in the document to avoid making the public content too complex (as is the case with the other components discussed in this article).

[0072] In some embodiments, communication circuitry 308 includes any device, such as a device or circuit implemented in hardware, software, firmware, or a combination of hardware, software, and / or firmware, configured to receive data from and / or transmit data to a network and / or any other device, or associated circuitry. In this regard, communication circuitry 308 may include, for example, a network interface for enabling communication with a wired or wireless communication network. For example, in some embodiments, communication circuitry 308 may be configured to receive and / or transmit any data that can be stored in memory 304 using any protocol available for communication between computing devices. For example, communication circuitry 308 may include one or more network interface cards, antennas, transmitters, receivers, buses, switches, routers, modems, and supporting hardware and / or software and / or firmware / software, or any other device suitable for communication over a network. Additionally or alternatively, in some embodiments, communication circuitry 308 may include circuitry for interacting with one or more antennas to transmit signals via one or more antennas or to process signals received via one or more antennas. These signals may be transmitted by computing unit 206 using various wireless communication technologies suitable for autonomous vehicles. These technologies can include Bluetooth® v1.0 to v5.0 or Bluetooth Low Energy (BLE) for short-range communication tasks, such as exchanging data with nearby devices, such as smartphones, in-vehicle systems, or diagnostic tools. Ultra-wideband (UWB) can be used for precise positioning and short-range data transmission between vehicle components or with other nearby vehicles. Infrared wireless (e.g., IrDA) can be used for specific short-range line-of-sight communication applications, such as vehicle identification in automated parking facilities. Furthermore, these signals can be transmitted using Wi-Fi-based V2X protocols (e.g., IEEE 802.11p), which enables communication with roadside infrastructure, other vehicles, or network access points at short to medium ranges. NFC can be used for proximity-based data transmission, such as vehicle access control or initiating secure communication links. C-V2X technologies, including 4G LTE and 5G NR, can support longer-range communication, enabling real-time data exchange with infrastructure, cloud services, or other vehicles, thereby facilitating collaborative driving and traffic management. Other wireless technologies, such as WiMAX (Global Microwave Interconnection Access), can also be used in specific application scenarios requiring high data throughput or extended communication range, although these technologies are not common in current automotive applications. Each technology can be selected based on the specific communication requirements (such as range, latency, or bandwidth) in the autonomous vehicle network.

[0073] The circuitry of CPU 206A can be connected via various interconnect architectures depending on its physical layout and implementation within computing unit 206. Within CPU 302, different circuits, such as processing circuitry 302, memory 304, input / output circuitry 306, and communication circuitry 308, can be linked via internal buses or interconnect structures to facilitate data transfer between these components. For example, CPU 206A can use an internal crossbar switch or ring bus architecture to interconnect these circuits, providing a pathway for efficient data transfer between the processing core, cache memory, and other functional units. In some configurations, CPU 206A can employ a hierarchical bus structure, where the front-side bus (FSB) connects processing circuitry 302 to memory 304, while separate buses (e.g., peripheral buses) connect input / output circuitry 306 and communication circuitry 308. Internal interconnects can also be configured to support consistent memory access, ensuring that data changes in one part of the CPU are reflected in other connected components.

[0074] Therefore, a non-volatile computer-readable storage medium (e.g., it may be memory 304) can be configured to store firmware, one or more applications and / or other software containing instructions and / or other computer-readable program code fragments that can be executed to direct the operation of computing unit 206, thereby implementing various operations, including the examples described herein. Thus, a series of computer-readable program code fragments can be embodied in one or more computer program products and can be used with devices, computing unit 206, databases and / or other programmable devices to produce the machine-implemented processes discussed herein. It should also be noted that all or part of the information discussed herein may be based on data received, generated and / or maintained by one or more components of computing unit 206. In some embodiments, one or more external systems (e.g., remote cloud computing and / or data storage systems) may also be utilized to provide at least some of the functionality discussed herein.

[0075] The GPU 206B in computing unit 206 can be used as a dedicated processing unit designed for handling parallel computing tasks. GPU 206B may include various components to support its high-performance capabilities, such as multiple multiprocessors 314, each of which may contain a set of independent processing units (P_1, P_2, ..., P_i) 322. Each multiprocessor 314 may also include its own shared memory 316 to facilitate efficient data access and communication between processors within the multiprocessor. Furthermore, GPU 206B may include device memory 318, which serves as the primary storage device for data processed by the GPU, and constant memory 320, which can be used to store read-only data that remains unchanged during the execution of a specific task.

[0076] The multiprocessors 314 can be configured to run in parallel, enabling the GPU 206B to execute multiple threads simultaneously, thereby accelerating tasks that can be broken down into smaller concurrent operations. Each multiprocessor 314 can include a set of registers 324 associated with its processor, which provide fast access to frequently used data during computation. The use of shared memory 316 in each multiprocessor 314 can reduce latency and increase throughput by allowing threads to quickly share data without accessing device memory 318.

[0077] Device memory 318 can be used as the main memory resource for GPU 206B and can include various types of memory, such as GDDR (Graphics Double Data Rate) memory or High Bandwidth Memory (HBM), depending on the system's performance requirements. Device memory 318 can be used to store large datasets, textures, or other information required for processing tasks, and it can be accessed by both GPU 206B and (in some configurations) CPU 206A. Constant memory 320 can be used to store data that does not change during processing, such as configuration parameters or lookup tables, which processor 322 can access quickly without incurring additional latency.

[0078] GPU 206B can support various interconnect architectures for communication between multiprocessors 314, shared memory 316, and other components within computing unit 206. For example, GPU 206B may include internal crossbar or ring interconnects to facilitate data flow between multiprocessors 314, shared memory 316, and device memory 318. In configurations where GPU 206B is operatively coupled to one or more additional GPUs, high-speed interconnects such as NVLink can be used to facilitate data transfer and memory resource sharing among multiple GPUs, thereby enhancing the parallel processing capabilities of large-scale computing.

[0079] In some embodiments, CPU 206A and GPU 206B can be operatively coupled via various interconnect architectures, depending on their physical arrangement and implementation within compute unit 206. In embodiments where both CPU 206A and GPU 206B are integrated on the same SoC, their circuitry can communicate via high-speed interconnects designed for low latency and high bandwidth. In this configuration, CPU 206A and GPU 206B can share a unified memory space, enabling them to efficiently access common data without incurring the overhead associated with data transfers between individual components. In embodiments where CPU 206A and GPU 206B reside on different SoCs, their circuitry can be connected via a PCIe bus or a similar high-speed interface for data exchange. In example embodiments of this scenario, each SoC may have its own dedicated memory, and explicit data transfer between the CPU's memory (e.g., memory 304) and the GPU's memory (e.g., device memory 318) may be required. Furthermore, when the CPU 206A and GPU 206B are housed in the same server but on separate motherboards, they can be connected via interconnects such as NVLink® interconnects, which are designed for high-speed communication between one or more CPUs and one or more GPUs, as described above. This approach offers higher bandwidth and enables faster data sharing compared to traditional PCIe connections, which is particularly advantageous for applications requiring rapid access to large datasets. In summary, the various circuit connectivity options within the compute unit 206 can take many forms depending on the design choices made during implementation. Each configuration presents different trade-offs in terms of performance, scalability, and complexity, and the chosen architecture can be optimized based on the specific workload requirements and performance goals of the system.

[0080] Computing unit 206 can be configured to support various operations across different domains, depending on specific implementation requirements and the configuration of its components. For example, computing unit 206 can be used to perform simulation operations, including but not limited to simulating physical processes, verifying software on autonomous machines, and performing hardware testing. Computing unit 206 can handle parallel processing tasks via GPU 206B and perform general-purpose processing via CPU 206A, enabling it to efficiently execute computationally demanding simulations. Furthermore, computing unit 206 can facilitate digital twin operations, where real-world processes are digitally mirrored to monitor, optimize, or predict system behavior.

[0081] The AI ​​Accelerator 206C is a dedicated hardware component configured to perform artificial intelligence tasks, such as deep learning, neural network inference, and other machine learning computations, efficiently and with low latency. The AI ​​Accelerator 206C may include multiple TPUs 330, a neural network core 332, on-chip memory 334, and control circuitry 336.

[0082] The TPU 330 can be a dedicated processing unit optimized for performing tensor operations, which are frequently used in deep learning algorithms. These TPU 330s can accelerate matrix multiplication and other linear algebra operations that form the core of many neural network computations, such as convolutional layers in image recognition tasks. TPU configurations can allow multiple computations to be executed in parallel, thereby increasing throughput and reducing processing time for large-scale AI models.

[0083] The Neural Network Core 332 can be composed of dedicated hardware modules configured to perform various neural network operations, such as convolution, fully connected layers, pooling, and activation functions. These cores can be designed to handle the various types of layers and computations present in neural network architectures, making them suitable for diverse AI tasks, including object detection, natural language processing, and sensor fusion. The Neural Network Core 332 can work in conjunction with the TPU 330 to optimize the execution of complex AI algorithms.

[0084] The on-chip memory 334 can be a high-speed memory integrated within the AI ​​accelerator 206C, used to store intermediate data, neural network weights, and frequently accessed variables during computation. The on-chip memory 334 reduces latency by providing fast access to critical data, enabling real-time processing of AI tasks. The on-chip memory 334 can be organized into multiple levels, such as a cache hierarchy, to ensure efficient data retrieval and minimize latency during execution.

[0085] Control circuitry 336 manages the operation of AI accelerator 206C by scheduling tasks, allocating resources, and coordinating data flow between internal components. Control circuitry 336 can dynamically adjust processing priorities based on workload to optimize performance, ensuring that tasks such as neural network inference or sensor fusion are executed with minimal latency. Control circuitry 336 can also interface with other parts of computing unit 206 to synchronize the operation of the AI ​​accelerator with overall system requirements.

[0086] Various components, including TPUs, neural network cores, on-chip memory, and control circuitry, can be operationally interconnected using interconnect structures. These interconnect structures can be configured to facilitate high-speed data transfer and efficient communication between components, thereby optimizing the execution of AI tasks. Examples of such interconnect structures include high-bandwidth memory interfaces, crossbar switches, and mesh networks, which provide low-latency communication paths. In some embodiments, the interconnect structure may leverage technologies such as NVIDIA's NVLink, which enables high-speed data exchange between processing units, allowing multiple AI accelerators to work in parallel or share data with other processors, such as one or more GPUs or one or more CPUs. The interconnect structure may also support memory coherence protocols, ensuring that data stored in the on-chip memory 334 remains consistent across different processing elements during computation.

[0087] In some embodiments, computing unit 206 may include external data storage (not shown) for storing large datasets, software, and historical information that are not immediately needed for real-time processing but are intended for long-term operation of the autonomous vehicle. External data storage may include components such as solid-state drives (SSDs), hard disk drives (HDDs), and non-volatile memory, each catering to different storage needs. SSDs can provide high-speed access to data required for tasks such as caching frequently accessed map data or software libraries, while HDDs can be used for long-term storage of less frequently accessed information, such as vehicle logs or sensor data archives. External data storage may also store system data, including configuration files, firmware updates, and security credentials. Data interfaces in external data storage can facilitate communication with CPU 206A, GPU 206B, and AI accelerator 206C, enabling these components to retrieve and store data as needed. Data storage may also support encryption and access control mechanisms to protect the integrity and confidentiality of stored information, especially when handling sensitive data related to vehicle operation or user privacy. Furthermore, external data storage can enable data logging and analysis by storing raw sensor data collected during vehicle operation, which can be used for post-processing, training machine learning models, or system diagnostics.

[0088] It should be noted that the description of computing unit 206 and its components provided herein represents only one embodiment of the present invention. The specific configurations, layouts, and functions described are merely examples and are not intended to limit the scope of the invention. Computing unit 206 may include more, fewer, or alternative components than those described, and the arrangement of components may vary depending on specific implementation requirements. For example, computing unit 206 may include multiple GPUs, CPUs, or AI accelerators, which may be interconnected using various high-speed interconnect technologies (such as NVLink® or PCIe), or may contain only a subset of the components. Furthermore, certain functions may be implemented using different hardware, software, firmware, or combinations thereof. The embodiments described herein are for illustrative and exemplary purposes only, and various modifications, adaptations, and variations can be made without departing from the scope and spirit of the invention.

[0089] Example methods for direct authentication between two entities in a dynamic network environment Figure 4 An example method 400 for direct authentication between two entities in a dynamic network environment is illustrated according to an embodiment of the present disclosure.

[0090] As used herein, “entity” can refer to any device or system capable of participating in a dynamic network environment (e.g., network environment 100). This entity may be equipped with communication modules, sensors, processing units, or other components that enable it to detect nearby devices, exchange data, perform encryption and decryption operations, and connect to the network. Examples of entities include, but are not limited to, autonomous vehicles (e.g., autonomous vehicle 110), drones, mobile computing devices, roadside units (e.g., RSU 120), central management units (e.g., central management unit 130), and various types of infrastructure components.

[0091] For example, autonomous vehicles can function as entities, using their onboard systems to communicate safely with other vehicles, roadside infrastructure, or mobile command units. Drones can communicate with the central management unit or other drones to share sensor data, flight information, or emergency alerts. RSUs can function as entities, providing information such as traffic signals or road hazard warnings by facilitating data exchange with passing vehicles or drones. The central management unit can coordinate communication between different entities in the network, enabling safe data sharing and centralized control of network activities.

[0092] Entities can also include other types of connected devices, such as wearable sensors used by personnel in industrial or emergency response scenarios, mobile command units set up for temporary operations, or smart devices used in smart city applications. These diverse entities can detect the presence of dynamic networks, assess available communication channels, and initiate secure connections, thereby allowing participation in self-organizing or temporary communication networks. This capability supports secure data transmission and coordination with other entities or network infrastructure components as needed.

[0093] The term "entity" is broadly used to encompass any device or system capable of performing the functions described herein in a manner that facilitates secure communication in a dynamic network environment, where communication links can be established and terminated based on factors such as proximity, network conditions, or operational requirements. An entity may use its onboard systems and communication capabilities to perform the steps described herein. Specifically, as described herein, an entity may be configured with processing units, communication modules, and encryption frameworks to perform tasks such as detecting nearby devices, sending and receiving communication requests, encrypting data, and transmitting encrypted information. The entity's onboard computing system (e.g., computing unit 206) may manage the process flow, executing each step in response to specific triggers or conditions detected in the network.

[0094] At block 402, the first entity can detect the presence of a second entity in its immediate vicinity. This detection can be achieved through various techniques, such as proximity sensing, network discovery protocols, or direct wireless communication, enabling the first entity to identify nearby devices within an ad hoc network. In an example embodiment, each entity may have a defined connection radius within which it can detect the presence of other entities. The connection radius may represent the effective range of an entity's communication module, such as a wireless transceiver, proximity sensor, or other detection mechanism. Whenever another entity enters this connection radius, the first entity can identify its presence in various ways, such as monitoring signal strength, analyzing a unique network identifier, or detecting transmitted signals. In some embodiments, the connection radius may be dynamic and adjusted based on factors such as network density, environmental conditions, or the specific communication protocol used. For example, in high-density network areas, the connection radius may be reduced to minimize interference and optimize detection accuracy; while in open or rural environments, the radius may be increased to increase detection range. Furthermore, the detection mechanism may involve periodic scanning or continuous monitoring to identify any entity entering or leaving the connection radius. In some cases, the detection process may include verification measures, such as checking digital certificates or comparing network credentials, to ensure that the detected entity is authorized to communicate. Once the presence of a second entity is detected within the connection radius, the first entity can initiate secure communication.

[0095] At block 404, after detecting the second entity, the first entity can send a first communication request to the second entity. As described herein, detecting the presence of the second entity in close proximity to the first entity can trigger the initiation of a communication process, signaling the second entity's presence within range, and potentially enabling secure data exchange. In some embodiments, detection may involve using proximity sensors, network discovery protocols, or other technologies to identify the presence of the second entity and initiate the request. The first communication request can serve as an indication that the first entity wishes to establish a secure communication channel with the second entity for information exchange.

[0096] A first entity may initiate a communication request for various reasons to establish a secure exchange of information with a second entity. For example, the first entity may want to obtain up-to-date information about road conditions, traffic, weather, or other environmental factors encountered by the second entity. Such information is very useful for adjusting the first entity's driving strategy, especially when local updates are not available from a centralized source. In some embodiments, the first entity may also send requests to coordinate driving maneuvers, such as lane changes, performing convoy driving maneuvers, or navigating intersections. Establishing communication allows the first and second entities to share data, such as speed, acceleration, or trajectory information, to facilitate safe and efficient coordination.

[0097] In certain situations, the first entity may send a communication request to alert the second entity to an emergency or hazard in the vicinity, such as an accident, road debris, or sudden weather changes. The first entity can share location data and relevant context to help the second entity make informed decisions regarding its driving strategy. Furthermore, the communication request can be used to exchange diagnostic information about mechanical health, enabling the first entity to inquire whether the second entity has encountered similar problems or to coordinate responses to shared issues.

[0098] The first communication request may include additional information to facilitate data exchange, such as the location, speed, or expected trajectory of the first entity. The second entity may also use this additional information to determine the level of trust associated with the first entity. For example, the first entity may send authentication tokens, digital certificates, or other security parameters to verify its identity and establish the legitimacy of the communication request. In some embodiments, the first entity may include detailed information about its operational status, fleet affiliation, or recent communication history to help the second entity assess the credibility of the request. The first entity may also specify the data type requested or the priority level of the request, which can further inform the second entity's decisions regarding the appropriate response level and data sharing level. In some embodiments, the first entity may provide contextual information, such as recent observations of the environment or known hazards, to provide the second entity with additional context regarding the request and encourage the sharing of relevant data. This contextual information can serve as an indicator of the first entity's operational awareness and may influence the level of trust assigned by the second entity.

[0099] At block 406, in response to receiving the first communication request, the second entity may encrypt the second primary information (sp) associated with the second entity. In a particular embodiment, before encrypting the second primary information (sp), the second entity may determine the trust level associated with the first entity. The trust level may be evaluated based on various factors extracted from the content of the communication request, such as the identity of the first entity, any authentication credentials provided, the urgency or priority of the request, and the history of previous interactions between the entities. For example, if the communication request contains authentication credentials, such as digital certificates or security tokens, the second entity may verify these credentials against a known list of trusted entities to determine whether the requester (e.g., the first entity) is identified and authorized. Furthermore, the context or type of the requested data may also affect the trust level; a high-priority request for urgent coordination may be considered to have a higher trust level than a regular request for non-critical information.

[0100] The second entity can also consider any past communication history with the first entity or any other entity in the same owner-owned group as the first entity to further guide its trust assessment. For example, if the second entity has previously communicated with other entities managed by the first owner and considered those interactions reliable, this can positively influence the trust level assigned to the first entity. Conversely, if the second entity has encountered problems such as data inconsistencies or failed authentication attempts when interacting with other entities in the first entity group, it may lead to a lower trust level for the first entity. By considering not only the communication history with individual first entities but also with other related entities under the same owner, the second entity can more comprehensively assess trust and leverage broader prior experience to guide its decision-making process.

[0101] In specific embodiments, the trust level can be represented as a numerical value, probability score, or weighting factor that quantifies the confidence of a second entity in the trustworthiness of a first entity. In some embodiments, the trust level can be calculated using a scoring system that considers various weighting factors derived from the communication request and other contextual information. The scoring system can assign numerical values ​​to specific attributes, such as the validity of authentication credentials, the priority of the request, the nature of the requested data, and the history of previous interactions. These values ​​can be combined using a weighted sum to produce an overall trust score for the first entity. For example, the trust level T can be calculated as follows: P = A1⋅P + P2⋅P + P3⋅P + P4⋅P, where: A represents the authentication score, based on the validity of credentials such as digital certificates or security tokens; P represents the priority score, based on the urgency or importance of the communication request; H represents the history score, based on the reliability of past interactions and communications with the first entity; C represents the context score, based on factors such as the data type of the request or the operational status of the first entity; and P1, P2, P3, and P4 are weighting factors that can be adjusted based on the specific requirements of the system, thereby assigning more or less importance to each attribute when determining the overall trust level.

[0102] In alternative embodiments, the trust level can be represented as a probability score, which indicates the likelihood of trusting a first entity based on known factors. For example, Bayesian inference techniques can be employed to update the probability score based on new evidence provided by the communication request. The trust probability can increase if the first entity provides valid authentication credentials, and decrease if the request lacks certain information or indicates anomalous behavior. In other embodiments, fuzzy logic methods can be used to determine the trust level. Various factors influencing the trust level can be viewed as fuzzy variables with different fuzzy group memberships (e.g., "high trust," "medium trust," "low trust"). Fuzzy logic rules can then be applied to combine these fuzzy variables and determine the overall trust level. For example, a rule could specify that if the authentication score is "high" and the historical score is "medium," the trust level should be classified as "medium-high." Furthermore, the trust level can be dynamically calculated and adjusted in real-time based on ongoing interactions between entities. In some embodiments, a time decay factor can be applied to historical scores, giving higher weight to recent interactions while gradually reducing the impact of earlier communication events, thereby allowing the trust level to reflect the most recent relationship between entities. In scenarios involving multiple entities, the trust level can also incorporate information from other trusted sources. For example, if other trusted entities in the network have recently interacted with the first entity and reported positive results, this information can be incorporated into the trust level calculation for the second entity. The calculated trust level can then be compared to one or more predefined thresholds to determine an appropriate data-sharing strategy. For instance, if the trust level exceeds a certain threshold, the second entity can share more sensitive information, but with limited encryption; conversely, if the trust level is below that threshold, stronger encryption measures can be applied to protect the data.

[0103] Based on the determined trust level, the second entity can decide not only whether to encrypt secondary primary information, but also which specific information should be categorized as primary information requiring encryption. The second entity can use the calculated trust level to assess the required level of data protection. At a higher trust level, the second entity may consider certain sensitive information securely shared at the lowest encryption level, or even transmitted unencrypted when the trust level exceeds a preset threshold. In this case, the risk of unauthorized access is considered lower, so the second entity can prioritize faster data exchange or a more permissive encryption strategy. At a lower trust level, the second entity can take a more cautious approach, categorizing a broader range of information as primary information requiring encryption. This may include proprietary data, operational details, or other sensitive content that the second entity wishes to protect. Furthermore, the encryption strategy may involve selectively encrypting certain fields in the data while allowing less sensitive information to remain unencrypted.

[0104] After determining the primary information to be encrypted (e.g., secondary primary information (sp)), the second entity can encrypt the secondary primary information (sp). Encryption can be performed based on the secondary primary information (sp), the encoded variable (y), and the secondary public key (e2) associated with the second entity. The encryption process ensures the security and reversibility of the encryption, allowing only authorized entities to decrypt the information using the corresponding private key. The secondary public key (e2) can be a component of the public-private key pair associated with the second entity, where the key pair was generated to implement the secure encryption and decryption process. The secondary public key (e2) can be a large prime number or have large prime factors. For example, the secondary public key (e2) can satisfy the condition... ,in It is the Euler totient function. Here, Furthermore, e2 may be related to Coprime, thus ensuring that e2 has an inverse modulus. This is a necessary condition for the existence of the second private key (f2), where f2 satisfies the equation The number. In other words, choose e2 such that the product of e2 and f2 divided by The remainder is 1. Alternatively or additionally, the second public key (e2) can also satisfy the condition. ,in It is the Carmichael totient function. Here, lcm is the least common multiple. Similarly, e2 can be used with... Coprime, thus ensuring e2 modulus The existence of an inverse is a necessary condition for the existence of the corresponding second private key (f2), where f2 satisfies the equation The number.

[0105] The encoded variable (y) can be a parameter used during the encryption process to modify the second primary information (sp) before or during the encryption operation. The encoded variable (y) can be a constant, a randomly generated number, a value derived from some aspect of the encryption scheme, etc. The encoded variable (y) can add a layer of complexity to the encryption process, making the final encrypted second primary information (esp) more secure. Therefore, in the encryption algorithm described in this paper, the encoded variable (y) can be a rational number not equal to 1.

[0106] To encrypt the second primary information (sp), the second entity can use binary operations that satisfy the Quandle axiom. Specifically, the encrypted main information (esp) = sp y, and sp y= In one exemplary embodiment, the second primary information (sp) may satisfy the condition , where n is a composite number of the form n = p ⋅ q, and p and q are prime numbers. Choosing n as the product of two prime numbers is fundamental to the security of the encryption algorithm. Factoring n back into its prime components without prior knowledge of p and q is extremely difficult, making it hard for unauthorized parties to decrypt the key information without access to the corresponding second private key (f2).

[0107] At block 408, the second entity may send encrypted second primary information (ESP) and second supplementary information (SS) to the first entity. This transmission may be conducted via a secure communication channel established in response to the first communication request. The encrypted second primary information (ESP) may be transmitted together with the supplementary information (SS), which may contain unencrypted data. The supplementary information (SS) may contain data provided in response to the first communication request from the first entity. When the supplementary information (SS) does not contain sensitive or proprietary content, it may be shared in unencrypted form. The supplementary information (SS) may access specific data types initially requested by the first entity, such as road condition updates, traffic patterns, weather forecasts, or non-critical sensor readings collected by the second entity. By sending the supplementary information (SS) together with the encrypted second primary information (ESP), the second entity enables the first entity to access useful data while still protecting any sensitive content.

[0108] Upon receiving a response from the second entity, the first entity can examine the supplemental information (SS) and determine if additional details, which could be a portion of the encrypted second primary information (ESP), are required. If the supplemental information (SS) alone is insufficient to satisfy the first entity's request, the first entity can initiate subsequent communication to request access to a specific portion of the previously encrypted primary information. In this case, the second entity can assess the trust level and decide whether to resend the response to the first entity, potentially allowing access to some of the initially protected primary information. This may involve decrypting a specific portion of the encrypted second primary information (ESP) or, depending on the established trust level and the nature of the requested information, sharing additional details that satisfy the first entity's needs. In some embodiments, the transmitted content may contain metadata or additional information that facilitates processing by the first entity, such as timestamps, data format identifiers, or indications of which portions of the transmitted content are encrypted. Using metadata can help the first entity correctly interpret and dispose of the received data.

[0109] In some embodiments, the second entity may initiate subsequent communication by sending a second communication request, either simultaneously with or after sending encrypted second primary information (ESP) and second supplementary information (SS) to the first entity. The second communication request can be used to continue information exchange and ensure bidirectional interaction, thereby allowing the second entity to query relevant data from the first entity. For example, the second entity may wish to obtain updated information about conditions that may affect its operation, such as new environmental data, changes in nearby traffic patterns, or recent road accidents detected by the first entity. The second communication request can also be used to synchronize data between entities, such as updating operating parameters or sharing diagnostic information to help identify potential mechanical problems that may be encountered by either entity. In this way, the second communication request supports dynamic, continuous information exchange, rather than one-way broadcasting.

[0110] A second entity may decide to send a follow-up communication request because it needs to confirm that it has received specific data or verify that information sent to the first entity has been processed correctly. For example, if the second entity shares critical data that requires a coordinated response (such as control instructions in complex traffic conditions or area hazard warnings), it may seek confirmation from the first entity to ensure mutual understanding and effective coordination. This confirmation may be requested as part of the second communication request so that the first entity acknowledges that it has received and understood the information sent.

[0111] Upon receiving a second communication request, the first entity may perform similar steps to those taken by the second entity in response to the initial communication request. Specifically, the first entity may determine the level of trust associated with the second entity by considering factors such as the context of the communication request, any authentication credentials provided, and the history of interactions between entities or with other entities associated with the same owner. Based on the assessed level of trust, the first entity may decide which information needs to be protected as primary information (e.g., primary key information), which may require encryption before transmission. This process ensures that sensitive or proprietary data is adequately protected while allowing non-sensitive information to be shared more freely, thereby facilitating ongoing exchange.

[0112] Then, the first entity can use the Quandle-based cryptographic framework described herein to encrypt the first primary information (fp) associated with it using the first public encryption key (e1) linked to the first entity. Similar to the encryption process performed by the second entity, the first entity can use an encoded variable (y) to add an additional layer of security during the encryption of the first primary information (fp). The encoded variable (y) can be a parameter used to modify the first primary information (fp) during the encryption operation, making it more resistant to unauthorized access. Encryption can be performed using binary operations that satisfy the Quandle axiom. This process is executed to obtain the encrypted first primary message (efp), where (efp) = fp y, and fp y= Here, the first public encryption key (e1) can be used as part of the encryption operation, ensuring that only an authorized entity with the corresponding private key can decrypt the information. The encoded variable (y) can be a constant, a randomly generated number, or derived from the encryption scheme itself, which increases the complexity of the encryption and enhances the security of the encrypted data.

[0113] After the first primary information (fp) is encrypted, the first entity can transmit the encrypted first primary information (efp) and first supplementary information (fs) to the second entity. This transmission may occur in response to a second communication request received from the second entity, thus forming a two-way information exchange. The encrypted first primary information (efp) ensures that sensitive or proprietary data related to the first entity is protected, enabling the second entity to securely receive the information. The first supplementary information (fs) may contain data related to the second entity's request, such as the first entity's current state, recent observations, or other non-sensitive details that do not require encryption.

[0114] Upon receiving a response from the first entity, the second entity can examine the provided first supplementary information (fs) and determine if additional details, which may be part of the encrypted first primary information (esp), are required. If the first supplementary information (fs) does not meet the second entity's requirements, or if more specific data is needed, the second entity can initiate subsequent communication requesting access to certain portions of the primary information previously encrypted by the first entity. In response to the subsequent communication request, the first entity may reassess the trust level associated with the second entity, considering factors such as the context of the request, any authentication credentials provided, and the history of past interactions. Based on this reassessment, the first entity can decide whether to grant access to the requested encrypted information.

[0115] In some embodiments, a second entity may establish an initial communication link with a first entity in response to a first communication request. This initial communication link serves as a preliminary secure connection, allowing entities to exchange data while minimizing the overhead associated with establishing the connection. For example, the second entity may use this initial communication link to send an encrypted second primary message (ESP) and a second supplementary message (SS) in response to the first communication request. If the first entity subsequently initiates a follow-up request for additional details regarding the second primary message, that request and any subsequent responses can also be communicated via the initial link. Similarly, the first entity may use this initial communication link to send an encrypted first primary message (EFP) and a first supplementary message (FS) in response to a second communication request. If the second entity subsequently initiates a follow-up request for additional details regarding the first primary message, that request and any further responses can also be communicated via the initial link.

[0116] Initial communication links can utilize short encryption keys, with key lengths less than or equal to 1024 bits, to protect data transmission, thus achieving a balance between security and efficiency in the early stages of communication. Shorter key lengths help accelerate key exchange and encryption processes, reduce latency, and enable parties to quickly establish a secure communication channel. While shorter keys may not provide the highest level of cryptographic security, they are sufficient to meet the data protection needs of initial authentication and the early stages of communication.

[0117] Once the initial encrypted exchange is successfully completed, the communication link can transition to a more secure state, such as a sustained communication link, where a longer encryption key is used to enhance the security of ongoing data exchange. This transition may involve using a longer encryption key than that used in the initial communication link to establish a more secure and longer-term channel for continuous interaction. In specific embodiments, the key length of the long key can be equal to or greater than 2048 bits. Depending on system requirements and the nature of inter-entity communication, the transition from an initial communication link using a short encryption key to a sustained communication link using a longer encryption key can be triggered by various factors. For example, the transition can occur automatically after the successful transmission of the initial encrypted data, such as from an encrypted second primary message (ESP) and a second supplementary message (SS) from a second entity, or from an encrypted first primary message (EFP) and a first supplementary message (FS) from a first entity. Once both parties confirm receipt of data and that there are no communication errors or inconsistencies, they can switch to a sustained communication link to enhance the security of future exchanges. Alternatively or additionally, entities may transition to a persistent communication link if the initial communication establishes a level of mutual trust between them based on factors such as valid authentication credentials, verified digital certificates, or successful integrity checks of transmitted data. This transition can occur once both parties agree that the initial authentication and encryption parameters meet the security requirements for continued communication. Alternatively or additionally, the transition may also be triggered after a preset period of time has elapsed since the initial communication link was kept active. For example, if no security events or errors occur within a certain number of seconds or minutes of the initial communication link being maintained, the parties may switch to a longer encryption key for subsequent communication. The length of the time-based threshold can be configured according to the desired balance between communication efficiency and security. Alternatively or additionally, the transition to a persistent communication link may be based on the number of data exchanges that have occurred on the initial communication link. For example, after a certain number of successfully transmitted encrypted data between entities, the system may determine that switching to a more secure communication link is appropriate. Alternatively or additionally, in some cases, the nature of the communication may change, prompting a transition to a persistent communication link. For example, if entities begin discussing higher-priority or more sensitive information (e.g., emergency coordination, critical system diagnostics, or proprietary data), they may upgrade to longer encryption keys to provide additional security for ongoing data exchanges. Alternatively or additionally, the transition may also occur in response to changes in the entity's operating environment or network conditions. For instance, if entities detect an increased risk of eavesdropping or cyberattacks, they may automatically switch to persistent communication links to enhance security.Similarly, if one of the entities moves to a higher-risk area (e.g., a crowded public place with many potential cyber threats), the system may initiate a conversion to a longer encryption key to enhance protection.

[0118] Persistent communication links can establish a higher level of security and be used for all future communication between entities, as long as these entities are in a close proximity area. If entities move out of the close proximity area and then return to the same area, they can directly switch to a persistent communication link without re-establishing the initial communication link. Since the initial communication link has already been established and verified, entities can more efficiently resume secure communication by leveraging previously authenticated and encrypted parameters. In some embodiments, entities can store session-specific data, such as cryptographic keys, authentication tokens, or communication history, to facilitate rapid re-establishment of persistent communication links. This stored data can be used to verify that the entity is indeed the same entity that communicated previously, thereby allowing for simplified recovery of secure communication without the overhead of re-initiating the entire authentication process. Alternatively, entities can implement time-based or event-based mechanisms to determine how long session-specific data remains valid for directly re-establishing persistent communication links. For example, if an entity goes out of range and then returns within a predefined time period, the persistent communication link can be restored using existing cryptographic parameters. If a longer period has elapsed, the entity can perform a partial re-authentication process or refresh the encryption key while still skipping the initial communication link establishment process to expedite the reconnection process. If an entity's operating environment or configuration undergoes significant changes, a lightweight verification process can be performed to confirm that security requirements are still met. For example, if an entity has experienced a configuration update or a change in its trust level, additional checks can be triggered before restoring persistent communication links to ensure that the restored connection complies with the updated security policy while maintaining the efficiency of re-establishing secure communication.

[0119] The following scenario illustrates how different types of entities can establish initial communication links in a dynamic network environment and then transition to a persistent, more secure connection.

[0120] When autonomous vehicles enter a new area (such as a smart city or industrial zone), they can connect to a dynamic network. Initially, each vehicle can establish an initial communication link with a nearby roadside unit (e.g., RSU 120) using a short encryption key to exchange preliminary information, such as traffic updates or road conditions. Once the vehicle receives confirmation that the connection is stable and all authentication checks have passed, it can switch to a longer encryption key for ongoing communication. The sustained link can support secure data exchange for real-time updates to navigation information, hazard warnings, or cooperative driving maneuvers with other vehicles, such as lane changes or platooning.

[0121] Drones operating within temporary networks at emergency response sites can establish initial communication links using short encryption keys, quickly connecting to network infrastructure such as command units or other drones. For example, when drones are deployed for search and rescue operations, they can use the initial link to quickly authenticate themselves to a nearby central management unit (e.g., Central Management Unit 130), thereby sharing real-time aerial footage and sensor data. As operations progress, drones can transition to persistent communication links using longer encryption keys to protect sensitive data related to search patterns, victim locations, or drone flight paths.

[0122] A central management unit (e.g., central management unit 130), such as one deployed in a smart city network or emergency command center, can act as a coordinator for establishing and managing communication links. When a new entity (e.g., an autonomous vehicle or drone) is detected nearby, the central management unit can initiate the process of establishing an initial communication link using a short encryption key. After initial authentication and data exchange (e.g., sending network access credentials or providing network condition updates), the central management unit can trigger a transition to a longer encryption key for more secure, continuous communication. This allows the central management unit to securely and coordinately exchange information between multiple entities while maintaining the confidentiality of sensitive data (e.g., traffic management protocols or emergency response strategies).

[0123] RSUs (such as RSU 120) located on highways or at intersections can facilitate connections between passing vehicles or drones and dynamic networks. For example, an RSU can detect an approaching autonomous vehicle and establish an initial communication link using a short encryption key to quickly transmit data. The vehicle and RSU can exchange initial data, such as traffic light status, speed limits, or road hazards. Once the vehicle is authenticated and communication is stable, the RSU can prompt a switch to a longer encryption key to securely transmit more detailed data, such as vehicle trajectory or real-time environmental sensor information.

[0124] In industrial or infrastructure zones, various autonomous machines (such as excavators, drones, or delivery vehicles) can connect to a temporary network managed by a central control unit. Upon arrival at the work area, each machine can establish an initial communication link using a short encryption key for rapid authentication with the network infrastructure. As the machines begin to perform tasks collaboratively (such as synchronized lifting or material handling), the system automatically switches to a longer encryption key to ensure continuous and secure data exchange. This ensures that data related to machine operation, task coordination, or safety protocols is always protected throughout the operation.

[0125] In a rescue environment, entities such as vehicles, drones, and mobile command units can connect to temporary communication networks established within the deployment area. Each entity can initially establish a communication link with the central management unit or other entities using a short encryption key, enabling rapid authentication and integration into the network. After initial data exchange (such as situation updates or mission instructions) is completed, communication can transition to a persistent link using a longer encryption key to provide secure and resilient data protection throughout the operation.

[0126] In emergency response scenarios such as firefighting operations, drones and vehicles can establish initial communication links with temporary command units deployed on-site. The initial link uses a short encryption key, enabling parties to quickly share critical data, such as real-time video feeds, environmental conditions, or responder locations. As the response progresses and the need for more detailed data exchange increases, the command unit can coordinate a switch to longer encryption keys to ensure secure, continuous communication, thereby protecting the confidentiality of sensitive information such as rescue strategies or hazardous material detection.

[0127] It is important to note that the terms "short key" and "long key" used herein are relative and will evolve with advancements in encryption standards and computing power. In this disclosure, a short key may refer to a key length that balances security and efficiency in the initial communication link. Similarly, a long key may refer to a key length that ensures enhanced security in persistent communication links. However, as technology advances and computing power increases, the definitions of short and long keys may change to accommodate higher security levels. For example, as encryption requirements become increasingly stringent, a key currently considered a long key may become a short key in future implementations. Therefore, the specific key lengths used in this disclosure are intended to be illustrative and not restrictive, and the lengths of long and short keys may change depending on future developments in encryption technologies and security standards.

[0128] Example method for inter-entity connection transformation Figure 5 An example method 500 for inter-entity connection transformation according to an embodiment of the present invention is illustrated. As shown in block 502, a first entity may continuously monitor the presence of one or more entities within its immediate vicinity. The first entity may monitor the presence of entities using various techniques, including proximity sensing, signal strength analysis, network discovery protocols, or direct wireless communication. In some embodiments, the first entity may establish a connection radius, which represents the effective range of its communication modules (e.g., wireless transceivers or proximity sensors). The connection radius may be static or dynamically adjusted based on factors such as environmental conditions, network density, or the specific communication protocol used.

[0129] Furthermore, the monitoring process may include periodic scanning or continuous evaluation to track entities entering or leaving the immediate vicinity of the first entity. In some cases, the monitoring process may include verification measures, such as checking digital certificates or comparing network credentials, to ensure that detected entities comply with authorization criteria. In alternative embodiments, the first entity may adjust its monitoring frequency based on operational needs, such as increasing the scanning interval during active communication or decreasing the frequency under stable network conditions.

[0130] As shown in block 504, the first entity can detect that the second entity is no longer within the immediate vicinity of the second entity. This detection can be based on signal strength reduction, loss of a unique network identifier, or other proximity sensing methods. For example, if the second entity moves out of the connection radius of the first entity, the monitoring system can record the departure of the second entity. In some embodiments, the absence of the second entity can be detected by periodic scanning or continuous monitoring, enabling the first entity to promptly identify changes in the network composition. Optionally, the detection process can include confirmation protocols, such as repeated signal loss checks or timeout mechanisms, to verify the departure of the second entity before terminating active communication. In some configurations, the first entity can establish a threshold for the duration or degree of signal attenuation and then conclude that the second entity has left the vicinity.

[0131] As shown in block 506, a first entity can terminate established communication with a second entity. Termination may include closing the active communication channel and ceasing any data exchange between the two entities. In some embodiments, the first entity may send a termination signal to formally close the communication, ensuring that both entities are aware that the interaction has ended. This process helps conserve network resources by promptly disconnecting inactive or distant entities. Alternatively, the termination of communication may be automatic, i.e., the first entity stops communicating after a pre-configured timeout following signal loss. In another embodiment, the first entity may log the disconnection event or update its internal network mapping to reflect the departure of the second entity, thereby ensuring accurate recording of nearby entities and active connections.

[0132] As shown in block 508, the first entity can detect the presence of a third entity in its immediate vicinity based on monitoring. As described herein, this detection can be performed using various methods, such as proximity sensing, network discovery protocols, or signal signature analysis. The first entity can identify the third entity by recognizing a unique network identifier, signal strength, or other predefined marker indicating a nearby device, in a manner similar to or the same as how the first entity detects the presence of a second entity (e.g., ...). Figure 4 (As described in the text).

[0133] As shown in block 510, the first entity may send a third communication request to the third entity to establish communication with the third entity. This request may serve as an initial handshake, signaling that the first entity intends to initiate a secure data exchange with the third entity. The third communication request may contain relevant information that facilitates the establishment of a secure connection, in a manner similar to or the same as that in which the first entity sends the first communication request to the second entity (e.g., ...). Figure 4 (As described in the text).

[0134] The overall topology of inter-entity connections may depend on each entity's relative position within the network. For example, in an autonomous vehicle fleet, each vehicle can establish direct communication links with its immediate neighbors (typically those directly in front and behind). This proximity-based connection structure allows each vehicle to maintain a minimal set of connections, thereby reducing network load and optimizing resource utilization within the fleet. This linear topology supports efficient data flow and coordination between closely spaced vehicles.

[0135] In a dynamic setup, where a subset of entities may leave the convoy (e.g., at an overpass or intersection), the network topology can be adjusted accordingly. Entities remaining in the convoy can retain their established links, ensuring uninterrupted operation of the overall structure. Meanwhile, entities leaving the convoy can form new network segments or connect with other neighboring entities, enabling seamless reconfiguration of communication links based on real-time location changes. This highly adaptable framework supports self-organizing network configurations, allowing the topology to change dynamically based on entity location and movement patterns. Therefore, the system supports multiple connection topologies, including linear, star, or mesh configurations, to adapt to the spatial arrangement and operating environment of related entities.

[0136] Those skilled in the art to which these embodiments belong, benefiting from the teachings set forth in the foregoing specification and related drawings, should be able to conceive of various modifications and other embodiments of the disclosure set forth herein. Although the drawings illustrate only certain components of the methods and systems described herein, it should be understood that various other components may also be present in the disclosure herein. Furthermore, the methods described above may contain fewer steps in some cases, while in others they may include additional steps. In some cases, the steps of the methods described above, and modifications to the steps, may be performed in any order and in any combination.

[0137] Therefore, it should be understood that this disclosure is not limited to the specific embodiments disclosed, and modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terminology is used herein, it is for general and descriptive purposes only and not for limitation.

Claims

1. A system for a Quandle-based secure cryptography system in a dynamic network environment, the system comprising: First entity; as well as Second entity; The first entity is configured as follows: Detect the presence of the second entity in the immediate vicinity of the first entity; and In response, a first communication request to establish communication with the second entity is transmitted to the second entity; and The second entity is configured as follows: In response to the first communication request, using a Quandle-based cryptographic framework, the second key information sp associated with the second entity is encrypted using the second public key e2; and The encrypted second primary information esp and the second supplementary information ss associated with the second entity are transmitted to the first entity.

2. The system as claimed in claim 1, wherein, The second public key e2 is associated with the second entity.

3. The system as described in claim 1, wherein, The second entity is one of the entities in a second group associated with the second owner, and the second public key e2 is associated with the second group of entities.

4. The system as claimed in claim 1, wherein, The second entity is also configured as follows: After transmitting the encrypted second primary information esp and second supplementary information ss, a second communication request is transmitted to the first entity.

5. The system as described in claim 4, wherein, The first entity is also configured as follows: Using the aforementioned Quandle-based cryptographic framework, first key information fp associated with the first entity is encrypted using the first public key e1, wherein the first public key e1 is associated with the first entity; and In response to the second communication request, encrypted first primary information efp and first supplementary information fs associated with the second entity are transmitted to the first entity.

6. The system of claim 5, wherein, The first entity is one of a first group of entities associated with the first owner, and the first public key e1 is associated with the first group of entities.

7. The system as claimed in claim 1, wherein, The second entity is also configured as follows: The encrypted second primary information esp is generated based on the second primary information sp, the encoded variable y, and the second public key e2, wherein... esp = sp y ,in, It is a binary operation that satisfies the Quandle axiom, where, ,in, It is shaped like The composite number, and among them, and It is a prime number.

8. The system of claim 7, wherein, sp y = ,in, ,in, Let be the Euler totient function, and where .

9. The system as claimed in claim 1, wherein, The second entity is also configured as follows: An initial communication link is established with the first entity, and the transmission of the encrypted second primary information esp includes using the initial communication link.

10. The system of claim 9, wherein, The second public key e2 is a short encryption key with a length of less than or equal to 1024 bits.

11. The system of claim 10, wherein, The second entity is configured as follows: After successfully transmitting the encrypted second primary information esp and second supplementary information ss to the first entity, the communication link is switched from the initial communication link to a persistent communication link, wherein the switch also includes converting the second public key e2 from the short encryption key to a long encryption key with a length greater than or equal to 2048 bits.

12. The system of claim 1, wherein, The second primary information sp includes operational information associated with the second entity, wherein the operational information includes at least one of internal system information, monetizable operational information, control commands, or security protocols and procedures.

13. The system of claim 1, wherein, The second supplementary information ss includes status information associated with the second entity, wherein the status information includes at least one of location information, functional status, or captured sensor information.

14. The system of claim 1, wherein, The first entity is also configured as follows: Continuously monitor the presence of one or more entities in the immediate vicinity of the first entity; The detection indicates that the second entity is no longer located within the immediate vicinity of the second entity; as well as Terminate the communication established with the second entity.

15. The system of claim 14, wherein, The first entity is also configured as follows: The presence of a third entity in the immediate vicinity of the first entity is detected based on the monitoring; and A third communication request to establish communication with the third entity is transmitted to the third entity.

16. A method for a Quandle-based secure cipher in a dynamic network environment, the method comprising: Receive a first communication request from the first entity to establish communication with the second entity; In response to the first communication request, the second entity uses a Quandle-based cryptographic framework to encrypt the second primary information sp associated with the second entity using the second public key e2; as well as The second entity transmits the encrypted second primary information esp and the second supplementary information ss associated with the second entity to the first entity. The first communication request is received in response to detecting the presence of the second entity in the immediate vicinity of the first entity.

17. The method of claim 16, wherein, The second public key e2 is associated with the second entity.

18. The method of claim 16, wherein, The second entity is one of the entities in a second group associated with the second owner, and the second public key e2 is associated with the second group of entities.

19. The method of claim 16, wherein, The method further includes: The encrypted second primary information esp is generated based on the second primary information sp, the encoded variable y, and the second public key e2, wherein... esp = SPI y ,in, It is a binary operation that satisfies the Quandle axiom, where, ,in It is shaped like The composite number, and among them, and It is a prime number.

20. The method of claim 19, wherein, sp y = ,in, ,in, Let be the Euler totient function, and where .

21. The method of claim 16, wherein, The method further includes: An initial communication link is established with the first entity, and the transmission of the encrypted second primary information esp includes using the initial communication link.

22. The method of claim 21, wherein, The second public key e2 is a short encryption key with a length of less than or equal to 1024 bits.

23. The method of claim 22, wherein, The method further includes: After successfully transmitting the encrypted second primary information esp and second supplementary information ss to the first entity, the communication link is switched from the initial communication link to a persistent communication link, wherein the switch also includes converting the second public key e2 from the short encryption key to a long encryption key with a length greater than or equal to 2048 bits.

24. The method of claim 16, wherein, The second primary information sp includes operational information associated with the second entity, wherein the operational information includes at least one of internal system information, monetizable operational information, control commands, or security protocols and procedures.

25. The method of claim 16, wherein, The second supplementary information ss includes status information associated with the second entity, wherein the status information includes at least one of location information, functional status, or captured sensor information.

Images