Network device and method for exchange, routing and / or gateway of data

Network devices designed through hardware and software collaboration, employing parallel and pipelined processing methods, overcome the shortcomings of existing software methods in real-time performance, enabling efficient data exchange and routing between different subnets of the communication network, and meeting the latency, performance, and security requirements of the automotive industry.

CN116569533BActive Publication Date: 2026-06-02YINWANG INTELLIGENT TECHNOLOGIES CO LTD

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
YINWANG INTELLIGENT TECHNOLOGIES CO LTD
Filing Date
2020-12-11
Publication Date
2026-06-02

AI Technical Summary

Technical Problem

Existing software-based network gateway methods may not be optimal in terms of ensuring real-time performance (especially in terms of latency, jitter, bandwidth, and/or throughput for next-generation autonomous vehicles), and are difficult to efficiently exchange, route, and/or gateway data between different subnets of a communication network.

Method used

Network devices with hardware/software co-design include a central processing unit, data ingress ports, data egress ports, and multiple coprocessors (such as frame normalization, ingress queuing, filtering and policing, intermediate queuing, gateway, egress queuing, and traffic shaping coprocessors) to process data frames in parallel and pipelined manner, meeting reliability and network security requirements.

Benefits of technology

It optimizes data processing latency, jitter, bandwidth, and throughput, enabling efficient data exchange, routing, and gatewaying between different subnets of the communication network, meeting the automotive industry's requirements for latency, performance, reliability, and functional safety.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN116569533B_ABST
    Figure CN116569533B_ABST
Patent Text Reader

Abstract

A network device for the exchange, routing and / or gatewaying of data between different subnets of a communication network, comprising: a central processing unit; one or more data ingress ports and one or more data egress ports for exchanging data with another network device of the communication network; a plurality of co-processors, including one or more frame normalization co-processors, one or more ingress queuing co-processors, one or more filtering and policing co-processors, one or more intermediate queuing co-processors, at least one gateway co-processor, one or more egress queuing co-processors and at least one traffic shaping co-processor; the central processing unit being adapted to configure and control the one or more data ingress ports, the one or more data egress ports and the plurality of co-processors to implement one or more data processing paths in parallel and / or pipelined between the one or more ingress ports and the one or more egress ports.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention generally relates to communication networks. More specifically, this invention relates to apparatus and methods for exchanging, routing, and / or gatewaying data between different subnets of a communication network. Background Technology

[0002] Network gateways are inherently complex and demanding processing tasks, especially in the automotive sector, where many heterogeneous in-vehicle network technologies and protocols coexist (such as CAN 2.0, CAN FD, LIN, FlexRay, or Ethernet).

[0003] While software-based network gateways are currently the de facto choice, they may not be the optimal option in terms of guaranteeing real-time performance, particularly in terms of latency, jitter, bandwidth, and / or throughput for next-generation autonomous vehicles.

[0004] In view of the above, there is a need for an improved device and method for efficiently exchanging, routing and / or gatewaying data between different subnets of a communication network. Summary of the Invention

[0005] The purpose of this invention is to provide an improved network device and method for efficiently exchanging, routing, and / or gatewaying data between different subnets of a communication network.

[0006] Generally, embodiments of the present invention relate to novel concepts of efficient communication gateway methods and devices. In other words, embodiments of the present invention enable the efficient design and development of complete construction methods through hardware / software co-design to synthesize communication gateways into functional products.

[0007] Furthermore, as a result of this method, the resulting physical gateway device is responsible for executing a full set of communication features, primarily forwarding, encapsulating, and processing protocol data units (PDUs) or data frames between different networks within a given network infrastructure, and meeting another set of requirements related to reliability or functional safety and network security. All the necessary algorithms are embedded within and executed within such a gateway device.

[0008] Embodiments of the present invention are suitable for and can be deployed in many industries and use cases: from general information and communication technologies or enterprise networks to smart manufacturing networks, Internet of Things (IoT) networks, and even automotive in-vehicle networks.

[0009] More specifically, according to a first aspect, the present invention relates to a network device for exchanging, routing, and / or gatewaying data between different subnets of a communication network, wherein the network device includes: a central processing unit; one or more data ingress ports and one or more data egress ports; and a plurality of coprocessors. The one or more data ingress ports and one or more data egress ports are used to exchange data with another network device in the communication network, and the plurality of coprocessors include one or more frame normalization coprocessors, one or more ingress queuing coprocessors, one or more filtering and monitoring coprocessors, one or more intermediate queuing coprocessors, at least one gateway coprocessor, one or more egress queuing coprocessors, and at least one traffic shaping coprocessor, wherein the central processing unit is adapted to configure and control the one or more data ingress ports, the one or more data egress ports, and the plurality of coprocessors to implement one or more data processing paths in parallel and / or pipelined between the one or more ingress ports and the one or more egress ports.

[0010] In view of the above, an improved network device is provided that supports efficient data exchange, routing, and / or gatewaying between different subnets of a communication network.

[0011] In another possible implementation of the first aspect, one or more input ports and one or more output ports are based on heterogeneous network technologies, including at least one or two of LIN, CAN 2.0, CAN-FD, CAN-XL, FlexRay, 10Base-T1S, 100Base-T1, 100Base-T, 1000Base-T1, 1000Base-T, and / or 10GBase-T. Advantageously, this supports efficient and network / protocol-independent data processing between the input and output ports.

[0012] In another possible implementation of the first aspect, each of one or more frame normalization coprocessors is used to convert one or more ingress frames for a given network technology into one or more normalized data link layer frames, wherein the normalized data link layer frames are network technology-independent and / or protocol-independent data link layer frames, constructed as a bit stream including a frame header, frame payload, and frame trailer. Advantageously, this supports efficient, more abstract, and less complex data processing between ingress and egress ports.

[0013] In another possible implementation of the first aspect, each of one or more frame normalization coprocessors can also be used to verify the integrity of the entire data link layer frame. Advantageously, this ensures the integrity of the data link layer frame.

[0014] In another possible implementation of the first aspect, each of one or more frame normalization coprocessors is used to convert one or more incoming frames into a bit stream organized by a set of information fields, each of which has a specific length and is encoded with a specific meaning according to the given network technology and / or protocol to which the incoming frame belongs, including LIN, CAN 2.0, CAN-FD, CAN-XL, FlexRay, 10Base-T1S, 100Base-T1, 100Base-T, 1000Base-T1, 1000Base-T, and / or 10GBase-T. Advantageously, this supports efficient, more abstract, and less complex data processing between the ingress and egress ports.

[0015] In another possible implementation of the first aspect, each of the one or more ingress queuing coprocessors includes a memory (particularly a FIFO memory) for caching one or more data link layer frames (particularly one or more data link layer frames generated by one or more frame normalization coprocessors). Advantageously, this supports more efficient caching of data link layer frames.

[0016] In another possible implementation of the first aspect, each of one or more filtering and monitoring coprocessors is used to parse the frame header and / or frame payload of one or more data link layer frames according to one or more matching rules and / or one or more regular expression searches, and to filter, monitor, and classify the one or more data link layer frames according to one or more matching rules and / or one or more regular expression searches. Advantageously, this supports the conversion of ingress frames into normalized data link layer frames, which are then more efficiently pattern-matched with a set of rules and / or signatures.

