Computing device, copy engine and method thereof, computer program product and medium

Abstract

The implementation includes a method for generating Cyclic Redundancy Check (CRC) in a secure network, executed by a replication engine of a computing device. The method includes: replicating a first dataset received from an interface bus to obtain a first dataset copy; replicating a second dataset received from the interface bus to obtain a second dataset copy; generating a first CRC value for the first dataset copy in the hardware of the replication engine via a first streaming CRC engine; and in parallel, generating a second CRC value for the second dataset copy in the hardware of the replication engine via a second streaming CRC engine; and sending a first streaming CRC message including the first dataset copy and the first CRC value, and a second streaming CRC message including the second dataset copy and the second CRC value, to a processor of the computing device.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to U.S. non-provisional application 17 / 929,764, filed September 6, 2022, the entire contents of which are incorporated herein by reference. Background Technology

[0003] A communication network enables network devices to be coupled to each other according to various communication standards. In order to transmit data between other devices within a communication network, network devices must be configured, or configurable, to communicate according to the communication protocols used by the other devices. For example, network devices attempting to establish a communication link between Bluetooth-enabled devices and another communication link between Wi-Fi-enabled devices involve establishing the link and transmitting data according to both Bluetooth and Wi-Fi standard protocols. Part of the communication link and data transmission process includes performing Cyclic Redundancy Check (CRC) to verify the data payload, ensure data security, and prevent errors. Network devices attempting to transmit data between network devices implementing various communication protocols need to perform CRC as defined by each communication protocol. Summary of the Invention

[0004] The aspects include a method for generating Cyclic Redundancy Check (CRC) in a secure network, performed by a replication engine of a computing device. These aspects may include replicating a first dataset received from an interface bus in the hardware of the replication engine to obtain a first dataset copy; replicating a second dataset received from the interface bus in the hardware of the replication engine to obtain a second dataset copy; generating a first CRC value for the first dataset copy in the hardware of the replication engine via a first streaming CRC engine; generating a second CRC value for the second dataset copy in parallel in the hardware of the replication engine via a second streaming CRC engine; sending a first streaming CRC message including the first dataset copy and the first CRC value to a processor of the computing device; and sending a second streaming CRC message including the second dataset copy and the second CRC value to a processor.

[0005] Some aspects may also include generating a first source ring descriptor based on a first communication message, which includes a first source data pointer indicating the memory location of a first dataset, and generating a second source ring descriptor based on a second communication message, which includes a second source data pointer indicating the memory location of a second dataset.

[0006] In some implementations, replicating a first dataset received from an interface bus in the hardware of the replication engine to obtain a copy of the first dataset may further include replicating the first dataset based on a first source data pointer, and replicating a second dataset received from an interface bus in the hardware of the replication engine to obtain a copy of the second dataset may further include replicating the second dataset based on a second source data pointer.

[0007] In some implementations, the first source ring descriptor may include a first length bit indicating the length of the first dataset, a first aggregation bit indicating that the first CRC value is generated as part of a first dataset stream including multiple datasets, and a first CRC type indicating the first communication protocol, and the second source ring descriptor may include a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream including multiple datasets, and a second CRC type indicating the second communication protocol.

[0008] In some implementations, generating a first CRC value for a first dataset copy via a first streaming CRC engine may further include generating a first CRC value for a first dataset copy via a first streaming CRC engine based on a first CRC type indicating a first communication protocol, and generating a second CRC value for a second dataset copy via a second streaming CRC engine may further include generating a second CRC value for a second dataset copy via a second streaming CRC engine based on a second CRC type indicating a second communication protocol.

[0009] In some implementations, the first CRC type and the second CRC type can be different CRC types.

[0010] Some aspects may also include generating a first state ring descriptor including a first CRC value and a first state bit, generating a second state ring descriptor including a second CRC value and a second state bit, setting the first state bit after generating the first CRC value, wherein sending a first streaming CRC message is performed in response to setting the first state bit, and setting the second state bit after generating the second CRC value, wherein sending a second streaming CRC message is performed in response to setting the second state bit.

[0011] Some aspects may also include generating a first destination ring descriptor including a first destination data pointer, and generating a second destination ring descriptor including a second destination data pointer, wherein sending the first streaming CRC message may further include sending the first streaming CRC message based on the first destination data pointer, and wherein sending the second streaming CRC message may further include sending the second streaming CRC message based on the second destination data pointer.

[0012] Some aspects may also include replicating a third dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the third dataset, wherein a first CRC value of the first dataset copy is generated in the hardware of the replication engine via a first streaming CRC engine and a second CRC value of the second dataset copy is generated in parallel in the hardware of the replication engine via a second streaming CRC engine. This may also include generating a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third dataset copy and the first CRC value, and wherein sending a first streaming CRC message to the processor may further include sending a first streaming CRC message to the processor that includes the first dataset copy, the third dataset copy, and the final CRC value.

[0013] Another aspect may include a computing device having a replication engine configured to perform operations of any of the methods outlined above. Another aspect may include a computing device having components capable of performing any of the methods outlined above. Attached Figure Description

[0014] The accompanying drawings, which are incorporated herein and form part of this specification, illustrate exemplary embodiments and, together with the general description given above and the detailed description given below, serve to explain the features of the various embodiments.

[0015] Figure 1A This is a component block diagram illustrating a secure network 150 suitable for implementing various implementation schemes and supporting systems.

[0016] Figure 1B This is a diagram illustrating an example software architecture that includes a radio protocol stack suitable for implementing wireless communication schemes, encompassing the user plane and control plane.

[0017] Figure 1C This is a system block diagram illustrating an example decomposed base station architecture according to various implementation schemes, which can be part of a 5G network suitable for implementing a hardware-based dynamic CRC generator.

[0018] Figure 2 This is a component block diagram illustrating an example computing and wireless modem system applicable to various implementation schemes.

[0019] Figure 3 This is a component block diagram illustrating an example system 300 configured to establish secure device-to-device communication between a security subsystem and network devices, according to some implementation schemes.

[0020] Figure 4 It is a block diagram of a replication engine, including a streaming CRC engine, based on various implementation schemes.

[0021] Figure 5 It is a block diagram of a replication engine, including software-based ring descriptors, based on various implementation schemes.

[0022] Figure 6 This is a block diagram of a streaming CRC engine implemented within a channel of the replication engine according to various implementation schemes.

[0023] Figure 7 This is a block diagram of a regular packet-based CRC message transmitted across the bus.

[0024] Figure 8 It is a block diagram of streaming CRC messages transmitted across the bus according to various implementation schemes.

[0025] Figure 9 It is a block diagram of example dataset streams based on various implementation schemes.

[0026] Figure 10A This is a flowchart illustrating the process of generating CRC in a secure network according to various implementation schemes.

[0027] Figures 10B to 10E This is a process flowchart of operations 1000b-1000e that can be performed as part of a method for generating CRC in a secure network, according to some implementation schemes.

[0028] Figure 11 This is a component block diagram applicable to network computing device 1100 (such as a security subsystem) used with various implementation schemes. Detailed Implementation

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

[0030] Various implementation schemes include hardware components and methods implemented in such hardware components for generating one or more cyclic redundancy checks (CRCs) in parallel in a network such as an automotive network supporting various safety-related subsystems.

[0031] Many different vehicle subsystems have safety-related functions, such as sensor systems, braking systems, and information displays. Many of these subsystems need to exchange data and commands with many other vehicle subsystems. For safety reasons, safety-related systems need to exchange data across networks and data buses in a secure and reliable manner. One method to ensure that data exchanged between devices is accurately transmitted involves including CRC information in message packets. This allows the receiving device to verify the accuracy of the packet data and correct any errors that may have been introduced during transmission. Complicating the secure exchange of data and commands between multiple vehicle subsystems is that many subsystems and devices connected to the vehicle network use different network protocols. Furthermore, some subsystems and devices may exchange data via wireless communication links, including Bluetooth, Bluetooth Low Energy (BLE), and Wi-Fi, which use different protocols than those used by devices transmitting data via the vehicle's wired network. Different communication protocols can involve different CRC methods. Therefore, the various components and subsystems communicating on the vehicle network, especially the safety-related subsystems exchanging data on the vehicle network (referred to as "safety subsystems"), may need to adapt to a variety of different methods for generating and using CRC information.

[0032] Various implementations include hardware solutions and methods for supporting streaming CRC generation of datasets communicated via various protocols. These implementations allow for the parallel (e.g., within the same time window) generation and / or computation of CRC values ​​for multiple datasets by implementing multiple streaming CRC engines in the hardware of the replication engine, which can be implemented in a security subsystem. Each streaming CRC engine can be assigned a channel and can handle multiple datasets of different CRC types within a dataset stream (i.e., a stack). The packet overhead for each dataset can be stored and updated in software as source, state, and destination ring descriptors, thereby reducing the time spent generating CRCs within the hardware-based streaming CRC engine. While particularly useful for vehicle systems, these implementations are also useful in any network of components and subsystems that use more than one communication protocol to communicate data and commands.

[0033] The term "computing device" as used herein refers to any or all of the following: router devices (wired or wireless), electrical appliances (wired or wireless), cellular phones, smartphones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, handheld computers, wireless email receivers, internet-enabled multimedia cellular phones, medical devices and equipment, biosensors / devices, wearable devices (including smartwatches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings, smart bracelets)), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), wireless network-enabled Internet of Things (IoT) devices (including smart meters / sensors, industrial manufacturing equipment, large and small machines and appliances for home or business use), wireless communication elements within autonomous and semi-autonomous vehicles, wireless devices attached to or incorporated into various mobile platforms, GPS devices, and similar electronic devices including memory and programmable processors. Computing devices that include wireless communication components and are configured to communicate with other computing devices via wireless communication links (e.g., cellular phones, smartphones, etc.) are referred to herein as "wireless computing devices."

[0034] The term "System-on-a-Chip" (SoC) is used herein to refer to a single integrated circuit (IC) chip containing multiple resources and / or processors integrated on a single substrate. A single SoC may contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SoC may also include any number of general-purpose and / or specialized processors (digital signal processors, modem processors, video processors, etc.), blocks of memory (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, regulators, oscillators, etc.). An SoC may also include software for controlling the integrated resources and processors, as well as software for controlling peripheral devices.

[0035] The term "System-in-Package" (SiP) is used herein to refer to a single module or package containing multiple resources, computing units, cores and / or processors on two or more IC chips, a substrate, or a System-on-a-Chip (SoC). For example, a SiP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SiP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SiP may also include multiple independent SoCs coupled together and packaged adjacently (e.g., on a single motherboard or in a single computing device) via high-speed communication circuitry. The proximity of the SoCs facilitates high-speed communication and the sharing of memory and resources.

[0036] Network devices implementing various communication protocols can handle Cyclic Redundancy Check (CRC) and generate CRC values ​​for error correction and data security purposes as defined by each communication protocol. Different communication protocols generate CRC values ​​in different ways, and therefore two components or subsystems using different communication protocols may generate / use different CRC values. For example, devices, networks, and subsystems (such as Advanced Driver Assistance Systems (ADAS) – i.e., safety subsystems) may communicate wirelessly with multiple network devices (such as multimedia distribution devices, entertainment displays, wireless mobile devices, wireless charging stations, tire pressure monitoring systems, keyless entry devices, and any other devices capable of communicating with ADAS within a secure network), some of which may use different CRC methods in data exchange on the same network.

[0037] The replication engine is a module within the security subsystem network that handles data transmission between various network devices for all types of communication protocols, including Ethernet, Controller Area Network (CAN), serial transmission, Secure Digital (SD) transmission, Double Data Rate (DDR) transmission, and WiFi. The recommended data integrity check process for generating CRC values ​​varies depending on the protocol.

[0038] In automotive safety networks and subsystems, recommended CRC processing steps can vary based on standards implemented by devices and subsystems of safety subsystems (i.e., ADAS) communicatively coupled within the safety network. Therefore, safety subsystems can process and generate CRC according to various standards defined by the Automotive Open Systems Architecture (AUTOSAR).

