Multi-protocol gateway

The hardware-based connection gateway efficiently routes data frames across diverse protocols and signal types, addressing the challenges of complex communication systems by providing faster processing and a stable architecture.

WO2026046567A1PCT designated stage Publication Date: 2026-03-05METAVONICS
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
PCT/EP2025/069266
Authority / Receiving Office
WO · WO
Patent Type
Applications
Current Assignee / Owner
Priority Date
2024-08-30
Filing Date
2025-07-07
Publication Date
2026-03-05

AI Technical Summary

Technical Problem

Existing communication systems face challenges in optimizing connection topologies and managing diverse protocols, leading to significant management complexity, weight issues, and performance limitations in applications like aeronautics and consumer electronics.

Method used

A hardware-based connection gateway implemented as an instructionless circuit with data frame management modules and a routing engine, capable of handling multiple protocols and signal types, including analog and digital signals, without software control, to efficiently route data frames across different communication protocols.

Benefits of technology

The solution provides faster processing and a more stable architecture by enabling efficient switching between various protocols and signal types, reducing the need for software management and minimizing hardware complexity.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure EP2025069266_05032026_PF_FP_ABST
    Figure EP2025069266_05032026_PF_FP_ABST
Patent Text Reader

Abstract

Disclosed is a connection gateway between a first device and a second device, the gateway being in the form of an instructionless circuit and comprising: - a first connection port configured to - extract useful payload data from a received incoming frame, - extract a routing identification from said incoming frame, - a routing engine connecting said first connection port and a second connection port, and configured to - determine, from said routing identification, said second connection communication port as destination port, - transmit said payload data with said routing identification, and - said second connection port being configured to - determine, from said identification, send frame parameters, - insert said payload data into a send frame depending on said parameters, said management module and said routing engine being applied in a layer higher than a transport layer.
Need to check novelty before this filing date? Find Prior Art

Description

Description Title of the invention: Multi-protocol gateway technical field

[0001] The present invention relates to the switching of data packets in communication networks. It relates in particular to the communication of data packets exchanged according to different communication protocols.

[0002] The invention has applications in all fields using complex communication systems involving communicating devices of different types and using non-uniform communication modes. Technological background

[0003] In the field of complex electronic systems, it is sometimes necessary to establish communication between the elements (or communicating devices) of that system. It is also sometimes necessary to establish communication between the systems themselves. Many problems can arise in doing so.

[0004] A primary challenge is optimizing the connection topology between elements and systems (e.g., electrical wiring) to establish communication when needed. For example, in a set of systems, each containing N elements, if the connection topology is based on a simplex point-to-point bus and each element needs to communicate with all other elements, it is necessary to draw Cables or electrical wires. If we consider a hundred or so elements, we need to manage 2^2 - 1000 connections. This number implies significant management complexity (energy, failures, etc.). They introduce a volume and weight that can be detrimental in certain applications. This is the case in aeronautical applications.

[0005] A second problem is the variety of possible connections. For example, to manage connections, large computer systems may use an Ethernet connection. They may also use a multi-node bus such as CAN (Controller Area Network). Simple sensors or actuators, for instance, have only one interface, which can be either analog or digital. For example, it is not possible to place an Ethernet interface on a temperature sensor since it is entirely mechanical. This means that the computer system using this sensor must have an analog interface.

[0006] Furthermore, various problems can combine, as illustrated by the two examples given above. For instance, in an aircraft, if the sensor that the computer system uses via an analog interface is located on the opposite side of the aircraft, the impact of the cabling weight can be significant.

[0007] Various solutions can be found to solve these problems.

[0008] One initial solution is network communication architecture.

[0009] This type of architecture can be used in aeronautics as well as in consumer electronics. As illustrated in [Fig. 1], these are systems 100 using switches 102 capable of establishing communication between elements (or communicating devices) 101, 103 with a limited need for connections (such as wires or electrical cables). The switch can connect all the elements to each other. Communication can occur between elements 101 and 103, but it can also occur between elements 101, or between elements 103. Each element 101 is connected to the switch 102 by means of a connection port 104. Each element 103 is connected to the switch 102 by means of a connection port 105. The switch is responsible for directing the data received on each incoming port of the communication to a relevant outgoing port to route the data from the correct sender to the correct receiver.Generally, to ensure all the required functions and for timing performance reasons, the switch design is carried out in FPGA (acronym for the abbreviation of "Field-programmable gate array" in Anglo-Saxon terminology) or ASIC (acronym for the English application-specific integrated circuit).