[0017] In another possible implementation of the first aspect, each of the one or more filtering and monitoring coprocessors is also used to implement a secure firewall and / or network intrusion detection system applied to each of the one or more data link layer frames. Advantageously, this supports the conversion of ingress frames into normalized data link layer frames, which are then efficiently and securely pattern-matched with a set of rules and / or signatures.

[0018] In another possible implementation of the first aspect, each of one or more filtering and regulatory coprocessors is used to process the frame headers and / or payloads of one or more data link layer frames in parallel and / or pipelined modes. Advantageously, this supports the conversion of ingress frames into normalized data link layer frames, which are then used for pattern matching more efficiently with a set of rules and / or signatures.

[0019] In another possible implementation of the first aspect, each of the one or more intermediate queuing coprocessors includes memory (specifically a FIFO memory) for caching one or more filtered data link layer frames filtered by the one or more filtering and monitoring coprocessors. Advantageously, this supports more efficient caching of data link layer frames filtered by the one or more filtering and monitoring coprocessors.

[0020] In another possible implementation of the first aspect, at least one gateway coprocessor is also used to perform any related actions associated with any given positive matching operation performed by the filtering and monitoring coprocessor on each data link layer frame, including alarm triggering operation, frame forwarding operation, frame routing operation, frame pass-through switching operation, frame duplication operation, frame elimination operation, frame encryption / decryption operation, frame compression / decompression operation, frame encapsulation / decapsulation operation, frame tunneling operation, and / or frame aggregation operation, and / or at least one gateway coprocessor is used to generate new data link layer frames.

[0021] In another possible implementation of the first aspect, at least one gateway coprocessor is used to apply one or more gateway operations and / or routing operations and / or switching operations to one or more filtered data link layer frames in parallel and / or pipelined modes. Advantageously, this supports more efficient gatewaying, routing, and switching of data link layer frames.

[0022] In another possible implementation of the first aspect, each of the one or more egress queuing coprocessors includes a memory (specifically a FIFO memory) for caching one or more data link layer frames provided by at least one gateway coprocessor. Advantageously, this supports more efficient caching of data link layer frames provided by at least one gateway coprocessor.

[0023] In another possible implementation of the first aspect, at least one traffic shaping coprocessor is used to control the provision of one or more data link layer frames to one or more output ports. Advantageously, this supports more efficient provision of data link layer frames.

[0024] In another possible implementation of the first aspect, at least one traffic shaping coprocessor is used to perform any frame shaping-related actions on each data link layer frame for each outgoing port, including time-aware shaping operations, credit-based shaping operations, asynchronous traffic shaping operations, cyclic queuing shaping operations, and / or frame preemption operations. Advantageously, any frame shaping-related actions can be performed efficiently on each data link layer frame.

[0025] In another possible implementation of the first aspect, at least one traffic shaping coprocessor is used to apply one or more traffic shaping operations to one or more filtered data link layer frames in parallel and / or pipelined modes. Advantageously, any frame shaping-related actions can be performed efficiently on each data link layer frame.

[0026] In another possible implementation of the first aspect, the network device further includes a communication bus, and the central processing unit (CPU) is used to communicate with multiple coprocessors via the communication bus to implement control paths that can be used to exchange instruction frames. Advantageously, this supports efficient communication between the CPU and the multiple coprocessors.

[0027] In another possible implementation of the first aspect, for each of one or more data link layer frames, multiple coprocessors are used to exchange instruction frames via a communication bus, wherein the instruction frame includes one or more commands for processing the corresponding data link layer frame, and wherein the communication bus is used to provide the corresponding instruction frame to the corresponding coprocessor synchronously with the corresponding data link layer frame. Advantageously, this supports efficient communication between multiple coprocessors and enables multiple coprocessors to process data link layer frames efficiently.

[0028] In another possible implementation of the first aspect, each data link layer frame moving within the network device is processed by multiple coprocessors in the data plane, while its associated instruction frame is processed simultaneously and in parallel by the control plane. The instruction frame moves from one coprocessor level to the next, synchronized with the back-and-forth movement of its associated data link layer frame. Advantageously, this supports efficient processing of data link layer frames and efficient management of the corresponding instruction frames.

[0029] In another possible implementation of the first aspect, the control plane of the network device is implemented by a central processing unit and / or a finite state machine (FSM) and / or an arithmetic logic unit (ALU), implemented in hardware within one or more coprocessors of the data plane, acting as a distributed controller of the control plane, responsible for executing instruction frames associated with each data link layer frame moving in the data plane. Advantageously, this supports efficient management of instruction frames.

[0030] In another possible implementation of the first aspect, each data link layer frame moved via the data plane within multiple coprocessors has an associated instruction frame moved via the control plane. Advantageously, this supports efficient processing of data link layer frames and efficient management of the corresponding instruction frames.

[0031] In another possible implementation of the first aspect, each instruction frame includes a header, payload, and trailer, which are organized with a set of fields and commands to indicate one or more operations to be performed to one or more coprocessors in the data plane. Advantageously, this supports efficient management of each instruction frame.

[0032] In another possible implementation of the first aspect, each instruction frame associated with a data link layer frame includes an information field containing metadata about the data link layer frame. This information field includes at least one of the following: port number, network type, ingress frame timestamp, frame length, frame priority, number of matching rules, one or more commands, and one or more command parameters. Advantageously, this supports efficient management of each instruction frame.

[0033] In another possible implementation of the first aspect, data link layer frames provided by the filtering and regulatory coprocessors are forwarded to one or more intermediate queuing coprocessors and / or returned to one or more ingress queuing coprocessors. Advantageously, this supports iteration over different processing levels of data link layer frames.

[0034] In another possible implementation of the first aspect, data link layer frames provided by one or more gateway coprocessors are forwarded to one or more egress queuing coprocessors, and / or returned to one or more intermediate queuing coprocessors, and / or returned to one or more ingress queuing coprocessors. Advantageously, this supports iteration over different processing levels of data link layer frames.

[0035] In another possible implementation of the first aspect, data link layer frames provided by one or more traffic shaping coprocessors are forwarded to one or more egress ports, and / or returned to one or more intermediate queuing coprocessors, and / or returned to one or more ingress queuing coprocessors. Advantageously, this supports iteration over different processing levels of data link layer frames.

[0036] In another possible implementation of the first aspect, the read / write ports of the ingress queue, intermediate queue, and egress queue have the same or different clock frequencies, thereby supporting different clock domains in the data path of frames flowing from the ingress port to the egress port through the normalization coprocessor, filtering and regulatory coprocessor, gateway coprocessor, and traffic shaping coprocessor.

[0037] In another possible implementation of the first aspect, the network device is an automotive gateway electronic control unit. Therefore, an improved automotive gateway electronic control unit is provided that supports optimized data processing latency, jitter, bandwidth, and / or throughput, as well as efficient data exchange, routing, and / or gatewaying between different subnets of the communication network.