[0039] AUTOSAR is a development partnership with automotive stakeholders aimed at creating and establishing open and standardized software architectures for automotive electronic control units (ECUs). AUTOSAR strives to encompass scalability across different vehicle and platform variants, software portability, usability, safety requirements, and maintainability throughout the product lifecycle. AUTOSAR recommends that ADAS adhere to various communication standards, including but not limited to Automotive Hardware Functional Safety (FuSa) features (e.g., ISO 26262), any International Telegraph and Telephone Consultative Committee (CCITT), algorithms for serial streams (e.g., WAN, radio communication protocols, Secure Digital, DigRF), modem standards, Ethernet standards, Bluetooth and Bluetooth Low Energy (BLE) standards, and AUTOSAR CRC standards and recommended protocols, such as the AUTOSAR Secure Polynomial CRC32P4 using the 0xF4ACFB13 polynomial, the SAE J1850 CRC8 using the 0x1D polynomial for diagnostics and digital sharing applications in vehicles, and the 8-bit 0x2FCRC for open secure communication protocols.

[0040] While the AUTOSAR specification recommends CRC for functional safety across all protocols and defines new methods for CRC protocols for security-related protocols, various other standards may recommend different protocols. Therefore, dynamic compliance with all protocols recommended by AUTOSAR and other various standards is a challenge because each standard may have different requirements for generating and verifying CRC when transmitting data payloads between interconnected devices and subsystems. Traditional block-based CRC processing is performed sequentially according to each standard and can require up to 50% CRC overhead of the total bit length of each associated data stack. Therefore, verifying CRC values ​​according to conventional block-based methods can be computationally costly and time-consuming for each variant of the communication protocol.

[0041] Various implementations minimize the hardware-executed processing for generating CRC values ​​by offloading the CRC overhead to data structures such as software-based ring descriptors. These implementations can generate and update source ring descriptors, state ring descriptors, and destination ring descriptors for each dataset used for transmission between network devices. In addition to other CRC overhead fields or bits associated with the payload or dataset, the ring descriptor may also include metadata that can be used to identify the source, destination, updated CRC value, and CRC type. Various implementations can further generate CRCs in parallel by implementing multiple hardware-based streaming CRC engines in separate channels, where each streaming CRC engine can process dataset streams including multiple datasets with the same or different CRC types. The CRC type can be an indicator of the communication protocol by which the dataset is transmitted to and / or from the security subsystem.

[0042] Various implementations include a computing device used in a secure network, the computing device comprising: an interface bus through which communications including datasets are transmitted; and a replication engine coupled to the interface bus. The replication engine may include a replication engine buffer in hardware configured to store datasets as copies of the datasets, and a first streaming CRC engine and a second streaming CRC engine. The replication engine may be configured to copy a first dataset received from the interface bus to the replication engine buffer as a first dataset copy, and to copy a second dataset received from the interface bus to the replication engine buffer as a second dataset copy. The replication engine may also be configured to generate a first CRC value for the first dataset copy using the first streaming CRC engine and a second CRC value for the second dataset copy using the second streaming CRC engine. The replication engine may then send a first streaming CRC message including the first dataset copy and the first CRC value, and a second streaming CRC message including the second dataset copy and the second CRC value, to the processor of the computing device via the interface bus.

[0043] In some implementations, the replication engine may also be configured to use a second streaming CRC engine to generate a second CRC value for a second dataset copy in parallel with generating a first CRC value using a first streaming CRC engine.

[0044] In some embodiments, the replication engine may further include a memory mapping subsystem configured to generate a first source ring descriptor based on a first communication message, the first source ring descriptor including a first source data pointer indicating the memory location of a first dataset. The memory mapping subsystem may also be configured to generate a second source ring descriptor based on a second communication message, the second source ring descriptor including a second source data pointer indicating the memory location of a second dataset. In some embodiments, the replication engine may also be configured to copy the first dataset to a replication engine buffer based on the first source data pointer, and to copy the second dataset to the replication engine buffer based on the second source data pointer.

[0045] In some implementations, the replication engine may also be configured such that the first source ring descriptor includes a first length bit indicating the length of the first dataset, a first aggregation bit indicating that the first CRC value is generated as part of a first dataset stream comprising multiple datasets, and a first CRC type indicating the first communication protocol. The replication engine may also be configured such that the second source ring descriptor includes a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream comprising multiple datasets, and a second CRC type indicating the second communication protocol.

[0046] In some implementations, the replication engine may also be configured to generate a first CRC value for a first dataset copy using a first streaming CRC engine based on a first CRC type indicating a first communication protocol, and to generate a second CRC value for a second dataset copy using a second streaming CRC engine based on a second CRC type indicating a second communication protocol, wherein the first CRC type and the second CRC type are different CRC types.

[0047] In some implementations, the memory-mapped subsystem can be configured to generate a first state ring descriptor including a first CRC value and a first state bit, generate a second state ring descriptor including a second CRC value and a second state bit, set a first state bit in response to a first streaming CRC engine generating a first CRC value, and set a second state bit in response to a second streaming CRC engine generating a second CRC value. The replication engine can be configured to send a first streaming CRC message via the interface bus in response to the memory-mapped subsystem setting the first state bit, and to send a second streaming CRC message via the interface bus in response to the memory-mapped subsystem setting the second state bit.

[0048] In some implementations, the memory-mapped subsystem may also be configured to generate a first destination ring descriptor including a first destination data pointer and a second destination ring descriptor including a second destination data pointer. The replication engine may be configured to send a first streaming CRC message via the interface bus based on the first destination data pointer and a second streaming CRC message via the interface bus based on the second destination data pointer.

[0049] In some implementations, the replication engine may also be configured to copy a third dataset received from the interface bus to a replication engine buffer as a copy of the third dataset, use a first streaming CRC engine to generate a final CRC value using the copy of the third dataset and a first CRC value (i.e., the first dataset and the third dataset are part of the same data stream), and send a first streaming CRC message including the copy of the first dataset, the copy of the third dataset, and the final CRC value to the processor via the interface bus.

[0050] In various implementations, multiple channels of traffic in a network (e.g., a secure network) can be handled with different CRC types based on recommendations for different communication protocols (i.e., how CRC is generated or otherwise calculated within the hardware circuitry). These implementations address the organization, throughput, and processing issues associated with implementing all communication protocols recommended by AUTOSAR. As a result of (i) multi-channel parallel CRC generation, (ii) hardware-based streaming CRC generation for data streams comprising multiple datasets, and (iii) offloading the CRC overhead from hardware to software in the form of a ring descriptor data structure, the performance and efficiency of the security subsystem are improved. More specifically, the subsystem and secure network performance are improved due to the following characteristics: CRC is calculated or otherwise generated in hardware; CRC is calculated or otherwise generated in a streaming manner rather than a packet-based manner and is updated in a state ring descriptor stored in a memory-mapped subsystem (e.g., firmware, DDR); CRC overhead is not added to the data payload or data buffer (i.e., but is stored separately as a software-based ring descriptor); the calculated CRC is handled by software (i.e., the generated CRC value is updated within the software-based state ring descriptor); CRC checksum verification is performed in software as data is consumed by the application; multiple channels handle different types of communication protocols and each data stream can include a different CRC type; and processor interrupts are minimized (i.e., fewer interrupts) when instructions are replaced by ring descriptors stored in a batch stack. In other words, data transfer can be initiated for multiple channels supporting different types of protocols by programming the source and destination ring descriptors of each channel in software; data transfer completion can be marked again in batches for a ring descriptor stack populated by hardware state ring descriptors; and CRC verification of the batched data transfer streams programmed in the source descriptor is handled by software. This reduces processor intervention and the need for frequent attention to each data transfer per channel.

[0051] Figure 1A This is a component block diagram illustrating a secure network 150 suitable for implementing various implementation schemes and supporting systems. (Reference) Figure 1A Vehicle 152a may include a safety subsystem 180, which may include various circuits and devices for controlling the operation of vehicle 152a and communicating with other vehicles with similar equipment, such as vehicle 152b. Figure 1A In the example illustrated, the safety subsystem 180 includes a radio module 185, a processor 182, a memory 181, an input module 183, an output module 184, and a replication engine 190. The safety subsystem 180 may be coupled to and configured to control a drive control component 186, a navigation component 187, one or more sensor components 188, a telematics component 191, and an infotainment component 193 of the vehicle 152a.

[0052] Base station 110 can communicate with core network 140 over wired or wireless communication link 126. Wireless communication link 126 can use various wired networks (e.g., Ethernet, TV cable, telephone, fiber optic, and other forms of physical network connections) that can use one or more wired communication protocols (such as Ethernet, point-to-point protocol, High-level Data Link Control (HDLC), Advanced Data Communication Control Protocol (ADCCP), and Transmission Control Protocol / Internet Protocol (TCP / IP)).

[0053] Wireless computing device 120 and vehicles 152a and 152b can communicate with base station 110 on wireless communication link 122. Wireless communication links 122 and 124 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. Wireless communication links 122 and 124 may utilize one or more radio access technologies (RATs). Examples of RATs that can be used in wireless communication links include: 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Microwave Access Global Interoperability (WiMAX), Time Division Multiple Access (TDMA), and other mobile phone communication technology cellular RATs. Other examples of RATs that can be used in one or more of the various wireless communication links within communication system 100 include mid-range protocols (such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire) and relatively short-range RATs (such as ZigBee, Bluetooth, and Bluetooth Low Energy (BLE)). In some implementations, wireless communication links 122 and 124 may include direct connection communication links that can be established on the PC5 interface according to applicable 3GPP standards.

[0054] The security subsystem 180 may include a processor 182 configured with processor-executable instructions to control the maneuvering, navigation, and / or other operations of the vehicle 152a, including operations in various embodiments. The processor 182 may be coupled to the memory 166, the replication engine 190, and the radio module 185, for example, via an interconnect or bus (e.g., an Advanced Scalable Interface (AXI)). The device 182 may include one or more processing units. In some embodiments, the processor 182 may be a network-on-a-chip (NoC), a switch, or a trusted integrated circuit (TIC) of a device communicatively coupled to or connected to various supporting networks within the security network 150 (i.e., via the radio module 185). In addition to firmware, the replication engine 190 may also include multiple hardware-based streaming CRC engines, such as a memory-mapped subsystem for storing software-based ring descriptors to offload CRC packet overhead from hardware.

[0055] Radio module 185 can be configured for wireless communication, including operation in various implementation schemes. Radio module 185 can exchange wireless signals with base station 110 via wireless communication link 122 and with control units in other vehicles 152b via wireless communication link 124. In some implementations, radio module 185 can also enable vehicle 152a to communicate with wireless communication device 120d (e.g., a cellular phone) via a two-way wireless communication link 178 (such as a WiFi or Bluetooth wireless data link). Similarly, radio module 185 can enable processor 182 to send and receive information from various network devices 189 within the security network 150 via wireless communication link 178. Network devices 189 can be any device communicatively coupled to radio module 185 within the security network 150, such as wireless charging stations, key cards or devices for keyless entry, infotainment systems, cellular devices, tire pressure measurement systems, and satellite-based navigation systems (e.g., Global Positioning System (GPS)). The examples of network devices 189 that communicate with radio module 185 provided are limited for the sake of simplicity and are not intended to be exhaustive. In various embodiments, the controlled network devices may also include smart plugs and smart switches, smart security systems, smart health devices and health monitors, smart appliances, smart meters, smart toys, smart environmental monitors and environmental control systems, various Internet of Things devices, and any other suitable devices capable of communicating with radio module 185.