[0010] One drawback of the network approach is that it is limited to a single type of protocol (Ethernet, for example). This approach does not allow for managing access to analog, digital, or multi-node buses such as CAN or others.

[0011] A second solution is the use of data concentrators.

[0012] As illustrated in [Fig. 2], this type of architecture 200 also establishes a link between different elements, but this time with different protocols. The hub 203 connects various elements 201, 202 to each other. For example, these are computer systems 201 that can communicate with each other or with various elements 202 such as sensors, actuators or others. The computer systems are connected to the hub 203 by means of various Ethernet 204 or CAN 205, 206 connection ports. The elements 202 are in turn connected to the hub 203 by means of connection ports handling analog or digital signals 207. The data hub 203 is capable of establishing communication between each computer system, which use different protocols (Ethernet, CAN, A664, A825, A429, RS422, ISOSPI, 1553, Modbus, or other) and of allowing each computer system to read data from the elements 202 or to activate them. Data hubs are generally software-controlled. The connection ports are managed by drivers communicating with the software that controls the hub. The software reads and / or writes data from and / or into the drivers. Following the OSI (Open Systems Interconnection) model, the layers Physical and data link layers are typically implemented by hardware, while network and transport layers can be implemented by hardware or software, depending on the architecture.

[0013] The main drawbacks of this approach are performance and architectural stability. Regarding performance, since the primary data concentration function is implemented by software, the typical transfer time between the input and output ports (i.e., the latency between when a data frame is received at the input port and when the processed frame is sent to the output port) is a minimum of approximately tens of milliseconds. It is possible to reduce this delay, but with very low bandwidth performance (the amount of data transferred from input to output). Regarding the architecture, each time a new connection port is added or removed, especially if that new port is of a new type, the impact on the architecture is significant.This has a significant impact on the low-level software architecture (adding or removing drivers), which is where making changes is most complex. It also has a significant impact on the hardware board architecture, as each driver must have direct access to the hardware via a dedicated bus (such as PCIe, AXI, PC, SPI, or another).

[0014] Therefore, there is a need to improve interconnection functions in communication systems.

[0015] The present invention falls within this framework. Summary of the invention

[0016] According to a first aspect, the invention relates to a connection gateway between a first communicating device and a second communicating device, in a communication between said communicating devices, said gateway being implemented in the form of an instructionless circuit and comprising:

[0017] a first data frame management module configured to receive data frames from said first communicating device, and to

[0018] extract the payload from a received incoming frame,

[0019] extract a routing identifier from said incoming frame,

[0020] a routing engine linking said first data frame management module and a second data frame management module configured to transmit data frames from said second communicating device, and for

[0021] to determine, based on said routing identification, said second data frame management module as the destination data frame management module,

[0022] transmit said payload with said routing identification, and

[0023] said second data frame management module, configured for

[0024] to determine, based on said identification, the parameters for the sending frame,

[0025] insert said payload into a transmit frame according to said parameters,

[0026] in which said data frame management module and said routing engine intervene on said input and output frames at a layer higher than a transport layer of said communication.

[0027] For example, the second data frame management module includes:

[0028] a plurality of physical connection ports for analog and / or digital signals for connection with said second communicating device, and

[0029] means to distribute said payload over said plurality of physical connection ports.

[0030] For example, the first data frame management module includes:

[0031] a plurality of physical connection ports for analog and / or digital signals for connection with said first communicating device, and

[0032] means to associate ports of said plurality of physical connection ports to respective sub-parts of said payload.

[0033] According to embodiments, at least one of said first and second data frame management modules is configured for connection to a processor bus configured for direct connection to an external processor (900), said data frame management module being configured to interface with a software connection driver via application connection interfaces.

[0034] For example, in which the first and second data frame management modules operate according to two different protocols.

[0035] According to some implementations, the gateway includes at least three data frame management modules and is configured to transfer a payload of the same frame from an input data frame management module to two output data frame management modules.

[0036] For example, at least one data frame management module operates according to one of the following protocols: CAN Ethernet, A664, A825, A429, RS422, ISOSPI, 1553, Modbus.

[0037] According to some designs, the gateway is implemented in an integrated circuit of the type ASIC, FPGA.