[0038] According to a second aspect, the present invention relates to a method for providing a network device for exchanging, routing, and / or gatewaying data between different subnets of a communication network, wherein the method includes the following steps: providing a central processing unit; providing one or more data ingress ports and one or more data egress ports for exchanging data with another network device in the communication network; providing a plurality of coprocessors, wherein the plurality of coprocessors includes one or more frame normalization coprocessors, one or more ingress queuing coprocessors, one or more filtering and regulatory coprocessors, one or more intermediate queuing coprocessors, at least one gateway coprocessor, one or more egress queuing coprocessors, and at least one traffic shaping coprocessor, wherein the central processing unit is responsible for configuring and controlling the one or more data ingress ports, the one or more data egress ports, and the plurality of coprocessors to implement one or more data processing paths in parallel and / or pipelined between the one or more ingress ports and the one or more egress ports.

[0039] Therefore, an improved method is provided to enable network devices to efficiently exchange, route, and / or gateway data between different subnets of a communication network.

[0040] One or more embodiments will be described in detail in the accompanying drawings and the following description. Other features, objects, and advantages will be apparent from the specification, drawings, etc. Attached Figure Description

[0041] The embodiments of the present invention will now be described in more detail with reference to the accompanying drawings.

[0042] Figure 1 This is a schematic diagram of an exemplary communication network 100 including network device 101 and another network device 131 according to an embodiment.

[0043] Figure 2 This is a schematic diagram of an exemplary network device 101, which is shown as a gateway electronic control unit according to an embodiment.

[0044] Figure 3 This is a schematic diagram illustrating an exemplary instruction frame 300 according to an embodiment.

[0045] Figure 4 This is a schematic diagram of the gateway portion of an exemplary network device 101, which is shown as an automotive gateway electronic control unit according to an embodiment, wherein data processing paths are implemented in parallel and / or pipelined between ingress and egress ports.

[0046] Figure 5 This is a schematic diagram of an exemplary network device 101, shown as an automotive gateway electronic control unit, according to an embodiment, wherein the data processing path includes iterations at different processing levels.

[0047] Figure 6This is a schematic diagram of an exemplary network device 101, shown as an automotive gateway electronic control unit, according to an embodiment, wherein the data processing path includes iterations at different processing levels.

[0048] Figure 7 This is a flowchart of a method 700 for providing network devices for exchanging, routing, and / or gatewaying data between different subnets of a communication network.

[0049] Hereinafter, the same reference numerals denote the same or at least functionally equivalent features. Detailed Implementation

[0050] In the following description, reference is made to the accompanying drawings, which form part of this disclosure and illustrate specific aspects of embodiments of the invention or aspects in which embodiments of the invention may be used. It should be understood that embodiments of the invention may be used in other aspects and may include structural or logical variations not depicted in the drawings. Therefore, the following detailed description should not be construed as limiting.

[0051] For example, it should be understood that the disclosure relating to the described method also applies to the corresponding apparatus or system for performing the method, and vice versa. For instance, if one or more specific method steps are described, the corresponding apparatus may include one or more units, such as functional units for performing the described one or more method steps (e.g., a unit performing one or more steps; or multiple units, each performing one or more of the multiple steps), even if such one or more units are not explicitly described or shown in the drawings. Furthermore, for example, if a specific apparatus is described based on one or more units (e.g., functional units), the corresponding method may include a step for performing the function of one or more units (e.g., a step performing the function of one or more units; or multiple steps, each performing the function of one or more of the multiple units), even if such one or more steps are not explicitly described or shown in the drawings. Further, it should be understood that, unless otherwise explicitly stated, features of the various exemplary embodiments and / or aspects described herein can be combined with each other.

[0052] The engineering workload required to develop an automotive gateway electronic control unit (ECU) (i.e., hardware / software co-design) should not be underestimated: it involves a large team of dozens of hardware, software and systems engineers working together for a long time, usually no less than one or two years, covering the entire product development cycle, from abstract concept to design and development, verification and certification, and finally to mass production.

[0053] State-of-the-art gateway designs are primarily based on software implementations, such as those guided by the AUTOSAR architecture. However, while software-based approaches are currently the de facto solution, they may no longer be the optimal choice for autonomous driving (AD) solutions, particularly in terms of latency, performance, reliability, and functional safety for next-generation L3 to L5 autonomous vehicles.

[0054] In contrast, hardware-driven gateway alternatives offer several advantages. In the automotive industry, some original equipment manufacturers (OEMs) or Tier 1 suppliers have already recognized this opportunity. Other solutions can be based on specific hardware architectures and hardware accelerators combined with software CPU cores.

[0055] Currently, there is a technology called Software Defined Networking (SDN), which drives the integration of network functions in hardware based on descriptions in software. Furthermore, a programming language called P4 has been developed for this purpose, through which a certain number of network algorithms or use cases can be deployed, but not all of them.

[0056] While Software-Defined Networking (SDN) is a powerful design strategy for implementing network systems, the level of abstraction required to handle only three programmable blocks (i.e., the parser, matching action, and inverse parser) is insufficient for realizing a true gateway electronic control unit capable of meeting the full suite of requirements for the automotive industry. In other words, such a level of abstraction is too high to achieve the challenging product that requires appropriate controllability in the design process and delivers the expected accuracy on target key performance indicators (KPIs).

[0057] In this regard, an alternative approach is needed for the efficient exchange, routing, and / or gatewaying of data between different subnets of a communication network.

[0058] As detailed below, embodiments of the present invention are described in the context of automotive technology, providing an innovative approach to building future automotive gateway electronic control units (ECUs). Perhaps the most relevant singularity of automotive in-vehicle networks compared to other industrial networks is the coexistence of many different types of network technologies in the automotive field, such as the recently adopted automotive Ethernet 100Base-T1, 1000Base-T1, or other traditional buses such as CAN 2.0, CAN-FD, LIN, and FlexRay. The methods, apparatus, and systems developed according to the embodiments herein can be applied to specific computing units or semiconductor devices synthesized in silicon, which become the processing core of the gateway electronic control unit (typically a system-on-chip (SoC) or microcontroller unit (MCU)).

[0059] The automotive electrical / electronic (EE) architecture consists of electronic control units (ECUs), which are physically distributed across the vehicle's mechanical chassis or infrastructure and are divided into high-performance computers (HPCs) and zonal gateways (ZGWs). All of these ECUs are interconnected through heterogeneous in-vehicle networks.

[0060] In this respect, gateways are inherently complex and computationally demanding tasks, especially in the automotive field where many heterogeneous network technologies and protocols coexist. Based on network and transport protocol instructions and standards, and according to the layered Open Systems Interconnection (OSI) model, gateway modules are responsible for receiving and sending frames between ingress and egress ports by encapsulating, aggregating, tunneling, and / or processing protocol data units (PDUs) or data frames.

[0061] Ideal gateway processing involves adapting Protocol Data Units (PDUs) from one network to another, but minimizing the impact of this transition; that is, minimizing the latency of this processing when moving PDUs from the gateway's ingress port to the egress port according to existing switching / routing mechanisms.