[0056] In various implementations, wireless communication links 122, 124, and 178 can implement any of the various known wireless communication protocols and standards, such as consumer electronics radio frequency (RF4 CE), controller local area network (CAN), remote protocols such as 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, CDMA, WCDMA, WiMAX, TDMA, any other mobile phone communication technology cellular RAT, medium-range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, relatively short-range RATs such as ZigBee, Bluetooth, BLE, DigRF, any other communication based on the Institute of Electrical and Electronics Engineers (IEEE) 802 standard (e.g., IEEE 802.3), infrared (IR) communication protocols such as RECS-80, RC-5, RC-6, NEC / Renesas protocol, or any other suitable IR communication protocol. In some implementations, various network devices 189 may be directly connected to the security subsystem 180 via a wired connection that implements one or more communication protocols, such as Ethernet, RS-232, RS-485, Universal Asynchronous Receiver Transmitter (UART), Universal Synchronous / Asynchronous Receiver / Transmitter (USART), Universal Serial Bus (USB), High Definition Multimedia Interface (HDMI), or any other suitable wired communication protocol.

[0057] Safety subsystem 180 may be an advanced driver assistance system (ADAS), and wireless communication links 122, 124, and 178, in conjunction with safety subsystem 180 (e.g., processor 182, radio module 185, and replication engine 190, etc.), may further implement safety and / or standardized protocols as defined by AUTOSAR, including but not limited to automotive hardware functional safety (FuSa) features (e.g., ISO 26262), any International Telegraph and Telephone Consultative Committee (CCITT), algorithms for serial streams (e.g., wide area network (WAN), radio communication protocols, secure digital, digital radio frequency (DigRF), etc.), AUTOSAR CRC standards and recommended protocols, such as AUTOSAR secure polynomial CRC32P4 using 0xF4ACFB13 polynomial, SAE J1850 CRC8 using 0x1D polynomial for diagnostic and data sharing applications in vehicles, and 8-bit 0x2FCRC for open secure communication protocols.

[0058] The input module 183 can receive sensor data from one or more sensor components 188 and electronic signals from other components, including the drive control component 186 and the navigation component 187. The output module 184 can be used to communicate with or activate various components of the vehicle 152a, including the drive control component 186, the navigation component 187, and the sensors 188.

[0059] The safety subsystem 180 can receive and send analog and / or digital sensor data to the sensor assembly 188, and can be configured to communicate with the sensor assembly 188 in one-way and / or two-way directions. The safety subsystem 180, in conjunction with the sensor assembly 188, can communicate with network devices (e.g., wireless computing device 120, network device 189) configured to relay sensor information. The safety subsystem 180, in conjunction with the sensor assembly 188, can be configured to implement various features such as wireless charging for electric vehicles (EVs), keyless entry, phone-as-key, automatic parking, tire pressure monitoring, remote sensor control, and autonomous driving features (such as lane and brake checks and alerts).

[0060] The safety subsystem 180 may be coupled to the drive control assembly 186 to control the physical components of the vehicle 152a related to the vehicle's maneuverability and navigation, such as the engine, motor, throttle, steering components, flight control components, braking or deceleration components, etc.

[0061] The safety subsystem 180 may be coupled to the navigation component 187 and may receive data from the navigation component 187 and be configured to use such data to determine the current position and orientation of the vehicle 152a and the appropriate route toward the destination.

[0062] The security subsystem 180 may be coupled to the telematics component 191. The security subsystem 180 may receive and send data to the telematics component 191, and may be configured to, in conjunction with the telematics component 191, send and receive information between a base station (e.g., 110) and other vehicles (e.g., 152b). The security subsystem 180, in conjunction with the infotainment component 193, may be configured to provide various features such as implementation of Car2Car and Car2Infrastructure standards, LTE offloading, media services, over-the-air (OTA) updates, and general internet access.

[0063] The security subsystem 180 may be coupled to the infotainment component 193. The security subsystem 180 may receive and send data to the infotainment component 193, and may be configured to stream data such as video and / or audio media to the display or media output unit of a communicatively connected network device (e.g., wireless computing device 120, network device 189). The security subsystem 180, in conjunction with the infotainment component 193, may be configured to provide various features such as hands-free voice calling, music streaming, multimedia distribution, rear-seat entertainment, display sharing, Apple CarPlay, Android Auto, MirrorLink, and universal internet access.

[0064] Processor 182 and / or navigation component 187 may be configured to communicate with core network 140 (e.g., the Internet) using wireless communication link 122 with cellular data network base station 110. Processor 182 may also be configured to execute various software applications by executing processor-executable instructions in the application layer as described herein.

[0065] Although the security subsystem 180 is described as comprising separate components, in some embodiments, some or all of the components (e.g., processor 182, memory 181, input module 183, output module 184, and radio module 185) may be integrated into a single device or module, such as a system-on-a-chip (SoC) or system-in-package (SiP) processing device, such as a reference Figure 2 The aforementioned SoC or device may be configured for use in a vehicle and configured (such as having processor-executable instructions configured to execute in processor 182) to perform the operations of various embodiments when installed in a vehicle.

[0066] In some implementations, the safety network 150 may include one or more devices configured to communicate as part of an Intelligent Transportation System (ITS). ITS technology improves interoperability and safety between driver-operated vehicles and autonomous vehicles. The Cellular Vehicle-to-Everything (C-V2X) protocol, defined by the 3rd Generation Partnership Project (3GPP), supports ITS technology and serves as the basis for direct communication between vehicles and surrounding communication devices. C-V2X defines transmission modes that provide non-line-of-sight awareness and a higher level of predictability for enhanced road safety and autonomous driving. Such C-V2X transmission modes may include V2V, V2I, and V2P and may utilize frequencies in the 5.9 GHz spectrum independent of cellular networks. C-V2X transmission modes may also include vehicle-to-network (V2N) communication in mobile broadband systems and technologies such as 3G mobile communication technologies (e.g., GSM Evolution (EDGE) systems, CDMA 2000 systems, etc.), 4G communication technologies (e.g., LTE, Advanced LTE, WiMAX, etc.), and 5G systems.

[0067] Figure 1B An example of software architecture 300 is illustrated, which includes user plane and control plane radio protocol stacks for wireless communication between security subsystem 180 (e.g., a controller or SIP 200 of vehicle 152a) and second computing device 350 (e.g., network device 189, wireless computing device 120 in vehicle 152b). In some embodiments, security subsystem 180 and second computing device 350 may communicate via D2D or another suitable device-to-device communication method. Reference Figure 1A and Figure 1B The security subsystem 180 can implement a software architecture 300 to communicate with the computing device 350. In various embodiments, layers in the software architecture 300 of the security subsystem 180 can be logically connected to corresponding software layers of the second computing device 350. The software architecture 300 can be distributed among one or more processors (e.g., processors 212, 214, 216, 218, 252, 260).

[0068] While an example of a single radio protocol stack has been given, in a multi-SIM (Subscriber Identity Module) wireless computing device, software architecture 300 may include multiple protocol stacks, each associated with a different SIM (e.g., in a dual-SIM wireless communication device, the two protocol stacks are associated with two SIMs respectively). Although described below with reference to the LTE communication layer, software architecture 300 may support any of the various standards and protocols used for wireless communication, and / or may include additional protocol stacks that support any of the various standards and protocols used for wireless communication.

[0069] Software architecture 300 may include a Non-Access Stratum (NAS) 302 and an Access Stratum (AS) 304. NAS 302 may include functions and protocols supporting packet filtering, security management, mobility control, session management, and traffic and signaling between a SIM (e.g., SIM 204) of a wireless computing device and its core network 140. AS 304 may include functions and protocols supporting communication between the SIM (e.g., SIM 204) and entities (e.g., base stations) of the supported access network. Specifically, AS 304 may include at least three layers (Layer 1, Layer 2, and Layer 3), each of which may contain various sublayers.

[0070] In the user plane and control plane, Layer 1 (L1) of AS 304 can be Physical Layer (PHY) 306, which oversees the functions implementing transmit and / or receive on the air interface. Examples of such Physical Layer 306 functions may include Cyclic Redundancy Check (CRC) annealing, decoding blocks, scrambling and descrambling, modulation and demodulation, signal measurement, MIMO, etc. The physical layer may include various logical channels, including the Physical Downlink Control Channel (PDCCH) and the Physical Downlink Shared Channel (PDSCH).

[0071] In the user plane and control plane, Layer 2 (L2) of AS 304 can be responsible for the link between the security subsystem 180 and the second computing device 350 at physical layer 306. In various embodiments, Layer 2 may include a Media Access Control (MAC) sublayer 308, a Radio Link Control (RLC) sublayer 310, and a Packet Data Convergence Protocol (PDCP) sublayer 312, each sublayer forming a logical connection terminating at the second computing device 350.

[0072] In the control plane, Layer 3 (L3) of AS 304 may include a Radio Resource Control (RRC) sublayer 3. Although not shown, software architecture 300 may include additional Layer 3 sublayers, as well as various upper layers above Layer 3. In various embodiments, RRC sublayer 313 may provide functions including broadcasting system information, paging, and establishing and releasing RRC signaling connections between security subsystem 180 and second computing device 350. Direct communication messages from the application layer may be transmitted directly on L2 or L3, or via another signaling layer (e.g., PC5 signaling or PC5-S) on L2 or L3.

[0073] In various implementations, PDCP sublayer 312 provides uplink functions including multiplexing between different radio bearers and logical channels, sequence numbering, handover data processing, integrity protection, encryption, and header compression. In the downlink, PDCP sublayer 312 provides functions including in-order delivery of data packets, duplicate data packet detection, integrity verification, decryption, and header decompression.

[0074] In the uplink, RLC sublayer 310 can provide segmentation and concatenation of upper-layer data packets, retransmission of lost data packets, and Automatic Repeat Request (ARQ). In the downlink, RLC sublayer 310 functions may include reordering of data packets to compensate for out-of-order reception, reassembly of upper-layer data packets, and ARQ.

[0075] In the uplink, MAC sublayer 308 provides functions including multiplexing between logical and transport channels, random access procedures, logical channel prioritization, and hybrid ARQ (HARQ) operation. In the downlink, MAC layer functions may include intra-cell channel mapping, demultiplexing, discontinuous reception (DRX), and HARQ operation.

[0076] While the software architecture 300 provides the ability to send data over a physical medium, it may also include at least one host layer 314 to provide data transfer services to various applications within the security subsystem 180. In some embodiments, application-specific functionality provided by the at least one host layer 314 may provide an interface between the software architecture and the general-purpose processor 206.

[0077] In other embodiments, software architecture 300 may include one or more higher logical layers (e.g., transport, session, presentation, application, etc.) that provide host layer functionality. For example, in some embodiments, software architecture 300 may include a network layer (e.g., IP layer) where logical connections terminate at a packet data network (PDN) gateway (PGW). In some embodiments, software architecture 300 may include an application layer where logical connections terminate at another device (e.g., end user equipment, server, etc.). In some embodiments, software architecture 300 may also include a hardware interface 316 in AS 304 between physical layer 306 and communication hardware (e.g., one or more radio frequency transceivers).

[0078] Figure 1C This is a system block diagram illustrating an example decomposed base station 160 architecture that can be part of a 5G network, supporting external communication with networks implementing various implementation schemes and thereby interfaced with a hardware-based dynamic CRC generator. Reference Figures 1A to 1CThe decomposed base station 160 architecture may include one or more central units (CUs) 162, which may communicate directly with the core network 140 via a backhaul link, or indirectly with the core network 140 through one or more decomposed base station units, such as a near real-time (near-RT) RAN Intelligent Controller (RIC) 164 via an E2 link, or a non-real-time (non-RT) RIC 168 associated with a Service Management and Orchestration (SMO) framework 166, or both. CUs 162 may communicate with one or more distributed units (DUs) 170 via corresponding midhaul links (such as F1 interfaces). DUs 170 may communicate with one or more radio units (RUs) 172 via corresponding fronthaul links. RUs 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, user equipment (UEs) (such as an automated vehicle control system (ADS) 104) may be served simultaneously by multiple RUs 172.

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