[0038] According to a second aspect, the invention relates to a system comprising:

[0039] a gateway according to the first aspect, and

[0040] at least two communicating devices connected to said gateway on data frame management modules.

[0041] For example, the system also includes a control unit connected to the gateway via a processor port through a processor bus.

[0042] According to some implementations, the system also includes an electronic board with external electronic blocks for connecting said communicating devices to the data frame management module of said gateway. Brief description of the figures

[0043] Other features and advantages of the invention will become apparent from the following detailed description, which is provided by way of non-limiting example, and the accompanying figures, including:

[0044] [Fig. 1] illustrates a switch according to the prior art,

[0045] [Fig.2] illustrates a concentrator according to the prior art,

[0046] [Fig.3] illustrates a footbridge according to different embodiments,

[0047] [Fig.4] illustrates data transmission according to different embodiments,

[0048] [Fig. 5] illustrates the conversion of the payload in an Ethernet frame to the payload of a CAN frame according to different embodiments,

[0049] [Fig.6] illustrates the control of a routing engine according to different embodiments,

[0050] [Fig.7] illustrates the use of pseudo-ports according to different embodiments,

[0051] [Fig.8] illustrates data transmission via a pseudo-port according to various embodiments,

[0052] [Fig.9] illustrates a footbridge according to embodiments. Detailed description of the invention

[0053] As will become apparent from reading this description, the embodiments of the invention offer the advantages of the hardware implementation used in network switches combined with the flexibility to connect different protocols.

[0054] The embodiments of the invention allow for the connection of various types of communicating elements using different protocols, the connection of these elements (or communicating devices) via analog or digital signals, the connection of computer systems, and the routing of incoming data from input ports to output ports. This makes it possible to achieve faster processing and a more stable architecture.

[0055] An implementation context for embodiments of the invention is first described with reference to [Fig. 3]. This figure schematically represents a system 300 with a gateway 301 which allows data communication between elements 312, 311, 302, 303, 313, 314, 315. For example, elements 312, 311, 302 are computer systems which can communicate with each other or with elements 303, 313, 314, 315, for example sensors, actuators, or, on the other hand.

[0056] The gateway 301 includes data frame management modules whose function is to support the various protocols used by the different communicating elements. Each element is connected to the gateway via a data frame management module. These modules extract the payload from incoming data frames and insert it into outgoing data frames. The gateway also includes a routing engine 304 between the various input and output data frame management modules. This routing engine directs the payload from an input data frame management module to the appropriate output data frame management module to establish communication between the elements connected to the data frame management modules exchanging this data.Unlike previous technology, the routing engine is not software-controlled. It is implemented entirely in hardware. The gateway is not implemented in software with instructions executed by a processor. For example, the gateway is implemented as an FPGA (Field-Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit). These are circuits without instructions.

[0057] To allow direct connections to buses for external processors, the gateway includes a dedicated 308 data frame management module.

[0058] The payload is the data that the elements actually intend to exchange. It is the data that carries the actual information. In information systems, the payload is accompanied by data that does not carry the exchanged information but is useful for its transmission from a sender to a receiver within the communication system. In the OSI model, the payload is exchanged at the interface between the transport layer and the session layer. For example, Figure 5 illustrates the transfer of payload 505 in an Ethernet 500 frame to payload 510 in a CAN 501 frame. The payloads are the same (the data contained in 505 and 510 is identical), as this is the message that the system elements intend to exchange. However, they are accompanied by different data depending on the frame being considered.In Ethernet frames, the payload is preceded by various headers mandated by the protocol: an Ethernet 502 header, an IP 503 header, and a UDP 504 header. The data contained in these headers ensures the correct routing of the payload. At the end of the frame, there is FCS 506 data, which verifies the frame's validity. This sequence of bits checks if the frame has been altered during its transmission. The CAN frame, on the other hand, is constructed using a similar scheme but with different data. The payload. is preceded by several data fields. A first data field, 507 (SOF), identifies the start of the frame. A second arbitration field, 508, identifies the data carried by the frame. A third control field, 509, indicates the payload size and whether the frame is of a standard or extended type. Following the payload are an error-checking code, 511, to guarantee frame integrity, and an end-of-frame indicator, 512. As can be seen, for a payload exchange, it is necessary to extract it from the initial frame and include it in the arrival frame so that the two elements exchanging this payload can find it at the expected location within the frame. Indeed, each element using a different protocol (Ethernet or CAN in this example) will not look for the payload in the same location.The headers and data following the payload are not the same and do not have the same sizes and meaning.