[0062] Many of these tasks performed by the gateway ECU are time-consuming, such as protocol conversion and data encapsulation from one network to another (e.g., for LIN, CAN, and the IEEE 1722 standard for Ethernet-based FlexRay).

[0063] Designing gateway devices involves addressing and meeting a multitude of standards and requirements. In the specific context of the automotive industry, any automotive-certified gateway ECU must meet specifications from various technical perspectives, such as performance (KPIs related to connection count, network type, bandwidth, latency, and jitter), configurability (SDN), time-sensitive networking (TSN) standards, network security measures, and functional safety requirements.

[0064] Embodiments of the present invention provide a novel method for constructing a physical gateway ECU that embeds a user-required and specified set of functions through hardware / software co-design. Thus, one part of the function is implemented in software to run on a CPU, while another part is synthesized in hardware via a coprocessor, peripheral, or hardware engine interconnected with a system-on-a-chip (SoC) or microcontroller, in which the complete gateway ECU application is integrated.

[0065] As will be described in more detail below, especially with reference to Figure 1 and Figure 2 Embodiments of the present invention provide a gateway architecture designed to leverage hardware parallelism and pipeline strategies based on sequential and ultra-fast ingress-to-egress data paths, with the goal of optimizing processing latency for each frame.

[0066] Figure 1 This is a schematic diagram of an exemplary communication network 100 according to an embodiment, including network device 101 and another network device 131, wherein network device 101 is used for exchanging, routing, and / or gatewaying data between different subnets of the communication network 100. In one embodiment, network device 101 is an automotive gateway electronic control unit.

[0067] like Figure 1 As shown in the detailed view, network device 101 includes a central processing unit 103, one or more data ingress ports 105a, one or more data egress ports 107a, and a plurality of coprocessors 109. In one embodiment, the central processing unit 103 is adapted to configure and control one or more data ingress ports 105a, one or more data egress ports 107a, and a plurality of coprocessors 109 to implement one or more data processing paths in parallel and / or pipelined between one or more ingress ports 105a and one or more egress ports 107a.

[0068] In another embodiment, network device 101 further includes a communication bus, through which central processing unit 103 communicates with multiple coprocessors 109 to implement a control path that can be used to exchange instruction frames as metadata linked to each individual data frame.

[0069] Furthermore, one or more data input ports 105a and one or more data output ports 107a are used to exchange data with another network device 131 of the communication network 100. In one embodiment, the one or more input ports 105a and one or more output ports 107a are based on heterogeneous network technologies, including at least one or two of LIN, CAN 2.0, CAN-FD, CAN-XL, FlexRay, 10Base-T1S, 100Base-T1, 100Base-T, 1000Base-T, 1000Base-T, and / or 10GBase-T.

[0070] like Figure 1 As shown in a further detailed view, the multiple coprocessors 109 include one or more frame normalization coprocessors 111a, one or more inbound queuing coprocessors 113a, one or more filtering and regulatory coprocessors 115a, one or more intermediate queuing coprocessors 117a, at least one gateway coprocessor 119, one or more outbound queuing coprocessors 121a, and at least one traffic shaping coprocessor 123. The functionality of these coprocessors will be discussed in further detail below.

[0071] In one embodiment, each of the one or more frame normalization coprocessors 111a is configured to convert one or more ingress frames of a given network technology into one or more normalized data link layer frames, wherein the normalized data link layer frames are network technology-independent and / or protocol-independent data link layer frames, and are constructed as a bit stream including a frame header, a frame payload, and a frame trailer. Furthermore, each of the one or more frame normalization coprocessors 111a can also be configured to verify the integrity of the entire data link layer frame.

[0072] In another embodiment, each of one or more frame normalization coprocessors 111a is configured to convert one or more incoming frames into a bit stream organized by a set of information fields, each of which has a specific length and is encoded with a specific meaning according to a given network technology and / or protocol to which the incoming frame belongs, including LIN, CAN 2.0, CAN-FD, CAN-XL, FlexRay, 10Base-T1S, 100Base-T1, 100Base-T, 1000Base-T1, 1000Base-T, and / or 10GBase-T.

[0073] After generating one or more data link layer frames, each of the one or more filtering and regulatory coprocessors 115a is used to parse the frame header and / or frame payload of the one or more data link layer frames according to one or more matching rules and / or one or more regular expression searches. Each of the one or more filtering and regulatory coprocessors is used to process the frame header and payload of the one or more data link layer frames in parallel mode and / or pipelined mode.

[0074] In another embodiment, each of the one or more filtering and monitoring coprocessors is configured to filter, monitor, and classify one or more data link layer frames based on one or more matching rules and / or one or more regular expression searches. In another embodiment, each of the one or more filtering and monitoring coprocessors is also configured to implement a security firewall and / or network intrusion detection system applied to each of the one or more data link layer frames.

[0075] In another embodiment, at least one gateway coprocessor 119 is configured to perform any associated actions related to any given positive match operation performed by the filtering and monitoring coprocessor on each data link layer frame, including alarm triggering, frame forwarding, frame routing, frame pass-through switching, frame duplication, frame elimination, frame encryption / decryption, frame compression / decompression, frame encapsulation / decapsulation, frame tunneling, and / or frame aggregation.

[0076] In another embodiment, at least one gateway coprocessor 119 is configured to apply one or more gateway operations and / or routing operations and / or switching operations to one or more filtered data link layer frames in parallel and / or pipelined modes. Furthermore, at least one gateway coprocessor 119 is configured to generate new data link layer frames.

[0077] According to one embodiment, in order to cache one or more data link layer frames at different levels of their data processing path, each of the one or more ingress queuing coprocessors 113a includes memory for caching one or more data link layer frames (particularly data link layer frames generated by one or more frame normalization coprocessors). Similarly, each of the one or more intermediate queuing coprocessors 117a includes memory for caching one or more filtered data link layer frames filtered by one or more filtering and monitoring coprocessors 115a, and each of the one or more egress queuing coprocessors 121a also includes memory for caching one or more data link layer frames provided by at least one gateway coprocessor 119.

[0078] In this regard, according to one embodiment, data link layer frames provided by the filtering and monitoring coprocessor 115a are forwarded to one or more intermediate queuing coprocessors 117a and / or returned to one or more ingress queuing coprocessors 113a. Further, data link layer frames provided by one or more gateway coprocessors 119 are forwarded to one or more egress queuing coprocessors 121a, and / or returned to one or more intermediate queuing coprocessors 117a, and / or returned to one or more ingress queuing coprocessors 113a. Additionally, data link layer frames provided by one or more traffic shaping coprocessors 123 are forwarded to one or more egress ports 121a, and / or returned to one or more intermediate queuing coprocessors 117a, and / or returned to one or more ingress queuing coprocessors 113a.

[0079] In one embodiment, the memory of each of one or more inlet queuing coprocessors 113a and / or each of one or more intermediate queuing coprocessors 117a and / or each of one or more outlet queuing coprocessors 121a may be a FIFO memory.