[0080] In some aspects, the CU 162 can host one or more higher-level control functions. Such control functions may include Radio Resource Control (RRC), Packet Data Convergence Protocol (PDCP), Service Data Adaptation Protocol (SDAP), etc. Each control function can be implemented using an interface configured to signal to other control functions hosted by the CU 162. The CU 162 can be configured to handle user plane functionality (i.e., Central Unit-User Plane (CU-UP)), control plane functionality (i.e., Central Unit-Control Plane (CU-CP)), or a combination thereof. In some specific implementations, the CU 162 can be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, CU-UP units can communicate bidirectionally with CU-CP units via an interface (such as an E1 interface). The CU 162 can be implemented to communicate with the DU 170 for network control and signaling as needed.

[0081] DU 170 may correspond to a logical unit comprising one or more base station functions for controlling the operation of one or more RU 172s. In some aspects, DU 170 may, at least in part, host one or more of the Radio Link Control (RLC) layer, the Media Access Control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) depending on functional splits (such as those defined by the 3rd Generation Partnership Project (3GPP). In some aspects, DU 170 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by DU 170 or with control functions hosted by CU162.

[0082] Lower-layer functionality can be implemented by one or more RU 172s. In some deployments, an RU172 controlled by a DU 170 may correspond to a logical node that hosts RF processing functions or low-PHY layer functions (such as performing Fast Fourier Transform (FFT), Inverse FFT (iFFT), digital beamforming, Physical Random Access Channel (PRACH) extraction and filtering, or both, based at least in part on functional partitioning (such as lower-layer functional partitioning). In such architectures, the RU 172 may be implemented to handle over-the-air (OTA) communications with one or more UE 120s. In some specific implementations, the real-time and non-real-time aspects of control and user plane communications with the RU 172 may be controlled by the corresponding DU 170. In some scenarios, this configuration allows the DU 170 and CU 162 to be implemented in a cloud-based Radio Access Network (RAN) architecture (such as a vRAN architecture).

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

[0084] The non-RT RIC 168 can be configured to include logical functions enabling non-real-time control and optimization of RAN elements and resources, including artificial intelligence / machine learning (AI / ML) workflows for model training and updates, or policy-based guidance for applications / features in the near-RT RIC 164. The non-RT RIC 168 can be coupled to or communicate with the near-RT RIC 164 (e.g., via an A1 interface). The near-RT RIC 164 can be configured to include logical functions enabling near real-time control and optimization of RAN elements and resources via data collection and action through an interface (e.g., via an E2 interface) that connects one or more CU 162s, one or more DU 170s, or both, and O-eNBs to the near-RT RIC 164.

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

[0086] Various implementation schemes can be implemented on several single-processor and multi-processor computer systems, including system-on-chip (SoC) or system-in-package (SiP) systems. Figure 2 This is a component block diagram illustrating an example computing and wireless modem system 200 suitable for implementing any of the various implementation schemes. Various implementation schemes can be implemented on several single-processor and multi-processor computer systems (including SoCs or SiPs).

[0087] refer to Figures 1A to 2 The illustrated example wireless device 200 (which may be a system-in-package in some embodiments) includes two SoCs 202 and 204 coupled to a clock 206, a voltage regulator 208, at least one subscriber identity module (SIM) 268 and / or SIM interface, and a wireless transceiver 266. The wireless transceiver is configured to transmit and receive wireless communications via an antenna (not shown) to and from network wireless devices such as base station 110, wireless computing device 120, vehicle 152b, and network device 189. In some embodiments, the first SoC 202 operates as the central processing unit (CPU) of the wireless device, executing instructions by performing arithmetic, logic, control, and input / output (I / O) operations specified by instructions from a software application. In some embodiments, the second SoC 204 may operate as a dedicated processing unit. For example, the second SoC 204 can operate as a dedicated 5G processing unit, responsible for managing high-capacity, high-speed (e.g., 5Gbps) and / or ultra-high frequency short-wavelength (e.g., 28GHz millimeter wave spectrum) communications.

[0088] The first SoC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor (AP) 216, one or more coprocessors 218 (e.g., vector coprocessors) connected to one or more of these processors, memory 220, custom circuitry 222, system components and resources 224, interconnect / bus modules 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SoC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple millimeter-wave transceivers 256, memory 258, and various additional processors 260 (such as application processors, packet processors, etc.).

[0089] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independently of the other processors / cores. For example, the first SoC 202 may include a processor running a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor running a second type of operating system (e.g., MICROSOFT WINDOWS 10). Furthermore, any one or all of processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (e.g., synchronous processor cluster architecture, asynchronous or heterogeneous processor cluster architecture, etc.).

[0090] The first SoC 202 and the second SoC 204 may include various system components, resources, and custom circuitry for managing sensor data, analog-to-digital conversion, wireless data transmission, and performing other specialized operations such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 224 of the first SoC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components to support processors and software clients running on wireless devices. The system components and resources 224 and / or custom circuitry 222 may also include circuitry for interfacing with peripheral devices such as cameras, electronic displays, wireless communication devices, external memory chips, etc.

[0091] The first SoC 202 and the second SoC 204 can communicate via interconnect / bus module 250. Various processors 210, 212, 214, 216, and 218 can be interconnected via interconnect / bus module 226 to one or more memory elements 220, system components and resources 224, custom circuitry 222, and a thermal management unit 232. Similarly, processor 252 can be interconnected via interconnect / bus module 264 to a power management unit 254, a millimeter-wave transceiver 256, memory 258, and various additional processors 260. Interconnect / bus modules 226, 250, and 264 may include arrays of reconfigurable logic gates and / or implement bus architectures (e.g., CoreConnect, AMBA, etc.). Communication can be provided by advanced interconnects, such as high-performance on-chip networks (NoC).

[0092] The first SoC 202 and / or the second SoC 204 may also include input / output modules (not illustrated) for communicating with external SoC resources such as clock 206, voltage regulator 208, one or more wireless transceivers 266, and at least one SIM 268 and / or SIM interface (i.e., an interface for accepting one or more SIM cards)). External SoC resources (e.g., clock 206, voltage regulator 208) may be shared by two or more internal SoC processors / cores. At least one SIM 268 (or one or more SIM cards coupled to one or more SIM interfaces) may store information supporting multiple subscriptions (including a first 5G NR subscription and a second 5G NR subscription, etc.).

[0093] In addition to the example system-in-package 200 discussed above, various implementations can be implemented in a wide variety of computing systems, including a single processor, multiple processors, multi-core processors containing two or more independent processing cores (e.g., central processing unit (CPU) cores, Internet Protocol (IP) cores, graphics processing unit (GPU) cores, etc.), or any combination thereof.

[0094] Figure 3 This is a component block diagram illustrating an example system 300 configured to establish secure device-to-device communication between a security subsystem and network devices, according to some implementation schemes. Reference Figures 1A to 3System 300 may include a security subsystem 180, one or more network devices 404 (e.g., vehicle 152b, wireless computing device 120, network device 189, second computing device 350), and external resources 418 (e.g., database, web server), which can communicate via wireless communication network 424. External resources 418 may include information sources outside of system 300, external entities participating with system 300, or other resources. In some embodiments, some or all of the functionality attributed herein to external resource 418 may be provided by resources included in system 300. System 300 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to processor 422.

[0095] The security subsystem 180 may include an electronic memory 420, which may be configured to store information related to the functionality implemented by the dataset copying module 430, the CRC generation module 432, the ring descriptor generator module 434, the ring descriptor update module 436, the memory mapping module 438, the CRC type identification module 440, the CRC type enabling module 442, the send / receive module 444, and any other instruction modules.

[0096] Electronic storage device 420 may include a non-transitory storage medium that electronically stores information. Electronic storage device 420 may include one or both of system storage that is integrated with system 200 (i.e., inherently non-removable) and removable storage that is removably connected to system 200 via, for example, a port (e.g., a Universal Serial Bus (USB) port, a FireWire port, etc.) or a drive (e.g., a disk drive, etc.). In various embodiments, electronic storage 420 may include one or more of charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash memory drives, etc.), optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard disk drives, floppy disk drives, etc.) and / or other electronically readable storage media. Electronic storage device 420 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). Electronic storage device 420 may store software algorithms, information determined by processor 422, and / or other information that enables system 200 to operate in the manner described herein.

[0097] Security subsystem 180 may be configured by machine-readable instructions 406. Machine-readable instructions 406 may include one or more instruction modules. Instruction modules may include computer program modules. Instruction modules may include one or more of the following: dataset copying module 430, CRC generation module 432, ring descriptor generator module 434, ring descriptor update module 436, memory mapping module 438, CRC type identification module 440, CRC type enabling module 442, send / receive module 444, and other instruction modules (not illustrated). Security subsystem 180 may include a processor 422 configured to implement machine-readable instructions 406 and corresponding modules.

[0098] Processor 422 may include one of a plurality of local processors that can be configured to provide information processing capabilities in system 200. Thus, processor 422 may include one or more of the following: digital processor, analog processor, digital circuitry designed to process information, analog circuitry designed to process information, state machine, and / or other mechanisms for electronically processing information. Although processor 422 is... Figure 3 The processor 422 is illustrated as a single entity, but this is for illustrative purposes only. In some embodiments, the processor 422 may include multiple processing units. These processing units may be physically located within the same device, or the processor 422 may represent the processing functionality of multiple devices distributed throughout the system 200.

[0099] In some embodiments, the processor 422 of the dataset replication module 430 may be configured to replicate a first dataset received from the interface bus in the hardware of the replication engine to obtain a first dataset copy. In some embodiments, the processor 422 of the dataset replication module 430 may be configured to replicate a second dataset received from the interface bus in the hardware of the replication engine to obtain a second dataset copy. In some embodiments, the processor 422 of the dataset replication module 430 may be configured to replicate the first dataset in the hardware of the replication engine based on a first source data pointer. In some embodiments, the processor 422 of the dataset replication module 430 may be configured to replicate the second dataset based on a second source data pointer. In some embodiments, the processor 422 of the dataset replication module 430 may be configured to replicate a third dataset received from the interface bus in the hardware of the replication engine to obtain a third dataset copy.

[0100] In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate a first CRC value for a first dataset copy via a first streaming CRC engine in the hardware of the replication engine, and in parallel generate a second CRC value for a second dataset copy via a second streaming CRC engine in the hardware of the replication engine. In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate the first CRC value for the first dataset copy via the first streaming CRC engine based on a first CRC type indicating a first communication protocol. In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate the second CRC value for the second dataset copy via a second streaming CRC engine based on a second CRC type indicating a second communication protocol. In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using a third dataset copy and the first CRC value.

[0101] In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a first source ring descriptor based on a first communication message, the first source ring descriptor including a first source data pointer indicating the memory location of a first dataset. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a second source ring descriptor based on a second communication message, the second source ring descriptor including a second source data pointer indicating the memory location of a second dataset. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a first state ring descriptor including a first CRC value and a first status bit. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a second state ring descriptor including a second CRC value and a second status bit. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a first destination ring descriptor including a first destination data pointer. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a second destination ring descriptor including a second destination data pointer.

[0102] In some embodiments, the processor 422 of the ring descriptor update module 436 may be configured to update the source ring descriptor, the state ring descriptor, and the destination ring descriptor, including updating the length bit, the aggregation bit, the source data pointer, the CRC value, and the destination data pointer. In some embodiments, the processor 422 of the ring descriptor update module 436 may be configured to set a first state bit after generating a first CRC value, wherein sending a first streaming CRC message is performed in response to setting the first state bit. In some embodiments, the processor 422 of the ring descriptor update module 436 may be configured to set a second state bit after generating a second CRC value, wherein sending a second streaming CRC message is performed in response to setting the second state bit.

[0103] In some implementations, the processor 422 executing the memory mapping module 438 may be configured to allocate a range of memory locations and addresses using external memory or a memory subsystem embedded in the copy engine (e.g., firmware, DDR) for storing data structures such as ring descriptors and associated data including metadata.