[0059] To determine the payload route within the switch, the data accompanying the payload data in an incoming frame is used. This includes, for example, the destination IP address or UDP port in an Ethernet frame, or, for example, a data identifier (arbitration field) in a CAN frame.

[0060] As illustrated in [Fig. 4], routing parameters are extracted by the input data frame management modules from the input data frames and are used by the routing engine to determine the forwarding route. For example, the payload contained in a CAN frame with the identifier 0x12345678 must be routed to the data frame management modules x, y, and z. The output frames containing the payload are generated by the data frame management modules using parameters determined by the routing engine.

[0061] Using the system from [Fig.3], [Fig.4] illustrates the transmission by element 311 of a frame to elements 312 and 302. Element 312 is connected to the gateway via an Ethernet data frame management module 305 while elements 311 and 302 are respectively connected to the gateway via CAN data frame management modules 306 and 307.

[0062] In the first step (401), element 311 sends a frame (402) with a given CAN identifier. The CAN data frame management module (306) receives the frame and extracts the payload in step 403 and the identifier in step 404. This identifier, along with the payload, is then sent in step 405 to the routing engine (304). A route is then determined in step 406, based on the identifier. This route can be determined in several ways. For example, the CAN frame management module (306) determines the associated route itself. to the CAN identifier. It then simply transmits an identifier for this route to the routing engine. In another example, the data frame management module transmits the CAN identifier itself to the routing engine. The routing engine then retrieves the identifier of the route associated with the CAN identifier. In this example, it is determined that the frame payload, as identified by the identifier, must be sent back via the data frame management modules 305 (Ethernet) and 307 (CAN). The transmission then occurs during step 407, and each data frame management module receives the payload and a corresponding route identifier in messages 408 and 412, respectively.

[0063] The data frame management module 307 receives message 408 and, based on the route identification, determines the frame parameters to use to generate the output frame containing the payload. Output frame 411 is generated in step 409. Once generated, it is transmitted in step 410 to element 302.

[0064] The Ethernet data frame management module 305 receives message 412 and, based on the route identification, determines the frame parameters to use to generate the output frame containing the payload. Output frame 415 is generated in step 413. Once generated, it is transmitted in step 414 to element 312. The transmitted frame contains the necessary parameters such as the MAC address, IP address, and other relevant information.

[0065] As can be seen, the gateway according to the invention allows switching from one protocol to another in a very efficient manner.

[0066] As previously mentioned, the gateway can include a dedicated processor data frame management module for direct connections to processor buses implementing software. This allows the hardware-implemented gateway to have a direct connection to external software components. This architecture is illustrated in Figure 6. The controller 600, which includes, for example, a processor, implements software that is interfaced by application connection interfaces 602, which connect it to a driver 601, itself connected to the data frame management module 603 of the routing engine 604. The application connection interfaces are similar to UDP ports (e.g., "sockets" in the Windows® environment).Thus, a payload from the 604 routing engine, through the 603 data frame management module and the 601 driver, is provided as input to the software controller via a dedicated application connection interface. The payload from the 604 routing engine originates from a different data frame management module. The routing mechanisms are similar to those described previously with reference to [Fig. 5], and illustrated by the associated example described with reference to Figures 3 and 4. The frame format. The frame generated by the data frame management module 603 is specific to the driver 601 and can take various forms, including a complex, multi-step protocol exchange of the request / response type. This generated frame allows the driver 601 to determine on which application connection interface 602 the frame should be made available. Conversely, an outgoing payload is provided by the software controller 600 via another application connection interface, passes through the driver 601 and the data frame management module 603 to be made available to the routing engine 604. The routing mechanisms implemented subsequently are similar to the mechanisms described previously with reference to [Fig. 5], and illustrated by the associated example described with reference to Figures 3 and 4. The format of the frame generated by the driver 601 is specific to it and can take various forms, including a complex, multi-step protocol exchange of the request / response type.This frame is generated based on the application connection interface used by the 600 controller and contains the information needed by the 603 data frame management module to determine the route.