[0080] In another embodiment, network device 101 has three queuing levels (i.e., executed by one or more ingress queuing coprocessors, one or more intermediate queuing coprocessors, and one or more egress queuing coprocessors) supporting up to three different internal clock domains or processing speeds: one from the ingress port to the ingress queue, another from the ingress queue to the intermediate queue, and the last from the intermediate queue to the egress port.

[0081] Finally, at least one traffic shaping coprocessor 123 is used to control the provision of one or more data link layer frames to one or more outgoing ports 107a. In one embodiment, at least one traffic shaping coprocessor 123 is used to perform any frame shaping-related actions for each data link layer frame of each outgoing port, including time-aware shaping operations, credit-based shaping operations, asynchronous traffic shaping operations, cyclic queuing shaping operations, and / or frame preemption operations. At least one traffic shaping coprocessor 123 is used to apply one or more traffic shaping operations to the filtered one or more data link layer frames in parallel mode and / or pipelined mode.

[0082] As described above, the central processing unit 103 of the network device 101 is used to communicate with a plurality of coprocessors 109 via a communication bus. According to one embodiment, for each of one or more data link layer frames, the plurality of coprocessors 109 are used to exchange instruction frames via the communication bus, wherein the instruction frame includes one or more commands for processing the corresponding data link layer frame, and wherein the communication bus is used to provide the corresponding instruction frame to the corresponding coprocessor synchronously with the corresponding data link layer frame.

[0083] Furthermore, each data link layer frame moving within network device 101 is processed by multiple coprocessors 109 of the data plane, while its associated instruction frame is processed in parallel by the control plane. The instruction frame moves from one coprocessor level to the next coprocessor level in sync with the back-and-forth movement of its associated data link layer frame.

[0084] In one embodiment, the control plane of the network device is implemented by a central processing unit 103 and / or a finite state machine (FSM) and / or an arithmetic logic unit (ALU), implemented in hardware within one or more coprocessors of the data plane. This acts as a distributed controller for the control plane, responsible for executing instruction frames associated with each data link layer frame moving through the data plane. In one embodiment, each data link layer frame moving through the data plane within multiple coprocessors has an associated instruction frame moving through the control plane, which stores some metadata or commands related to the data frame.

[0085] In another embodiment, each instruction frame includes a header, payload, and trailer, which are organized with a set of fields and commands to instruct one or more coprocessors in the data plane to perform one or more operations. Furthermore, each instruction frame associated with a data link layer frame includes an information field containing metadata about the data link layer frame, including at least one of the following: port number, network type, ingress frame timestamp, frame length, frame priority, number of matching rules, one or more commands, and one or more command parameters.

[0086] Figure 2 This is a schematic diagram of an exemplary network device 101, shown as an automotive gateway electronic control unit (ECU), according to an embodiment based on hardware / software partitioning technology, wherein time-critical operations or functions can be deployed in hardware through dedicated and reconfigurable coarse-grained function blocks.

[0087] like Figure 2 As shown in the detailed view, network device 101 includes a central processing unit 103, one or more data ingress ports 105a-105c, one or more frame normalization coprocessors 111a-111c, one or more ingress queuing coprocessors 113a-113c, one or more filtering and censoring coprocessors 115a-115c, one or more intermediate queuing coprocessors 117a-117c, at least one gateway coprocessor 119, one or more egress queuing coprocessors 121a-121d, at least one traffic shaping coprocessor 123, and one or more data egress ports 107a-107d. The functions of the central processing unit 103, the various coprocessors, and the data ingress or egress ports have been discussed in detail above.

[0088] Advantageously, embodiments of the present invention elevate the design approach for such complex network systems and products to a new level by developing a novel method to fill design gaps in detected network, communication, and computing systems. Although initially inspired by Software-Defined Networking (SDN), this method surpasses SDN to some extent in providing better design granularity and accuracy.

[0089] In one embodiment, a library of specific hardware components or primitives is constructed that are responsible for performing a wide range of communication functions typically required in such network products (i.e., switches, routers, gateways, etc.). This set of functions is primarily developed in hardware rather than software with the aim of offloading the system-on-chip (SoC) or microcontroller unit (MCU) from the system's central processing unit (CPU) while ensuring good performance, particularly in terms of latency, jitter, bandwidth, and throughput.

[0090] Furthermore, this group of components in the library becomes highly configurable through a set of design parameters. Therefore, a standard set of coarse-grained building blocks is provided in a way that maintains flexibility while allowing for dynamic reconfiguration (i.e., during runtime, without halting system execution) in a very short time. All these building blocks provided in the library integrate all the functions expected in an automotive gateway electronic control unit (ECU).

[0091] In addition to the novelty of the design methodology, embodiments of the present invention also focus on a system approach. At the system level, embodiments of the present invention provide a streamlined set of building blocks that can practically allocate the full set of standards currently required in an automotive gateway ECU from three main design pillars: high performance (latency), functional safety (reliability, fault operation), and cybersecurity (attack protection), as shown in Table 1 below.

[0092]

[0093] Table 1: Typical Standards That Any Automotive GW ECU Must Meet

[0094] Based on this approach, the design of the target gateway ECU can be customized through the instantiation of a complete set of components to build the required geometry and classification in terms of inlet and outlet ports as well as internal functions / features.

[0095] The gateway architecture according to embodiments of the present invention aims to leverage hardware parallelism and pipeline strategies based on sequential and ultra-fast ingress-to-egress data paths, with the goal of optimizing the processing latency of each frame.

[0096] like Figure 2As shown, the functional architecture of the gateway electronic control unit (ECU) in this embodiment can be decomposed at the first level of abstraction into a series of processing levels other than CPU interaction, generating a data path of frames from the ingress port to the egress port: frame normalization; ingress queuing; filtering and monitoring; intermediate queuing; gateway; egress queuing; and traffic shaping.

[0097] Compared to Software-Defined Networking (SDN) as described above, the number of different components or building blocks in the embodiments of this invention is significantly greater than in an SDN consisting of only three elements or processing levels: a parser, a matching action engine, and a reverse parser. This key difference enables the level of controllability and accuracy required by the gateway ECU of this embodiment.

[0098] At the second level of abstraction, the building blocks of a gateway device can be broken down into another set of functional blocks to deploy the complete list of standards and protocols detailed in Table 1. These flexible and reconfigurable coarse-grained building blocks at this second level are also part of a library detailed in this methodology for creating gateway devices based on modular and reusable design.

[0099] In one embodiment, Figure 2 The data paths and set of functions shown are the correct building blocks required to construct any automotive gateway that any original equipment manufacturer (OEM) might need. No state-of-the-art approach considered the full set of standards detailed in Table 1 to construct a gateway device; this gap has now been covered, allowing most of the required functions and standards to be implemented directly in software executed by the system's CPU.

[0100] like Figure 2 As shown, the functions embedded in the main hardware blocks (i.e., coprocessors) that constitute the complete data path of the gateway electronic control unit (ECU) are described in detail below:

[0101] Frame Normalization: This block or coprocessor is responsible for normalizing incoming frames, internally treating them as OSI Layer 2 standard frames. This normalization is invariant to / independent of the network nature or protocol (e.g., LIN, CAN 2.0, CAN-FD, FlexRay, 100BaseT1, 1000BaseT1), i.e., as a simple bitstream organized as a set of data fields, each with a specific meaning. Therefore, this function block can process any type of frame by interpreting it as a sequence of data fields or words with specific meanings, depending on its internal encoding based on its network / protocol type.

[0102] It's important to note that this functional block converts incoming data frames into network / protocol-independent normalized frames; that is, bitstreams, regardless of whether they correspond to Ethernet or CAN frames. This is a strategic aspect of the design because it supports an abstraction scheme that remains invariant to network protocols, thus encompassing many types of products, such as enterprise routers that only handle Ethernet ports, and automotive gateways that handle heterogeneous ports like Ethernet, CAN, and LIN, all configured to be handled accordingly by the same physical device. Furthermore, new networks still under development or soon to be introduced can be integrated into this scheme without requiring any hardware changes, as this level of abstraction allows for handling at the configuration level.

[0103] Entry queuing: The FIFO memory is used as a buffer between the frame normalization level and the next processing level. From an architectural perspective, this queue supports the creation of two different clock domains or processing levels operating at different speeds, one clock domain or processing level for writing and the other clock domain or processing level for reading.

[0104] Filtering and Monitoring: For the frame header and payload, this block or coprocessor is essentially responsible for performing filtering, classification, and monitoring actions on inbound frames based on a rule-based matching engine. This matching process is shared across many operations performed in gateway devices: from frame filtering to implementing security firewalls and / or intrusion detection systems, and even routing matrix operations.

[0105] At the filtering and oversight level and at the gateway level, many Time-Sensitive Networking (TSN) standards, as well as many other standards (such as network security, functional safety, high performance, etc.), are deployed in the hardware through dedicated tasks or function blocks allocated within these two coprocessors (i.e., the filtering and oversight coprocessor and the gateway coprocessor).

[0106] Intermediate queuing: The FIFO memory is used as a cache between the filtering and supervisory level and the next processing level. From an architectural perspective, this queue supports the creation of two different clock domains or processing levels operating at different speeds, one clock domain or processing level for writing and the other clock domain or processing level for reading.

[0107] Gateway: This block or coprocessor is responsible for performing most of the gateway's electronic control unit (ECU) actions, from TSN standardization to filtering and regulatory actions, frame generation or frame encapsulation / aggregation, and gatewaying.

[0108] Egress queuing: The FIFO memory is used as a buffer between the filtering and supervisory level and the next processing level. From an architectural perspective, this queue supports the creation of two different clock domains or processing levels operating at different speeds, one clock domain or processing level for writing and the other clock domain or processing level for reading.

[0109] Traffic shaping: This block or coprocessor is responsible for arbitrating outgoing frames according to different strategies or priorities (such as time-aware shaping or credit-based shaping).

[0110] At the architectural level, all these functional blocks or coprocessors consist of the same type of input / output interfaces. This feature brings great flexibility to the system configuration, as some of these components can be added or removed by interconnecting the preceding and following blocks in a connection / removal chain, which does not affect or minimizes the integration effort when modifying certain geometric or functional aspects of the automotive gateway electronic control unit (ECU) for scalability.

[0111] Furthermore, to standardize computation across different internal levels of the automotive gateway electronic control unit (ECU), the embodiments provide a new gateway processing protocol through the definition of commands or instructions. The command format is based on a control frame, which consists of instruction fields or metadata distributed across a header, payload, and trailer, moving from a coarse-grained building block to the next building block in the data path. The header gathers global information about the command, while the payload references specific parameters relevant to each processing level. Finally, the trailer of the command frame provides integrity verification of the frame through checksum calculation.

[0112] Internal control frames are processed via a control bus, which transfers data in parallel and synchronously with each network or data frame through different modular processing levels of the gateway. The command conforms to a new internal gateway processing protocol, which... Figure 3 The data fields are defined using the following terms shown below.

[0113] like Figure 3 As shown, the instruction frame 300 associated with the data link layer frame includes an information field, which includes metadata of the data link layer frame. The information field includes at least one of the following: port number 301, network type 303, ingress frame timestamp 305, frame length 307, frame priority 309, number of matching rules, match number of matching rules 313, one or more commands, command length 315, one or more command parameters 317a-317c, and command checksum 319.

[0114] In summary, embodiments of the present invention achieve: an apparatus and method that aims to construct an automotive gateway electronic control unit (ECU) based on hardware / software co-design, driven by a set of standardized and predefined but parameterizable / configurable coarse-grained functional building blocks to leverage hardware parallelism and pipelined strategies; a novel system architecture that aims to decompose network products (from switches to routers to gateways) and their functional blocks into devices that can be implemented in System-on-Chip (SoC) and Field-Programmable Gate Array (FPGA) devices; and a novel design methodology that can simultaneously meet / balance a broad set of network requirements and network disciplines, primarily functional safety, network security, and time-sensitive networking (TSN).

[0115] Furthermore, embodiments of the present invention provide a new set of building blocks for constructing Lego-like network systems, wherein each building block can synthesize one or more functions: from data encryption / decryption to data integrity verification (CRC), to TSN (802.1AS, 802.Qci, 802.Qbv, 802.1CB), to rule-based filtering, firewalls, and network intrusion detection systems (NIDS), to signaling or PDU gateways, transport protocol packet encapsulation and aggregation (such as IEEE 1722), etc.

[0116] In this regard, each coarse-grained building block has a set of configurable aspects (e.g., the number of ingress / egress ports, queue memory geometry and size, bus width, pipeline stages, operating clock frequency, etc.), each of which is developed in silicon, is configurable, and can be instantiated in an on-chip system device to form a communication gateway unit. Through a fully automated process, embodiments of the invention support a full-featured communication gateway unit by selecting and interconnecting different functional blocks to form control and data paths, wherein these control and data paths are configured with selected configurable features and supported protocols / functions consistent with Software-Defined Networking (SDN) architectures. Each processing stage (from ingress to egress) of the gateway device's complete data path is configurable.

[0117] As described above, embodiments of the present invention provide a gateway architecture designed to leverage hardware parallelism and pipeline strategies based on sequential and ultra-fast ingress-to-egress data paths.

[0118] Figure 4This is a schematic diagram of the gateway portion of an exemplary network device 101, which is shown as an automotive gateway electronic control unit (ECU), according to an embodiment. In this embodiment, the data processing path is implemented in parallel and / or pipelined between the ingress and egress ports.

[0119] like Figure 4 As shown in the detailed view, network device 101 includes a central processing unit 103, one or more crossbar switches 403a-403b, and multiple coprocessors, including: intermediate queuing coprocessor 117a, intermediate local queuing coprocessor 401, gateway coprocessor 119, and egress queuing coprocessor 121a.

[0120] According to one embodiment, in order to cache data frames at different levels of the data processing path, the intermediate queuing coprocessor 117a, the intermediate local queuing coprocessor 401, and the exit queuing coprocessor 121a include at least memories 411a-411h, such as FIFO memories for caching data frames.