[0104] In some implementations, the processor 422 executing the CRC type identification module 440 may be configured to identify a CRC type associated with a CRC algorithm defined by a communication standard or protocol, wherein the CRC type is identifiable in metadata received from a network device outside the replication engine as part of the communication.

[0105] In some implementations, the processor 422 executing the CRC type enable module 442 may be configured to enable and control the hardware circuitry within the streaming CRC engine of the replication engine to generate CRC values ​​for the dataset based on the CRC type associated with the dataset.

[0106] In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a first streaming CRC message to the processor of the computing device, including a first dataset copy and a first CRC value. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a second streaming CRC message to the processor, including a second dataset copy and a second CRC value. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send the first streaming CRC message based on a first destination data pointer. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send the second streaming CRC message based on a second destination data pointer. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a first streaming CRC message to the processor, including a first dataset copy, a third dataset copy, and a final CRC value.

[0107] Processor 422 may execute modules 430-444 and / or other modules via software, hardware, firmware, or some combination of software, hardware and / or firmware and / or other mechanisms for configuring the processing capabilities on processor 422.

[0108] The description of the functionality provided by the different modules 430-444 is for illustrative purposes and is not intended to be limiting, as any module of 430-444 may provide more or less functionality than described. For example, one or more modules of 430-444 may be eliminated, and some or all of their functionality may be provided by other modules of 430-444. As another example, processor 422 may execute one or more additional modules that perform some or all of the functionality attributable to one of modules 430-444.

[0109] Figure 4 This is a block diagram of a replication engine, including a streaming CRC engine, based on various implementation schemes. (Reference) Figures 1A to 4 The replication engine 190 may include any number of “N” hardware-based streaming CRC engines 192. For example, the replication engine 190 may include a first streaming CRC engine 192-1, a second streaming CRC engine 192-2, an “N”th streaming CRC engine 192-N, and any number of streaming CRC engines (not illustrated) between the second streaming CRC engine 192-2 and the Nth streaming CRC engine 192-N. The replication engine 190 may be a module in a security subsystem (e.g., 180) that replicates datasets during data transmission (i.e., receiving and sending) for all types of communication protocols, including Ethernet, CAN, serial transmission, SD, DDR, BLE, etc. An interface bus (e.g., Advanced Extensible Interface (AXI), interconnect / bus modules 226, 264) may connect the streaming CRC engines 192 of the replication engine 190 to a processor (e.g., 164) within the security subsystem.

[0110] The replication engine 190 can calculate or otherwise generate CRC in a grouped manner (i.e., conventional CRC calculation), in a streaming manner in parallel channels, and / or according to each CRC standard defined within a communication protocol implemented within a secure network (e.g., 150). Specifically, each of the streaming CRC engines 192 can be associated with a separate channel, where software-based ring descriptors indicate the source, state, and destination of a dataset being processed by the streaming CRC engine 192 for error checking purposes. In other words, after the software generates and stores the source, state, and destination ring descriptors identifying the corresponding dataset, the CRC calculation can be performed by the streaming CRC engine 192 (i.e., in hardware). For example, the replication engine 190 can partition, generate, or otherwise define separate channels for each streaming CRC engine 192 within a memory-mapped region (i.e., within a memory-mapped subsystem (e.g., within the replication engine 190; within the DDR connected to or embedded in the replication engine 190; within the firmware of the replication engine 190)). As shown in the figure, there can be N channels, equal to the number of N streaming CRC engines 192: Channel 1 may include streaming CRC engine 192-1, source ring descriptor 502-1, state ring descriptor 504-1, and destination ring descriptor 506-1; Channel 2 may include streaming CRC engine 192-2, source ring descriptor 502-2, state ring descriptor 504-2, and destination ring descriptor 506-2; Channel N may include streaming CRC engine 192-N, source ring descriptor 502-N, state ring descriptor 504-N, and destination ring descriptor 506-N; and any other channel may include an equivalent ring descriptor. Therefore, each of the ring descriptors 502, 504, and 506 can be a data structure stored in the firmware (i.e., the memory-mapped subsystem) or in the memory-mapped area of ​​the replication engine 190.

[0111] Each channel N can handle multiple CRC types, or various CRC algorithms defined by wireless communication protocols and standards (e.g., AUTOSAR, WiFi, BLE, DigRF, etc.). Implementing individual channels N (each including a hardware-based streaming CRC engine 192) allows for parallel processing and computation of multiple CRC types for various applications. For example, channel 1 can process a dataset stream or stack for CRC checksum verification, where each dataset within the dataset stack can be of the same or different CRC type, while channel 2 is processing a different dataset stack. In some implementations, the order in which the CRC of each dataset within a channel is computed can be based on the order of arrival (i.e., when the streaming CRC engine 192 copies the datasets). In some implementations, the order in which the CRC of each dataset within a channel is computed can be based on priority (e.g., high-priority DMA, low-priority DMA, dynamic priority, fixed priority).

[0112] Figure 5 This is a block diagram of a replication engine, including software-based ring descriptors, based on various implementation schemes. (Reference) Figures 1A to 5 The replication engine 190 can generate a source ring descriptor 502, a state ring descriptor 504, and a destination ring descriptor 506 and store them in the memory-mapped area of ​​the firmware of the replication engine 190.

[0113] Each ring descriptor may be stored in a stack of ring descriptors of the same type according to the order in which the datasets are received (i.e., devices connected to the communication site via radio module 185, such as network device 189, wireless computing device 120, and vehicle 152b)). For example, each dataset may be associated with a source ring descriptor 502, a state ring descriptor 504, and a destination ring descriptor 506.

[0114] The replication engine 190 can generate a source ring descriptor 502, a state ring descriptor 504, and a destination ring descriptor 506 associated with each received dataset based on the metadata included in each dataset. The replication engine 190 can store each ring descriptor of all datasets together in the firmware according to the ring descriptor type. For example, the source ring descriptors 502 (e.g., source ring descriptors [1], [2], [N]) of all datasets (e.g., data [1], [2], [N]) can be stored together in the firmware as a sequential stack, the state ring descriptors 504 (e.g., state ring descriptors [1], [2], [N]) of all datasets can be stored together in the firmware as a separate sequential stack, and the destination ring descriptors 506 (e.g., destination ring descriptors [1], [2], [N]) of all datasets (e.g., data [1], [2], [N]) can be stored together in the firmware as another sequential stack. Thus, as Figure 5 and Figure 6 As illustrated, the source ring descriptors 502-1, 502-2, ..., 502-N in each individual channel (e.g., channels 1, 2, ..., N) can be aggregated and stored as a single stack in the firmware of the replication engine 190; the state ring descriptors 504-1, 504-2, ..., 504-N in each individual channel can be aggregated and stored as a single stack; and the destination ring descriptors 506-1, 506-2, ..., 506-N in each individual channel can be aggregated and stored as a single stack. Each ring descriptor stack can be ordered sequentially according to the order in which the replication engine receives and / or replicates each dataset within the replication engine buffer 194.

[0115] The replication engine 190 may receive or be otherwise notified and requested regarding one or more datasets concerning communications between the security subsystem 180 and any network device within the security network 150. The replication engine 190 may replicate any received dataset within a hardware-based replication engine buffer 194. For example, the replication engine 190 may receive and replicate any number of datasets (e.g., data[1], data[2], ..., data[N]) from one or more devices according to one or more communication protocols, each of which requires various CRC verification processes and algorithms. The datasets received from each network device may include metadata that the replication engine 190 can use to generate various ring descriptors.

[0116] To perform CRC calculations relative to all data received by and sent from the security subsystem 160, the replication engine 190 may communicate the dataset to a memory subsystem (e.g., DDR) within the security subsystem 160. When communicating the dataset to the memory subsystem for the purpose of performing CRC calculations on the dataset, the firmware of the replication engine 190 may generate a source ring descriptor 502. Each generated source ring descriptor 502 may include a length bit (i.e., the length of the dataset), aggregation or clustering bits (i.e., one or more bits indicating that the dataset can be processed in a streaming parallel channel manner for CRC calculations, as opposed to conventional block-based CRC calculations), one or more bits indicating the CRC type (e.g., type 1, type 2, type 3, etc., as defined by a communication protocol standard), and a source data pointer (i.e., a memory index).

[0117] The source data pointer may indicate a memory-mapped address and / or physical and / or virtual location where the corresponding dataset is stored in the memory subsystem. For example, a processor (e.g., 182) communicating with replication engine 190 may receive communications including the dataset from a device (e.g., network device 189) within secure network 150.

[0118] The processor can forward communications to the replication engine 190, and the firmware of the replication engine 190 can generate a source ring descriptor 502, including length bits, aggregation bits, CRC type, and source data pointer, during the process of transferring the dataset to the memory subsystem. For example, the replication engine 190 can receive and replicate a first dataset of communications from a cellular phone via a BLE connection, and can receive a second dataset of communications from a wireless charging station via a WiFi connection.

[0119] The replication engine 190 can generate a first source ring descriptor having a CRC type indicating that the first dataset should be and will be processed according to the BLE CRC processing standard, and can subsequently generate a second source ring descriptor having a CRC type indicating that the second dataset should be processed according to the WiFi CRC processing standard, and can subsequently load the first source ring descriptor and the second source ring descriptor as an ordered stack or otherwise store them in the firmware.

[0120] The replication engine 190 can detect when a source ring descriptor 502 has been generated based on the dataset. After the replication engine 190 detects the presence of a source ring descriptor 502 stored in the firmware with padding length, aggregation, CRC type, and source data pointer bits, the replication engine 190 can locate the corresponding dataset based on each source data pointer and copy the dataset from the memory-mapped area to the replication engine buffer 194. The replication engine 190 can simultaneously generate a destination ring descriptor and a status ring descriptor based on the dataset copy, while performing parallel CRC calculations on the dataset copy via the streaming CRC engine 192. For example, a first dataset and a second dataset can be copied from firmware address locations identified by a first source data pointer and a second data pointer of a first source ring descriptor (e.g., 502-1) and a second source ring descriptor (e.g., 502-2), respectively, thereby generating a first dataset copy and a second dataset copy stored in the replication engine buffer 194.

[0121] The replication engine 190 can generate a first state ring descriptor and a second state ring descriptor (e.g., 504-1, 504-2), as well as a first destination ring descriptor and a second destination ring descriptor (e.g., 506-1, 506-2), based on the first dataset copy and the second dataset copy, respectively. After replicating each dataset to obtain a dataset copy, the replication engine 190 can update the first destination ring descriptor with a length bit and a destination data pointer, and update the second destination ring descriptor with a length bit and a destination data pointer (i.e., a memory index indicating where the CRC to be calculated / generated will be sent). The first state ring descriptor and the second state ring descriptor can be generated to include a length bit and an aggregation bit.

[0122] Once the dataset is copied to replication engine 190, replication engine 190 can perform the following tasks in parallel (i.e., at the same or substantially the same time / within the same time window): (i) perform a first CRC calculation based on the CRC type of the first source ring descriptor via a first streaming CRC engine (e.g., 192-1); (ii) perform a second CRC calculation based on the CRC type of the second source ring descriptor via a second streaming CRC engine (e.g., 192-2).

[0123] After completing the CRC calculation for the first and / or second dataset copies, each of the corresponding state ring descriptors 504 can be updated based on each dataset copy to include the final generated CRC. The first and second state ring descriptors can be updated according to the order in which the CRC calculations performed by the first and second streaming CRC engines are completed. For example, the first streaming CRC engine can complete the CRC calculation for the first dataset copy before the second streaming CRC engine completes the CRC calculation for the second dataset copy. Therefore, the replication engine 190 can update the first state ring descriptor with the generated CRC of the first dataset copy before updating the second state ring descriptor with the generated CRC of the second dataset copy.