[0067] Thus, the gateway's overall architecture is very stable. For any input or output payload, there is only one software controller. The routing engine requires only a single 601 driver. The architecture is also simplified around the controller since only one data bus is needed to access the routing engine. The gateway can interface with any software, not just data hub software like the previous generation. For example, the gateway can interface with flight control software, human-machine interfaces, and more.

[0068] Regarding the handling of raw analog and digital signals, as illustrated in [Fig. 7], a 701 pseudo data frame management module can be connected between the 700 routing engine and the physical connection ports to the 702 analog or digital signals. A "pseudo data frame management module" is a data frame management module for physical connections to digital or analog signals. This type of data frame management module has multiple physical connections for handling data. Therefore, a pseudo data frame management module is a data frame management module with multiple physical connections.Such a pseudo frame management module can work in both directions: one direction to distribute the payload over several physical connections and a second direction to concentrate received physical signals on physical connections to generate a data frame with a payload.

[0069] As illustrated in [Fig. 8], when receiving an 800 frame for writing on physical connection ports 806, the 803 payload of the 800 frame (by For example, an Ethernet frame is provided via an input data frame management module (e.g., an Ethernet data frame management module) 801 to a routing engine 802. The payload is then provided by the routing engine to the pseudo-data frame management module 804, which divides it into sub-parts 805. Each sub-part is then transmitted via the physical connection ports 806. The physical connection ports are thus associated with sub-parts of the payload. Conversely, in the case of transmitting the values ​​of signals received on the physical connection ports 806 into the frame 800, the values ​​of these signals are read by the data frame management module 804, which constructs a payload 805 that is provided to the routing engine 802 along with the routing information.Subsequently the 802 routing engine makes the payload available to the input data frame management module (e.g. an Ethernet data frame management module) 801 which generates the 800 frame (e.g. an Ethernet frame).

[0070] These implementations allow data to be switched according to a given protocol to digital or analog signals. The reverse is also possible. All of this can be done efficiently, without the need to implement specific software solutions for the switching itself.

[0071] Figure 9 illustrates a general embodiment of the invention.

[0072] A gateway 904, for example, is implemented as a programmable circuit such as an EPGA (Field Programmable Gate Array). It includes a processor data frame management module 905 connected to a routing engine 914, as previously described. The processor data frame management module allows connection to a control unit 900 via an electronic bus 903. The control unit includes means for implementing a driver 901 and software 902 that communicate with each other via application interfaces, as previously described.

[0073] Bus 903 enables communication between driver 901 and processor data frame management module 905. In addition, the gateway includes a set of data frame management modules that manage communication buses (which carry payloads) 906, 907 or in the form of pseudo data frame management modules 908. Each data frame management module, with the exception of processor data frame management module 905, has a respective connection with an electronic block 909, 910, 911, of an external electronic card 915 (external to the gateway). Each electronic block has physical connection ports for bus connections (912) or for digital / analog signals (913). The interface (916) between buses (906, 907) and the electronic board (915) can be of the GPIO (General Purpose Input / Output) type or of a more specific type such as For example, RGMI (reduced gigabit media-independent) or SGMI (serial gigabit media-independent interface). Interface 917 between pseudo-port 908 and the card can also be of type GPIO or another type such as SPI (Serial Peripheral Interface) or I-B buses. 2 C (English acronym for "Inter-Integrated Circuit").

[0074] Thus, as can be seen in this embodiment, the control unit driver only has one interface to manage, that with the processor data frame management module, and does not have to manage all the interfaces with the electronic board.

[0075] In general, the embodiments of the invention offer numerous advantages not combined in prior art solutions (conventional gateways or data hubs). These embodiments are implemented in hardware, without an instruction set. Therefore, they do not require a processor for their implementation. This results in performance gains, particularly in terms of execution speed, since data processing can be parallelized and is not clocked as is necessary for a processor executing instructions sequentially. A conventional data hub, implemented in software, would require very large computing resources to match the performance of a gateway using the embodiments of the invention. These computing resources would require several processors operating in parallel.

[0076] According to one specific embodiment of the invention, the processing performed by the gateway is carried out beyond the network layer. However, according to the prior art, all processing performed by data concentrators beyond this layer is done by software and not in hardware. Yet, as mentioned above, the embodiments of the invention are implemented without instruction sets, therefore in hardware, without software.

[0077] The OSI model (an acronym for "Open Systems Interconnection") comprises several layers: the "physical" layer, responsible for the actual transmission of signals; the "data link" layer, which manages communication between two connected machines; the "network" layer, which manages hop-by-hop communication; the "transport" layer, which manages end-to-end communication between processes; the "session" layer, which manages the synchronization of data exchanges; the "presentation" layer, responsible for encoding application data; and the "application" layer, which is the access point to network services. Generally, in data hubs, only the physical and data link layers are implemented in hardware. The other layers are implemented in software.

[0078] The architecture of the embodiments of the invention makes it possible to go further and to carry out the steps implemented for communication between elements, in particular the extraction of the payload, in a material way, at the level of higher layers, for example at the level of the network layer, the transport layer or the higher layers.

[0079] The present invention has been described and illustrated in this detailed description with reference to the accompanying figures. However, the present invention is not limited to the embodiments shown. Other variations, configurations, and combinations of features can be deduced and implemented by a person skilled in the art upon reading this description and the accompanying figures.

[0080] To meet specific needs, a person competent in the field of the invention may apply modifications or adaptations.

[0081] In the claims, the term “include” does not exclude other elements or steps. The various features presented and / or claimed may be advantageously combined. Their presence in the description or in different dependent claims does not preclude the possibility of combining them. Reference symbols shall not be construed as limiting the scope of the invention.

Claims

Demands

1. A connection gateway (301) between a first communicating device (311) and a second communicating device (312, 302), in a communication between said communicating devices (301, 311), said gateway being implemented in the form of an instructionless circuit and comprising: - a first data frame management module (306) configured to receive data frames from said first communicating device (311), and to • extract (403) the payload from a received incoming frame, • extract (404) a routing identifier from said incoming frame, - a routing engine (304) linking said first data frame management module (306) and a second data frame management module (307, 305) configured to transmit data frames from said second communicating device (312, 302), and for • determine (406), from said routing identification, said second data frame management module (307, 305) as the destination data frame management module, • transmit (407) said payload with said routing identification, and - said second data frame management module (307, 305), configured for • determine (409, 413), from said identification, the transmit frame parameters, • insert (410, 414) said payload into a transmit frame according to said parameters, in which said data frame management module and said routing engine intervene on said input and transmit frames at a layer higher than a transport layer of said communication.

2. Gateway according to claim 1, wherein said second data frame management module comprises: - a plurality of physical connection ports to analog and / or digital signals (702, 806) for connection with said second communicating device (303), and - means to distribute said payload over said plurality of physical connection ports.

3. Gateway according to any one of the preceding claims, wherein said first data frame management module comprises: - a plurality of physical connection ports for analog and / or digital signals for connection with said first communicating device, and - means to associate ports of said plurality of physical connection ports to respective sub-parts of said payload.

4. Gateway according to any one of the preceding claims, wherein at least one of said first and second data frame management modules is configured for connection (308, 603) to a processor bus (903) configured for direct connection to an external processor (900), said data frame management module being configured to interface with a connection driver (601, 901) of software (600, 902) via application connection interfaces (602).

5. Gateway according to any one of the preceding claims, wherein the first and second data frame management modules operate according to two different protocols.

6. Gateway according to any one of the preceding claims, comprising at least three data frame management modules and configured to transfer a payload of the same frame from an input data frame management module to two output data frame management modules.

7. Gateway according to any one of the preceding claims, wherein at least one data frame management module operates according to one of the following protocols: Ethernet CAN, A664, A825, A429, RS422, ISOSPI, 1553, Modbus.

8. Gateway according to any one of the preceding claims implemented in an integrated circuit of type among AS IC, FPGA.

9. System comprising: a gateway according to one of the preceding claims, and at least two communicating devices connected to said gateway on data frame management modules.

10. System according to claim 9, further comprising a control unit (900) connected to the gateway via a processor port via a processor bus.

11. System according to any one of claims 9 and 10, further comprising an electronic card having external electronic blocks for connecting said communicating devices to the data frame management modules of said gateway.

Citation Information

Patent Citations

  • A multi-protocol gateway device for an information transmission platform

    CN107395497B

  • Protocol conversion configuration method and system of avionics data interface device

    CN116634036A

  • Multi-protocol Internet of Things gateway device based on FPGA

    CN210129874U

  • Multi-protocol conversion gateway

    CN210780852U