[0121] In one embodiment, the central processing unit 103 is used to communicate with multiple coprocessors to implement control paths that can be used to exchange instruction frames. Furthermore, each data frame moving within the network device 101 is processed by multiple coprocessors of the data plane 421, while its associated instruction frames are processed simultaneously in parallel by the control plane 423. Instruction frames move from one coprocessor level to the next, synchronized with the back-and-forth movement of their associated data link layer frames.

[0122] There is a wide range of processing tasks at the filtering and oversight levels, as well as at the gateway level. All of these processing tasks, allocated to each of these coprocessors, can be processed in parallel and / or pipelined.

[0123] like Figure 4 As shown, there is a set of functional blocks (task #1...task #N) 413a-413c, which can be interconnected in parallel or pipelined manner according to the processing of the internal crossbar switches 403a-403b. In one embodiment, for example, a feedback path or closed-loop connection from the gateway output to the gateway input for observing the output (o2) of task #2 413b can be re-injected into the intermediate local queue coprocessor for processing again in task #2 or task #N.

[0124] In one embodiment, in each processing level, instruction frames are generated and moved from the in port to the out port in sync with each data frame. This is how each function block is instructed about the processing tasks that need to be performed for each particular data frame.

[0125] In addition to direct ingress-to-egress processing, network device 101 also supports, for example, Figure 5 and Figure 6 The iterations of the different processing levels shown are intended to leverage and optimize the reuse of the hardware coprocessor when possible and / or necessary.

[0126] Figure 5 and Figure 6 An exemplary network device 101, purportedly an automotive gateway electronic control unit (ECU), is shown according to an embodiment, wherein a closed-loop data path extends from a traffic shaping stage 123 (output) to an ingress queuing stage (input), such as... Figure 5 As shown, the closed-loop data path runs from gateway level 119 (output) to the inlet queuing level and the outlet queuing level (input), as follows: Figure 6 As shown.

[0127] like Figure 2 As shown, the data frames provided by the flow shaping coprocessor 123 are forwarded to the egress port, and / or returned to the intermediate queuing coprocessor, and / or returned to the ingress queuing coprocessor.

[0128] like Figure 2 As shown, data frames provided by gateway coprocessor 119 are forwarded to the egress queuing coprocessor, and / or returned to the intermediate queuing coprocessor, and / or returned to the ingress queuing coprocessor.

[0129] The above embodiments support further processing of the resulting gateway frames in additional processing tasks assigned to the filtering and policing level 115a, the gateway level 119, or the traffic shaping level 123. This iterative process exists because some ingress frames may require more than one action to be performed on them. This closed-loop architecture supports the deployment of pipelined strategies across these blocks and their internal deployment through different hardware functions or tasks assigned to these blocks.

[0130] Figure 7This is a flowchart of a method 700 for providing a network device for exchanging, routing, and / or gatewaying data between different subnets of a communication network. The method 700 includes the following steps: Step 701, providing a central processing unit; Step 703, providing one or more data ingress ports and one or more data egress ports for exchanging data with another network device in the communication network; Step 705, providing a plurality of coprocessors, wherein the plurality of coprocessors includes one or more frame normalization coprocessors, one or more ingress queuing coprocessors, one or more filtering and regulatory coprocessors, one or more intermediate queuing coprocessors, at least one gateway coprocessor, one or more egress queuing coprocessors, and at least one traffic shaping coprocessor, wherein the central processing unit is responsible for configuring and controlling the one or more data ingress ports, the one or more data egress ports, and the plurality of coprocessors to implement one or more data processing paths in parallel and / or pipelined between the one or more ingress ports and the one or more egress ports.

[0131] Those skilled in the art will understand that the “blocks” (“units”) in various figures (methods and apparatuses) represent or describe the functionality of embodiments of the invention (and are not necessarily individual “units” in hardware or software), thereby equivalently describing the functionality or features of apparatus embodiments and method embodiments (unit = step).

[0132] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the described apparatus embodiments are merely exemplary. For example, the unit division is merely a logical functional division, and in actual implementation, it can be other divisions. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not performed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed can be implemented using some interface. Indirect coupling or communication connection between apparatuses or units can be implemented electronically, mechanically, or otherwise.

[0133] The units described as discrete components may or may not be physically separate. The components shown as units may or may not be physical units, and may be located in one location or distributed across multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0134] Furthermore, the functional units in the embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

Claims

1. A network device (101) for exchanging, routing, and / or gatewaying data between different subnets of a communication network (100), characterized in that, The network device (101) includes: Central processing unit (103); One or more data input ports (105a-105c) and one or more data output ports (107a-107d) are used to exchange data with another network device (131) of the communication network (100); Multiple coprocessors (109), wherein the multiple coprocessors (109) include one or more frame normalization coprocessors (111a-111c), one or more inbound queuing coprocessors (113a-113c), one or more filtering and regulatory coprocessors (115a-115c), one or more intermediate queuing coprocessors (117a-117c), at least one gateway coprocessor (119), one or more outbound queuing coprocessors (121a-121d), and at least one traffic shaping coprocessor (123). The central processing unit (103) is adapted to configure and control the one or more data input ports (105a-105c), the one or more data output ports (107a-107d), and the plurality of coprocessors (109) to implement one or more data processing paths in parallel and / or pipelined between the one or more input ports (105a-105c) and the one or more output ports (107a-107d); Each of the one or more frame normalization coprocessors (111a-111c) is used to convert one or more ingress frames of a given network technology into one or more normalized data link layer frames, wherein the normalized data link layer frames are network technology-independent and / or protocol-independent data link layer frames and are constructed as a bit stream including a frame header, a frame payload and a frame trailer. Each of the one or more filtering and monitoring coprocessors (115a-115c) is configured to parse the frame header and / or frame payload of the one or more data link layer frames according to one or more matching rules and / or one or more regular expression searches, and to filter, monitor and classify the one or more data link layer frames according to the one or more matching rules and / or the one or more regular expression searches.

2. The network device (101) according to claim 1, characterized in that, The one or more input ports (105a-105c) and the one or more output ports (107a-107d) are based on heterogeneous network technology, which includes at least one or two of LIN, CAN 2.0, CAN-FD, CAN-XL, FlexRay, 10Base-T1S, 100Base-T1, 100Base-T, 1000Base-T1, 1000Base-T and / or 10GBase-T.

3. The network device (101) according to claim 1 or 2, characterized in that, Each of the one or more frame normalization coprocessors (111a-111c) is configured to convert one or more incoming frames into a bit stream organized by a set of information fields, each of which has a specific length and is encoded with a specific meaning according to a given network technology and / or protocol to which the incoming frame belongs, including LIN, CAN 2.0, CAN-FD, CAN-XL, FlexRay, 10Base-T1S, 100Base-T1, 100Base-T, 1000Base-T1, 1000Base-T, and / or 10GBase-T.

4. The network device (101) according to claim 1 or 2, characterized in that, Each of the one or more ingress queuing coprocessors (113a-113c) includes memory for caching the one or more data link layer frames.