[0124] For example, the second streaming CRC engine can perform the CRC calculation on the second dataset copy before the first streaming CRC engine completes the CRC calculation on the first dataset copy (e.g., the first streaming CRC engine may calculate the CRC according to a more stringent and time-consuming standard). Therefore, the replication engine 190 can update the second state ring descriptor with the CRC of the generated second dataset copy before updating the first state ring descriptor with the CRC of the generated first dataset copy.

[0125] Figure 6 This is a block diagram of a streaming CRC engine implemented within a channel of the replication engine, based on various implementation schemes. (Reference) Figures 1A to 6 The streaming CRC engine 192 can be one of any number N streaming CRC engines 192 of the replication engine 190.

[0126] Based on metadata from the source ring descriptor, the streaming CRC engine 192 can calculate or otherwise generate the CRC of a copy of the dataset. The metadata may include a CRC type, which allows the streaming CRC engine 192 to calculate the copy of the dataset according to the CRC type (i.e., the CRC protocol defined by the communication standard type).

[0127] A copy of the dataset can be provided (i.e., via “Data stream_in”) to CRC circuit 604 (hardware component, not illustrated) based on metadata, thereby enabling or otherwise activating the hardware to process the dataset copy. For example, the metadata may indicate CRC type 2 (e.g., BLE CRC protocol), and CRC circuit 604 for CRC type 2 may be enabled via the “enable2” signal.

[0128] A copy of the dataset can be streamed to CRC circuit 604 for CRC type 2 calculation. After processing, the CRC data can be output to CRC_out and multiplexed (and / or reflected, if necessary, according to the AUTOSAR standard for CRC) to obtain the final CRC of the dataset copy. The final CRC can then be updated in the corresponding state ring descriptor 504.

[0129] In some implementations, the streaming CRC engine 192 can process more than one dataset copy before obtaining the final CRC. For example, a first streaming CRC engine can process sequences with more than one dataset copy. This process of analyzing the CRC of more than one dataset copy in a row before obtaining the final CRC can also be performed in parallel with a second streaming CRC engine that processes different sequences with more than one dataset copy separately (i.e., as referenced). Figure 7 The above).

[0130] A group of two or more dataset copies may be referred to as a dataset stream, wherein each dataset copy within the dataset stream has a CRC calculated or generated sequentially and, depending on the CRC type, is fed into a CRC circuit until the last dataset copy of the dataset stream is processed and the final CRC is calculated or otherwise generated. Therefore, the streaming CRC engine 192 may calculate or otherwise generate the final CRC of several dataset copies, which may be of the same CRC type or different CRC types.

[0131] A CRC is calculated for each dataset, and a streaming CRC is calculated for multiple datasets linked to multiple source ring descriptors within the dataset stream. The end of the dataset stream (i.e., the last dataset within the dataset stream) can be indicated by an aggregate bit not set in the source ring descriptor associated with that dataset stream. A state descriptor and a CRC can be updated for multiple datasets forming a single dataset stream. In contrast, if the communication protocol is a packet-based protocol, a CRC is generated for each dataset, the aggregate bit is not set, and a one-to-one mapping from the source ring descriptor to the state ring descriptor with each generated CRC is produced.

[0132] For example, each dataset copy within a dataset stream can be fed into CRC circuit 604 according to the CRC type and length defined by metadata for each source ring descriptor used for each dataset copy in the dataset stream. For example, the dataset stream may include a first dataset copy and a second dataset copy, each of which can be identified by a first source ring descriptor and a second ring descriptor, respectively. The first source ring descriptor may indicate that the first dataset copy has a 56-bit length, CRC type 3 (e.g., WiFi), and an aggregation bit (i.e., indicating that the dataset copy is part of the dataset stream), and the second ring descriptor may indicate that the second dataset copy has a 16-bit length, CRC type 2 (e.g., BLE), and an aggregation bit. Therefore, metadata in the firmware of replication engine 190 can enable CRC type 3 in CRC circuit 604 of streaming CRC engine 192; and the first dataset copy can be processed to determine the CRC. Since the first dataset copy is part of the dataset stream indicated by the aggregation bit, the first calculated or generated CRC value is multiplexed back into CRC circuit 604 via a "feedback CRC" connection. The metadata in the firmware of the replication engine 190 can then enable CRC type 2 of the CRC circuit 604 of the streaming CRC engine 192; and the second dataset copy can be processed to determine the CRC and a feedback CRC value calculated from the CRC of the first dataset copy. This process can be repeated until the last dataset copy of the dataset stream has a calculated or generated CRC, based on which the final CRC is determined.

[0133] Figure 7 This is a block diagram illustrating a standard block CRC message 700 for a 4KB data payload transmitted across the bus. Assuming a 32-bit CRC overhead per packet, the block CRC message 700 can include a total of bits according to the following formula: 4096 bits [data] + (64 packets × 32 bits CRC per packet) = 4096 + 2048 = 150% of the payload. Therefore, if the CRC is handled in hardware, the standard block CRC message 700 can include 100% payload data plus a 50% overhead due to the added block CRC.

[0134] Figure 8 This is a block diagram illustrating a streaming CRC message 800 carrying a 4KB data payload across the bus, according to various implementation schemes. (Reference) Figures 1A to 8Assuming a 32-bit CRC, a streaming CRC message 800 can include a total number of bits according to the following formula: 4096 bits [data] + 32-bit CRC uploaded in software = 100% payload. Therefore, if the CRC is handled in hardware, the streaming CRC message 800 can include 100% payload data plus a CRC checksum added to the data payload. The integrity of the CRC data can be ensured by offloading the CRC overhead to the source ring descriptor 502, state ring descriptor 504, and destination ring descriptor 506 in the firmware, while providing zero overhead in the payload due to the addition of the CRC. The reduced-overhead streaming CRC message 800 allows for more efficient transmission of the data payload and corresponding CRC value across the interface bus, thereby reducing the computational resources and time required by the receiving processor for unpacking and utilizing the streaming CRC message 800 compared to the block-based CRC message 700.

[0135] Figure 9 This is a block diagram illustrating examples of dataset stream 900 according to various implementation schemes. (Reference) Figures 1A to 9 Dataset Stream 900 exemplifies the ability to support multiple CRC datasets of different CRC types within a single channel. Supported data widths within Dataset Stream 900 can include 64-bit, 56-bit, 48-bit, 40-bit, 32-bit, 24-bit, 16-bit, and 8-bit data widths. Protocols supported by Dataset Stream 900 can include the CRC-8-SAE data sharing protocol for vehicles, the CRC-8-2F open security protocol, the CRC-16CCITT modem / Bluetooth / DigRF protocol, the CRC-32P4 AUTOSAR security protocol, the CRC-32 Ethernet IEEE 802.3 protocol, and any other known CRC protocols.

[0136] Figure 10A This is a process flowchart of an example method 1000a, which can be executed by a processor of a receiving wireless device according to various implementation schemes, for generating a cyclic redundancy check (CRC) in a secure network (e.g., secure network 150). Figures 10B to 10E This is a process flowchart of example operations 1000b-1000e, which can be performed as part of method 1000a for generating CRC in a secure network, according to some implementation schemes. (Reference) Figures 1A to 10EMethod 1000a and operations 1000b-1000e may be executed by a replication engine (e.g., processors 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a computing device (e.g., security subsystem 180, wireless computing device 120, vehicle 152b, network device 189). In some embodiments, the replication engine (e.g., processors 182, 210, 212, 214, 216, 218, 252, 260, 422, auxiliary engine 190) may be configured to perform operations via processor-executable instructions stored in a non-transitory processor-readable medium (e.g., 220, 258, 420). The component used to perform the operation of method 1000a and each of operations 1000b-1000e may be a processor of system 100, 160, 200, 300 and 1100, such as processors 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190 and / or as referenced Figures 1A to 6 and Figures 8 to 10E Similar to the aforementioned.

[0137] In block 1002, the replication engine of the computing device is capable of performing operations including replicating a first dataset received from an interface bus in the hardware of the replication engine to obtain a copy of the first dataset. For example, the replication engine (e.g., replication engine 190) may receive communication including the dataset across an interface bus (e.g., AXI, interconnect / bus modules 226, 264) and may replicate the dataset to a replication engine buffer (e.g., replication engine buffer 194) in the hardware of the replication engine. In some embodiments, replicating the first dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the first dataset may further include replicating the first dataset based on a first source data pointer (i.e., a first source ring descriptor). Components for performing the operations of block 1002 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) that performs the dataset replication module 430.

[0138] In block 1004, the replication engine of the computing device is capable of performing operations including replicating a second dataset received from an interface bus in the hardware of the replication engine to obtain a second dataset copy. For example, the replication engine (e.g., replication engine 190) may receive communication including the dataset across an interface bus (e.g., AXI, interconnect / bus modules 226, 264) and may replicate the dataset to a replication engine buffer (e.g., replication engine buffer 194) in the hardware of the replication engine. In some embodiments, replicating the second dataset received from the interface bus in the hardware of the replication engine to obtain a second dataset copy may further include replicating the second dataset based on a second source data pointer (i.e., a pointer to a second source ring descriptor). Components for performing the operations of block 1004 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) that performs the dataset replication module 430.

[0139] In block 1006, the replication engine of the computing device is capable of performing operations including generating a first CRC value for a first dataset copy via a first streaming CRC engine (e.g., 192-1) in the hardware of the replication engine, and generating a second CRC value for a second dataset copy in parallel via a second streaming CRC engine (e.g., 192-2) in the hardware of the replication engine (e.g., 190). The parallel temporal generation of the first and second CRC values ​​can be performed in separate channels (e.g., channel 1, channel 2), each channel including a set and / or stack of ring descriptors (e.g., 502, 504, 506) and streaming CRC engine 192. Components for performing the operations of block 1006 may include processors (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) that performs the CRC generation module 432.

[0140] In some implementations, the first CRC value generated in block 1006 via the first streaming CRC engine may further include the first CRC value generated via the first streaming CRC engine based on a first CRC type indicating a first communication protocol.

[0141] In some embodiments, the second CRC value generated in block 1006 via the second streaming CRC engine to create a second dataset copy may further include a second CRC value generated via the second streaming CRC engine based on a second CRC type indicating a second communication protocol. In some embodiments, the first CRC type and the second CRC type may be different CRC types or may be the same CRC type.

[0142] In some implementations, generating a first CRC value for a first dataset copy via a first streaming CRC engine in the hardware of the replication engine in block 1006 and generating a second CRC value for a second dataset copy via a second streaming CRC engine in the hardware of the replication engine in parallel may further include generating a final CRC value via the first streaming CRC engine, wherein the final CRC value may be generated using a third dataset copy and the first CRC value.

[0143] In block 1008, the replication engine (e.g., 190) of the computing device is capable of performing operations including sending a first streaming CRC message, including a first dataset copy and a first CRC value, to a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422) of the computing device (e.g., security subsystem 180). In some embodiments, sending the first streaming CRC message may further include sending the first streaming CRC message based on a first destination data pointer (e.g., a first destination ring descriptor 506-1). In some embodiments, sending the first streaming CRC message to the processor may further include sending a first streaming CRC message to the processor including a first dataset copy, a third dataset copy, and a final CRC value. Components for performing the operations of block 1008 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the send / receive module 444.

[0144] In block 1010, the replication engine (e.g., 190) of the computing device is capable of performing operations including sending a second streaming CRC message, which includes a second dataset copy and a second CRC value, to a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422). In some embodiments, sending the second streaming CRC message may further include sending the second streaming CRC message based on a second destination data pointer (e.g., a second destination ring descriptor 506-2). Components for performing the operations of block 1010 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) of the transmit / receive module 444.

[0145] Figure 10B An operation 1000b, which can be performed as part of a method 1000a for generating a CRC in a secure network, is illustrated according to some implementation schemes. Reference Figures 1A to 10BThe replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) is capable of performing operations including generating, in block 1012, a first source ring descriptor (e.g., 502-1) based on a first communication message, including a first source data pointer indicating the memory location of a first dataset. In some embodiments, the first source ring descriptor may include a first length bit indicating the length of the first dataset, a first aggregation bit indicating that a first CRC value is generated as part of a first dataset stream comprising multiple datasets, and a first CRC type indicating a first communication protocol. Components for performing the operations of block 1012 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor generation module 434.

[0146] In block 1014, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) is capable of performing operations including generating a second source ring descriptor (e.g., 502-2) based on a second communication message, which includes a second source data pointer indicating the memory location of a second dataset. In some embodiments, the second source ring descriptor may include a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream comprising multiple datasets, and a second CRC type indicating a second communication protocol. Components for performing the operations of block 1014 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor generation module 434.

[0147] Following the operations in box 1014, the replication engine may perform the operations described in box 1002.

[0148] Figure 10C An example of operation 1000c, which can be performed as part of method 1000a for generating a CRC in a secure network, according to some implementation schemes, is illustrated. Reference Figures 1A to 10C Following the operation in box 1006, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) can perform operations including generating a first state ring descriptor (e.g., 504-1) in box 1016, including a first CRC value and a first state bit. Components for performing the operation in box 1016 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor generation module 434.

[0149] In block 1018, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) is capable of performing operations including generating a second state ring descriptor (e.g., 504-2) that includes a second CRC value and a second state bit. Components for performing the operations of block 1018 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor generation module 434.

[0150] In block 1020, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) is capable of performing operations including setting a first status bit after generating a first CRC value, wherein sending a first streaming CRC message may be performed in response to setting the first status bit. Components for performing the operations of block 1020 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor update module 436.

[0151] In block 1022, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) is capable of performing operations including setting a second status bit after generating a second CRC value, wherein sending a second streaming CRC message is performed in response to setting the second status bit. Components for performing the operations of block 1022 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor update module 436.

[0152] The order of operations described in reference frames 1002-1022 is merely illustrative and not exhaustive. For example, the operations described in reference frames 1016 and 1018 may be performed before, during, or after the operations described in reference frame 1006.

[0153] Following the operations in box 1022, the replication engine can perform the operations described in box 1008.

[0154] Figure 10D An example of operation 1000d, which can be performed as part of method 1000a for generating CRC in a secure network, according to some implementation schemes, is illustrated. Reference Figures 1A to 10DFollowing the operations in box 1004, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) can perform operations including generating a first destination ring descriptor (e.g., 506-1) in box 1024, which includes a first destination data pointer. Components for performing the operations in box 1024 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor generation module 434.

[0155] In block 1026, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) is capable of performing operations including generating a second destination ring descriptor (e.g., 506-2) that includes a second destination data pointer. Components for performing the operations of block 1026 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the ring descriptor generation module 434.

[0156] Following the operations in box 1026, the replication engine may perform the operations described in box 1006.

[0157] Figure 10E An operation 1000e, which can be performed as part of a method 1000a for generating a CRC in a secure network, is illustrated according to some implementation schemes. Reference Figures 1A to 10E Following the operation in box 1004, the replication engine (e.g., 190) of the computing device (e.g., security subsystem 180) can perform operations including copying the third dataset received from the interface bus in the hardware of the replication engine (e.g., replication engine buffer 194) to obtain a copy of the third dataset. Components for performing the operation in box 1028 may include the processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) that performs the dataset replication module 430.

[0158] Following the operations in box 1028, the replication engine can perform the operations described in box 1006.

[0159] Various implementation schemes can be implemented on various network devices, examples of which are shown in Figure 11 The example is 1100, which is used as a network element (such as a base station) in a communication network. Such a network computing device may include at least... Figure 11 The components are shown. Refer to Figure 1 to... Figure 11The network computing device 1100 may typically include a processor 1101 coupled to volatile memory 1102 and mass non-volatile memory such as a disk drive 1103. The network computing device 1100 may also include peripheral memory access devices coupled to the processor 1101, such as floppy disk drives, compact disc (CD) or digital video disc (DVD) drives 1106. The network computing device 1100 may also include a network access port 1104 (or interface) coupled to the processor 1101 for establishing data connections to networks such as the Internet and / or local area networks coupled to other system computers and servers. The network computing device 1100 may include one or more antennas 1107 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless communication link. The network computing device 1100 may include additional access ports for coupling to peripheral devices, external memory, or other devices, such as USB, FireWire, Thunderbolt, etc.

[0160] The processor of the wireless network computing device 1100 can be any programmable microprocessor, microcomputer, or one or more multiprocessor chips that can be configured via software instructions (applications) to perform various functions, including those described in the various embodiments below. In some wireless devices, multiple processors may be provided, such as one processor within SoC 204 dedicated to wireless communication functions and another within SoC 202 dedicated to running other applications. Typically, software applications may be stored in memories 1102, 1103, and then accessed and loaded into the processor. The processor may include sufficient internal memory to store application software instructions.

[0161] Specific implementation examples are described in the following paragraphs. While some of the specific implementation examples below are described in accordance with example methods, further example implementations may include: example methods implemented by a computing device, as discussed in the following paragraphs, the computing device including a processor configured with processor-executable instructions for performing the operations of the methods of the following specific implementation examples; example methods implemented by a computing device, as discussed in the following paragraphs, including components that include functionality for performing the methods of the following specific implementation examples; and example methods discussed in the following paragraphs may be implemented as non-transitory processor-readable storage media storing processor-executable instructions configured to cause the processor of the computing device to perform the operations of the methods of the following specific implementation examples.

[0162] Example 1: A method for generating Cyclic Redundancy Check (CRC) in a secure network, executed by a replication engine of a computing device, the method comprising: replicating a first dataset received from an interface bus in the hardware of the replication engine to obtain a first dataset copy; replicating a second dataset received from the interface bus in the hardware of the replication engine to obtain a second dataset copy; generating a first CRC value of the first dataset copy in the hardware of the replication engine via a first streaming CRC engine, and generating a second CRC value of the second dataset copy in the hardware of the replication engine via a second streaming CRC engine in parallel; sending a first streaming CRC message including the first dataset copy and the first CRC value to a processor of the computing device; and sending a second streaming CRC message including the second dataset copy and the second CRC value to the processor.

[0163] Example 2: According to the method in Example 1, the method further includes: generating a first source ring descriptor based on a first communication message, the first source ring descriptor including a first source data pointer indicating the memory location of the first dataset; and generating a second source ring descriptor based on a second communication message, the second source ring descriptor including a second source data pointer indicating the memory location of the second dataset.

[0164] Example 3: According to the method of Example 1 or 2, copying the first dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the first dataset further includes copying the first dataset based on the first source data pointer, and copying the second dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the second dataset further includes copying the second dataset based on the second source data pointer.

[0165] Example 4: According to any one of Examples 1 to 3, the first source ring descriptor includes a first length bit indicating the length of the first dataset, a first aggregation bit indicating that the first CRC value is generated as part of a first dataset stream including multiple datasets, and a first CRC type indicating a first communication protocol, and the second source ring descriptor includes a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream including multiple datasets, and a second CRC type indicating a second communication protocol.

[0166] Example 5: The method according to any one of Examples 1 to 4, wherein generating the first CRC value of the first dataset copy via the first streaming CRC engine further includes generating the first CRC value of the first dataset copy via the first streaming CRC engine based on a first CRC type indicating a first communication protocol, and generating the second CRC value of the second dataset copy via the second streaming CRC engine further includes generating the second CRC value of the second dataset copy via the second streaming CRC engine based on a second CRC type indicating a second communication protocol.

[0167] Example 6: According to the method described in Example 5, the first CRC type and the second CRC type are different CRC types.

[0168] Example 7: The method according to any one of Examples 1 to 6, the method further includes: generating a first state ring descriptor including the first CRC value and a first state bit; generating a second state ring descriptor including the second CRC value and a second state bit; setting the first state bit after generating the first CRC value, wherein sending the first streaming CRC message is performed in response to setting the first state bit; and setting the second state bit after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second state bit.

[0169] Example 8: The method according to any one of Examples 1 to 7, the method further includes: generating a first destination ring descriptor including a first destination data pointer; and generating a second destination ring descriptor including a second destination data pointer, wherein sending the first streaming CRC message further includes sending the first streaming CRC message based on the first destination data pointer, and wherein sending the second streaming CRC message further includes sending the second streaming CRC message based on the second destination data pointer.

[0170] Example 9: The method according to any one of Examples 1 to 8, the method further comprising: copying a third dataset received from the interface bus in the hardware of the replication engine to obtain a third dataset copy, wherein generating a first CRC value of the first dataset copy in the hardware of the replication engine via a first streaming CRC engine, and generating a second CRC value of the second dataset copy in the hardware of the replication engine via a second streaming CRC engine in parallel further comprising generating a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third dataset copy and the first CRC value, and wherein sending the first streaming CRC message to the processor further comprises sending the processor a first streaming CRC message including the first dataset copy, the third dataset copy and the final CRC value.

[0171] As used herein, the terms “component,” “module,” “system,” etc., are intended to include computer-related entities such as, but not limited to, hardware, firmware, combinations of hardware and software, software, or software being executed, configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, a thread of execution, a program, and / or a computer. By way of example, both an application running on a computing device and the circuitry of a computing device (e.g., a System-on-a-Chip) can be referred to as a component. One or more components may reside within a process and / or a thread of execution, and components may reside on a processor or core and / or be distributed across two or more processors or cores. Furthermore, these components may execute from various non-transitory computer-readable media on which various instructions and / or data structures are stored. Components may communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory read / write, and other known network, computer, processor, and / or process-related communication methods.