5. The network device according to claim 1, characterized in that, Each of the one or more filtering and monitoring coprocessors (115a-115c) is also used to implement a security firewall and / or network intrusion detection system applied to each of the one or more data link layer frames.

6. The network device (101) according to claim 1, characterized in that, Each of the one or more filtering and regulatory coprocessors (115a-115c) is used to process the frame header and payload of the one or more data link layer frames in parallel mode and / or pipelined mode.

7. The network device (101) according to claim 1, characterized in that, Each of the one or more intermediate queuing coprocessors (117a-117c) includes memory for caching the one or more data link layer frames after filtering.

8. The network device (101) according to claim 7, characterized in that, The at least one gateway coprocessor (119) is also used to perform any related actions associated with any given positive match operation performed by the filtering and monitoring coprocessors (115a-115c) on each data link layer frame, including alarm triggering, frame forwarding, frame routing, frame pass-through switching, frame duplication, frame elimination, frame encryption / decryption, frame compression / decompression, frame encapsulation / decapsulation, frame tunneling, and / or frame aggregation, and / or the at least one gateway coprocessor (119) is used to generate new data link layer frames.

9. The network device (101) according to claim 8, characterized in that, The at least one gateway coprocessor (119) is used to apply one or more gateway operations and / or routing operations and / or switching operations to the filtered one or more data link layer frames in parallel mode and / or pipeline mode.

10. The network device (101) according to claim 8 or 9, characterized in that, Each of the one or more exit queuing coprocessors (121a-121d) includes a memory for caching the one or more data link layer frames provided by the at least one gateway coprocessor (119).

11. The network device (101) according to claim 1 or 2, characterized in that, The at least one traffic shaping coprocessor (123) is used to control the provision of the one or more data link layer frames to the one or more output ports (107a-107d).

12. The network device (101) according to claim 11, characterized in that, The at least one traffic shaping coprocessor (123) is used to perform any frame shaping-related actions on each data link layer frame of each outgoing port, including time-aware shaping operations, credit-based shaping operations, asynchronous traffic shaping operations, cyclic queuing shaping operations, and / or frame preemption operations.

13. The network device (101) according to claim 12, characterized in that, The at least one traffic shaping coprocessor (123) is used to apply one or more traffic shaping operations to the filtered one or more data link layer frames in parallel mode and / or pipeline mode.

14. The network device (101) according to claim 1 or 2, characterized in that, The network device (101) further includes a communication bus, and the central processing unit (103) is used to communicate with the plurality of coprocessors (109) via the communication bus to implement a control path that can be used to exchange instruction frames.

15. The network device (101) according to claim 14, characterized in that, For each of the one or more data link layer frames, the plurality of coprocessors (109) are configured to exchange instruction frames via the communication bus, wherein the instruction frame includes one or more commands for processing the corresponding data link layer frame, and wherein the communication bus is configured to provide the corresponding instruction frame to the corresponding coprocessor synchronously with the corresponding data link layer frame.

16. The network device (101) according to claim 14, characterized in that, Each data link layer frame moving within the network device (101) is processed by the plurality of coprocessors (109) of the data plane, while its associated instruction frame is processed in parallel by the control plane simultaneously, moving from one coprocessor level to the next coprocessor level in synchronization with the back-and-forth movement of its associated data link layer frame.

17. The network device (101) according to claim 16, characterized in that, The control plane of the network device (101) is implemented by the central processing unit (103) and / or finite state machine (FSM) and / or arithmetic logic unit (ALU), implemented in hardware within the one or more coprocessors of the data plane, acting as a distributed controller of the control plane, responsible for executing the instruction frames associated with each data link layer frame moving in the data plane.

18. The network device (101) according to claim 14, characterized in that, Each data link layer frame that moves through the data plane within the plurality of coprocessors has an associated instruction frame that moves through the control plane.

19. The network device (101) according to claim 14, characterized in that, Each instruction frame includes a header, a payload, and a trailer, which are organized in a set of fields and commands to instruct one or more operations to be performed on one or more coprocessors in the data plane.

20. The network device (101) according to claim 14, characterized in that, Each instruction frame associated with a data link layer frame includes an information field that includes metadata of the data link layer frame. The information field includes at least one of the following: port number, network type, ingress frame timestamp, frame length, frame priority, number of matching rules, one or more commands, and one or more command parameters.

21. The network device (101) according to claim 1 or 2, characterized in that, Data link layer frames provided by the one or more filtering and regulatory coprocessors (115a-115c) are forwarded to the one or more intermediate queuing coprocessors (117a-117c) and / or returned to the one or more inbound queuing coprocessors (113a-113c).

22. The network device (101) according to claim 1 or 2, characterized in that, Data link layer frames provided by the at least one gateway coprocessor (119) are forwarded to the one or more egress queuing coprocessors (121a-121d), and / or returned to the one or more intermediate queuing coprocessors (117a-117c), and / or returned to the one or more ingress queuing coprocessors (113a-113c).

23. The network device (101) according to claim 1 or 2, characterized in that, The data link layer frames provided by the at least one traffic shaping coprocessor (123) are forwarded to the one or more outgoing ports (107a-107d), and / or returned to the one or more intermediate queuing coprocessors (117a-117c), and / or returned to the one or more ingoing queuing coprocessors (113a-113c).

24. The network device (101) according to claim 1 or 2, characterized in that, The network device (101) is an automotive gateway electronic control unit.

25. A method (700) for providing a network device (101) for exchanging, routing, and / or gatewaying data between different subnets of a communication network (100), characterized in that, The method (700) includes: Provides a (701) central processing unit; Provide (703) one or more data inlet ports (105a-105c) and one or more data outlet ports (107a-107d) for exchanging data with another network device (131) of the communication network (100); Provided (705) a plurality of coprocessors (109), wherein the plurality of coprocessors (109) include one or more frame normalization coprocessors (111a-111c), one or more ingress queuing coprocessors (113a-113c), one or more filtering and regulatory coprocessors (115a-115c), one or more intermediate queuing coprocessors (117a-117c), at least one gateway coprocessor (119), one or more egress queuing coprocessors (121a-121d), and at least one traffic shaping coprocessor (123). The central processing unit (103) is responsible for configuring and controlling the one or more data input ports (105a-105c), the one or more data output ports (107a-107d), and the plurality of coprocessors (109) to implement one or more data processing paths in parallel and / or pipelined between the one or more input ports (105a-105c) and the one or more output ports (107a-107d); Each of the one or more frame normalization coprocessors (111a-111c) is used to convert one or more ingress frames of a given network technology into one or more normalized data link layer frames, wherein the normalized data link layer frames are network technology-independent and / or protocol-independent data link layer frames and are constructed as a bit stream including a frame header, a frame payload and a frame trailer. Each of the one or more filtering and monitoring coprocessors (115a-115c) is configured to parse the frame header and / or frame payload of the one or more data link layer frames according to one or more matching rules and / or one or more regular expression searches, and to filter, monitor and classify the one or more data link layer frames according to the one or more matching rules and / or the one or more regular expression searches.