[0172] A variety of different cellular and mobile communication services, as well as medium-range and short-range and / or near-field communication standards, are available or conceivable in the future, and all of these services and standards can be implemented and benefit from various implementation schemes. Such services and standards include, for example, the 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) systems, 3rd generation (3G), 4th generation (4G), 5th generation (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) systems (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rate Evolution of GSM (EDGE), Advanced Mobile Phone Systems (AMPS), Digital AMPS (IS-136 / TDMA), Evolved Data Optimization (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Global Interoperability for Microwave Access (WiMAX), Wireless Local Area Networks (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN), Bluetooth, BLE, WiFi, and DigRF. Each of these technologies involves the transmission and reception of, for example, voice, data, signaling, and / or content messages. It should be understood that any references to terms and / or technical details relating to individual telecommunications standards or technologies are for illustrative purposes only and are not intended to limit the scope of the claims to a particular communication system or technology, unless specifically stated in the language of the claims.

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

[0174] The foregoing method descriptions and process flowcharts are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the given order. As those skilled in the art will appreciate, the operations of the foregoing embodiments can be performed in any order. Words such as “afterward,” “then,” “next,” etc., are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. Furthermore, any reference to singular claim elements (e.g., references using the articles “a,” “an,” or “described”) should not be construed as limiting that element to the singular.

[0175] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Those skilled in the art may implement the described functionality in different ways for each specific application, but such implementation decisions should not be construed as causing a departure from the scope of the claims.

[0176] Hardware for implementing the various exemplary logic units, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic units, discrete hardware components, or any combination thereof. While the general-purpose processor may be a microprocessor, in alternative embodiments, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver intelligent objects, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors incorporating a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0177] In one or more embodiments, the described functionality may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or a non-transitory processor-readable storage medium. The operation of the methods or algorithms disclosed herein may be implemented in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and without limitation, such non-transitory computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disc storage devices, magnetic disk storage devices or other magnetic storage intelligent objects, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically magnetically reproduce data, while optical discs optically reproduce data using lasers. The above combinations are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operation of a method or algorithm may reside as one or any combination or set of code and / or instructions on a non-transitory processor-readable and / or computer-readable storage medium, which may be incorporated into a computer program product.

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

Claims

1. A computing device for use in a secure network, the computing device comprising: Interface bus; A replication engine coupled to the interface bus, the replication engine comprising: A replication engine buffer in the hardware of the replication engine, the replication engine buffer being configured to store the dataset as a copy of the dataset; First-generation streaming Cyclic Redundancy Check (CRC) engine; and Second-generation streaming CRC engine, The replication engine is configured as follows: The first dataset received from the interface bus is copied to the replication engine buffer as a copy of the first dataset. The second dataset received from the interface bus is copied to the replication engine buffer as a second dataset copy; In the hardware of the replication engine, a first CRC value for the first dataset replica is generated via a first streaming CRC engine, and in parallel, a second CRC value for the second dataset replica is generated via a second streaming CRC engine in the hardware of the replication engine; and A first streaming CRC message, including a copy of the first dataset and the first CRC value, and a second streaming CRC message, including a copy of the second dataset and the second CRC value, are sent to the processor of the computing device via the interface bus.

2. The computing device of claim 1, wherein the replication engine further comprises: A memory mapping subsystem is configured to: A first source ring descriptor is generated based on a first communication message. The first source ring descriptor includes a first source data pointer that indicates the memory location of the first dataset. as well as A second source ring descriptor is generated based on a second communication message. The second source ring descriptor includes a second source data pointer that indicates the memory location of the second dataset.

3. The computing device of claim 2, wherein the replication engine is further configured to: The first dataset is copied to the replication engine buffer based on the first source data pointer, and The second dataset is copied to the replication engine buffer based on the second source data pointer.

4. The computing device of claim 2, wherein the replication engine is further configured such that: The first source ring descriptor includes a first length bit indicating the length of the first dataset, a first aggregation bit indicating that the first CRC value is generated as part of a first dataset stream comprising multiple datasets, and a first CRC type indicating a first communication protocol; and The second source ring descriptor includes a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream comprising multiple datasets, and a second CRC type indicating the second communication protocol.

5. The computing device of claim 1, wherein the replication engine is further configured to: The first CRC value of the first dataset copy is generated using the first streaming CRC engine based on a first CRC type indicating the first communication protocol, and The second CRC value of the second dataset copy is generated using the second streaming CRC engine based on the second CRC type indicating the second communication protocol. The first CRC type and the second CRC type are different CRC types.

6. The computing device of claim 1, wherein the replication engine further comprises: A memory mapping subsystem is configured to: Generate a first state ring descriptor that includes the first CRC value and the first state bit; Generate a second state ring descriptor that includes the second CRC value and the second state bit; The first status bit is set in response to the first streaming CRC engine generating the first CRC value; as well as In response to the second streaming CRC engine generating the second CRC value, the second status bit is set. The replication engine is also configured to: In response to the memory-mapped subsystem setting the first status bit to send the first streaming CRC message via the interface bus; and In response to the memory mapping subsystem setting the second status bit, the second streaming CRC message is sent via the interface bus.

7. The computing device according to claim 1, further comprising: A memory mapping subsystem is configured to: Generate a first destination ring descriptor that includes a first destination data pointer; as well as Generate a second destination ring descriptor that includes a second destination data pointer. The replication engine is also configured to: Based on the first destination data pointer, the first streaming CRC message is sent via the interface bus; and The second streaming CRC message is sent via the interface bus based on the second destination data pointer.

8. The computing device of claim 1, wherein the replication engine is further configured to: The third dataset received from the interface bus is copied to the replication engine buffer as a copy of the third dataset; The first streaming CRC engine is used to generate the final CRC value using the third dataset copy and the first CRC value; as well as The first streaming CRC message, comprising the first dataset copy, the third dataset copy, and the final CRC value, is sent to the processor via the interface bus.

9. A method for generating a Cyclic Redundancy Check (CRC) in a secure network, performed by a replication engine of a computing device, the method comprising: The first dataset received from the interface bus is copied in the hardware of the copy engine to obtain a copy of the first dataset; The second dataset received from the interface bus is copied in the hardware of the copy engine to obtain a copy of the second dataset; In the hardware of the replication engine, a first CRC value of the first dataset replica is generated via a first streaming CRC engine, and in parallel, a second CRC value of the second dataset replica is generated via a second streaming CRC engine in the hardware of the replication engine. Send a first streaming CRC message, including a copy of the first dataset and the first CRC value, to the processor of the computing device; and A second streaming CRC message, including a copy of the second dataset and the second CRC value, is sent to the processor.

10. The method according to claim 9, further comprising: A first source ring descriptor is generated based on a first communication message. The first source ring descriptor includes a first source data pointer that indicates the memory location of the first dataset. as well as A second source ring descriptor is generated based on a second communication message. The second source ring descriptor includes a second source data pointer that indicates the memory location of the second dataset.

11. The method of claim 10, wherein: Copying the first dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the first dataset also includes copying the first dataset based on the first source data pointer, and Copying the second dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the second dataset also includes copying the second dataset based on the second source data pointer.

12. The method of claim 10, wherein the first source ring descriptor includes a first length bit indicating the length of the first dataset, a first aggregation bit indicating that the first CRC value is generated as part of a first dataset stream including multiple datasets, and a first CRC type indicating a first communication protocol, and wherein the second source ring descriptor includes a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream including multiple datasets, and a second CRC type indicating a second communication protocol.

13. The method according to claim 9, wherein: The first CRC value generated by the first streaming CRC engine for the first dataset copy also includes the first CRC value generated by the first streaming CRC engine based on a first CRC type indicating a first communication protocol. The second CRC value generated by the second streaming CRC engine for the second dataset copy also includes the second CRC value generated by the second streaming CRC engine based on a second CRC type indicating a second communication protocol.

14. The method of claim 13, wherein the first CRC type and the second CRC type are different CRC types.

15. The method according to claim 9, further comprising: Generate a first state ring descriptor that includes the first CRC value and the first state bit; Generate a second state ring descriptor that includes the second CRC value and the second state bit; After generating the first CRC value, the first status bit is set, wherein sending the first streaming CRC message is performed in response to setting the first status bit; and After generating the second CRC value, the second status bit is set, wherein sending the second streaming CRC message is performed in response to setting the second status bit.

16. The method according to claim 9, further comprising: Generate a first destination ring descriptor that includes a first destination data pointer; as well as Generate a second destination ring descriptor that includes a second destination data pointer. in: Sending the first streaming CRC message further includes sending the first streaming CRC message based on the first destination data pointer, and Sending the second streaming CRC message also includes sending the second streaming CRC message based on the second destination data pointer.

17. The method according to claim 9, further comprising: The third dataset received from the interface bus is copied in the hardware of the copy engine to obtain a copy of the third dataset. The generation of the first CRC value of the first dataset replica via the first streaming CRC engine in the hardware of the replication engine, and the generation of the second CRC value of the second dataset replica via the second streaming CRC engine in the hardware of the replication engine in parallel, further includes: generating a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third dataset replica and the first CRC value. Sending the first streaming CRC message to the processor further includes sending the first streaming CRC message to the processor, which includes the first dataset copy, the third dataset copy, and the final CRC value.

18. A replication engine for a computing device, the replication engine comprising: A component used to copy the first dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the first dataset; A component for copying a second dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the second dataset; Components for generating a first CRC value of the first dataset copy in the hardware of the replication engine via a first streaming CRC engine, and in parallel generating a second CRC value of the second dataset copy in the hardware of the replication engine via a second streaming CRC engine; A component for sending a first streaming CRC message, including a copy of the first dataset and the first CRC value, to the processor of the computing device; and A component for sending a second streaming CRC message to the processor, including a copy of the second dataset and the second CRC value.

19. The replication engine of claim 18, further comprising: A component for generating a first source ring descriptor based on a first communication message, the first source ring descriptor including a first source data pointer indicating a memory location of the first dataset; and The component for generating a second source ring descriptor based on a second communication message, the second source ring descriptor including a second source data pointer indicating the memory location of the second dataset.

20. The replication engine of claim 19, wherein: The component for copying the first dataset received from the interface bus to obtain a copy of the first dataset also includes a component for copying the first dataset based on the first source data pointer, and The component for copying the second dataset received from the interface bus to obtain a copy of the second dataset also includes a component for copying the second dataset based on the second source data pointer.

21. The replication engine according to claim 19, wherein: The first source ring descriptor includes a first length bit indicating the length of the first dataset, a first aggregation bit indicating that the first CRC value is generated as part of a first dataset stream comprising multiple datasets, and a first CRC type indicating a first communication protocol; and The second source ring descriptor includes a second length bit indicating the length of the second dataset, a second aggregation bit indicating that the second CRC value is generated as part of a second dataset stream comprising multiple datasets, and a second CRC type indicating the second communication protocol.

22. The replication engine according to claim 18, wherein: The component for generating the first CRC value of the first dataset copy also includes a component for generating the first CRC value of the first dataset copy based on a first CRC type indicating a first communication protocol; and The component for generating the second CRC value of the second dataset copy also includes a component for generating the second CRC value of the second dataset copy based on a second CRC type indicating a second communication protocol.

23. The replication engine of claim 22, wherein the first CRC type and the second CRC type are different CRC types.

24. The replication engine of claim 18, further comprising: A component for generating a first state ring descriptor that includes the first CRC value and the first state bit; Components used to generate a second state ring descriptor including the second CRC value and the second state bit; A component for setting the first status bit after generating the first CRC value, wherein sending the first streaming CRC message is performed in response to setting the first status bit; and The component is used to set the second status bit after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second status bit.

25. The replication engine of claim 18, further comprising: The component used to generate a first destination ring descriptor, including a first destination data pointer; and The component used to generate a second destination ring descriptor, including a second destination data pointer. in: The component for sending the first streaming CRC message includes a component for sending the first streaming CRC message based on the first destination data pointer, and The component for sending the second streaming CRC message includes a component for sending the second streaming CRC message based on the second destination data pointer.

26. The replication engine of claim 18, further comprising components for replicating a third dataset received from the interface bus to obtain a copy of the third dataset, wherein: The component for generating the first CRC value of the first dataset copy and the second CRC value of the second dataset copy in parallel includes a component for generating a final CRC value using the third dataset copy and the first CRC value; and The component for sending the first streaming CRC message to the processor includes a component for sending the first streaming CRC message to the processor, which includes a copy of the first dataset, a copy of the third dataset, and the final CRC value.

27. A non-transitory processor-executable medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause a copy engine of a computing device to perform operations, the operations including: The first dataset received from the interface bus is copied in the hardware of the copy engine to obtain a copy of the first dataset; The second dataset received from the interface bus is copied in the hardware of the copy engine to obtain a copy of the second dataset; In the hardware of the replication engine, a first CRC value of the first dataset replica is generated via a first streaming CRC engine, and in parallel, a second CRC value of the second dataset replica is generated via a second streaming CRC engine in the hardware of the replication engine. Send a first streaming CRC message, including a copy of the first dataset and the first CRC value, to the processor of the computing device; and A second streaming CRC message, including a copy of the second dataset and the second CRC value, is sent to the processor.

28. The non-transitory processor-executable medium of claim 27, wherein the stored processor-executable instructions are further configured to cause the copy engine of the computing device to perform an operation, the operation further comprising: A first source ring descriptor is generated based on a first communication message. The first source ring descriptor includes a first source data pointer that indicates the memory location of the first dataset. as well as A second source ring descriptor is generated based on a second communication message. The second source ring descriptor includes a second source data pointer that indicates the memory location of the second dataset.

29. The non-transitory processor-executable medium of claim 28, wherein the stored processor-executable instructions are further configured to cause the copy engine of the computing device to perform operations such that: Copying the first dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the first dataset also includes copying the first dataset based on the first source data pointer, and Copying the second dataset received from the interface bus in the hardware of the replication engine to obtain a copy of the second dataset also includes copying the second dataset based on the second source data pointer.

30. A computer program product comprising computer instructions that, when executed by a processor of a replication engine of a computing device for generating cyclic redundancy check (CRC) in a secure network, cause the processor to perform the method according to any one of claims 9-17.

Images