WO2024232600A1 - Method and device for ultra-low latency packet scheduling based on hardware-implemented mode - Google Patents

Abstract

A device for ultra-low latency packet scheduling based on a hardware-implemented mode according to an embodiment of the present invention may comprise: an input interface module that receives packet streams from a plurality of input devices; a packet processing module that processes the packet streams received from the input interface module; a mode management module that changes and sets a mode related to the packet processing of the packet processing module in real time and requests that the packet processing mode changed and set in real time be propagated to other switching devices; an output determination module that sets and outputs the priority of the packets according to the packet processing mode changed and set in real time by the mode management module; an output queue module for storing the packets which had the priority set by the output determination module; a mode propagation module that propagates the corresponding mode to the other switching devices in response to the request from the mode management module; and an output interface module that outputs the packets stored in the output queue module to the corresponding output devices according to the priority.

Description

Mode-based ultra-low-latency packet scheduling device and method for hardware implementation

The present invention relates to a packet scheduling device and method, and more particularly, to a mode-based ultra-low latency (ULL) packet scheduling device and method, and more particularly, to a hardware-implemented mode-based ultra-low latency packet scheduling device and method.

The present invention was supported by the group research support of the Ministry of Science and ICT (Project Unique Number: 1711137721, Project Number: 2021R1A4A1032252, Research Project Title: Embedded Cluster Computing and Deep Learning Lightweight Technology for Low-Cost, High-Reliability Autonomous Vehicles, Project Management Agency: National Research Foundation of Korea, Project Execution Agency: Soongsil University Industry-Academic Cooperation Foundation, Research Period: 2021.06.01 ~ 2024.02.29) and the Information and Communication Broadcasting Innovation Talent Development (Project Unique Number: 1711174068, Project Number: IITP-2024-RS-2022-00156360, Research Project Title: Regional Intelligence Innovation Talent Development, Project Management Agency: Information and Communication Planning and Evaluation Institute, Project Execution Agency: Soongsil University Industry-Academic Cooperation Foundation, Research Period: 2022.07.01 ~ This is derived from research conducted as part of the 2029.12.31). Meanwhile, there is no property interest of the Korean government in any aspect of the present invention.

Recently, as the technology of electric vehicles and autonomous vehicles is developing, numerous sensors are being installed in vehicles, and various electronic control processors and driving processes are increasing. These vehicles can be considered as a single electronic component, and the signal exchange between nodes within the vehicle is also rapidly increasing. Naturally, the number of network switches connecting nodes within the vehicle is also increasing, and to support this, networks based on Automotive Ethernet are being actively developed and used.

Meanwhile, in the case of autonomous vehicles, numerous sensor signals must be analyzed to make decisions for optimal driving and drive control, and there is a need to respond quickly to emergency situations such as obstacles occurring during driving. Accordingly, network switches must quickly transmit numerous sensor signals and drive signals. However, as the number of network switches and signals increases, signal transmission delay becomes a major challenge. In addition, depending on system conditions such as changes in the vehicle's driving environment, the bandwidth and timing requirements of signals change rapidly, and the signal transmission policy (forwarding rule) also needs to change dynamically.

Existing software-defined networking (SDN) methods can be utilized to manage dynamic signal transmission policies. However, while ultra-low latency (ULL) of at least ㎲ units must be guaranteed within a vehicle, existing SDN methods can cause delays of ms units, which is problematic.

In a software-defined network, a network switch queries a higher-level SDN control device about the signal transmission mode, and the SDN control device then remotely controls the signal transmission mode to control the switching process. In other words, the software-defined network method cannot guarantee ultra-low latency (ULL) switching delay in a vehicle.

Accordingly, a network switching method is required in situations where ultra-low latency switching delay must be guaranteed, such as in autonomous vehicles.

The present invention provides a mode-based ultra-low-latency packet scheduling device and a mode-based ultra-low-latency packet scheduling method implemented in hardware.

In addition, the present invention provides a hardware-implemented mode-based ultra-low latency packet scheduling device and a hardware-implemented mode-based ultra-low latency packet scheduling method, which are configured to perform parallel processing of a packet processing mode change of a network switch based on hardware, thereby enabling ultra-low latency mode change.

In addition, the present invention provides a hardware-implemented mode-based ultra-low-latency packet scheduling device and a hardware-implemented mode-based ultra-low-latency packet scheduling method that can implement a safe and smooth autonomous driving process by being configured to be able to change modes immediately with almost no mode change delay in an emergency situation such as an autonomous vehicle, and that has the effect of enabling efficient network switching with limited resources.

A hardware-implemented mode-based ultra-low-latency packet scheduling device according to one aspect of the disclosed invention may be configured to include an input interface module that receives a packet stream from a plurality of input devices; a packet processing module that processes the packet stream received from the input interface module; a mode management module that changes and sets a packet processing mode in real time based on a processing result of the packet stream by the packet processing module; an output decision module that sets and outputs a packet priority according to the packet processing mode changed in real time by the mode management module; an output queue module that stores packets whose priorities are set by the output decision module; and an output interface module that outputs packets stored in the output queue module to a corresponding output device according to the priorities.

In addition, the packet processing module may be implemented as a logic circuit in an FPGA (field programmable gate array) on the NIC (network interface controller) card, and may be configured to simultaneously and in parallel parse and identify each field header of a packet stream input from the input interface module using a plurality of multiplexers provided in the FPGA.

Additionally, the mode management module may be configured to request propagation of the packet processing mode set to be changed in real time to another switch device.

Additionally, the mode management module may be configured to further include a mode propagation module that propagates the mode to the other switch device at the request of the mode management module.

In addition, it may be configured to further include a control interface module that receives an OpenFlow or similar control message from an SDN (software defined network) control device and inputs it into the mode management module.

Additionally, the mode management module may be configured to operate according to an openflow message received from the SDN control device.

In addition, the packet processing module may be configured to include a lookup table memory in which a lookup table regarding a packet processing mode is stored; a flow behavior monitoring unit that identifies each field header to be parsed by referring to the lookup table stored in the lookup table memory, determines whether the behavior of the corresponding flow violates the current packet processing mode on the lookup table, and, if the determination result is violated, generates a violation message and outputs it in real time to the mode management module.

In addition, the flow behavior monitoring unit may be configured to match each of the parsed field headers with a header of the lookup table, extract overlapping candidate rules among packet processing candidate rules (forwarding rules) specified in each matched header, and determine a packet processing rule corresponding to the current flow processing among the extracted candidate rules.

Additionally, the flow behavior monitoring unit may be configured to determine that a current packet processing mode is violated if the flow generates more messages than the conditions of the current packet processing mode.

를 패킷의 도착 시간을 제한하는 형태의 수학식에 따라 산출하도록 구성될 수 있다.In addition, the above mode management module provides the guide time of the current mode.

can be configured to produce a mathematical expression that limits the arrival time of packets.

에서의

번째 주기적 메시지에 대하여 현재 모드의 가이드 타임(guide time)

를 하기 수학식에 따라 산출하고, [수학식]

여기서,

는 플로우

에서의

번째 메시지의 도착 시간이고,

는 각 주기적 메시지의 릴리스 지터(release jitter)이고,

는 플로우

에서의 현재 모드 주기이고, 상기

번째 메시지의 도착 시간이 상기 가이드 타임보다 작은 경우 해당 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 또는 상기 메시지의 크기가 현재 모드의 크기 조건보다 더 큰 경우 상기 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 긴급 모드의 행동을 나타내는 것으로 판단하는 경우 모드 위반으로 판단하도록 구성될 수 있다.In addition, the above flow behavior monitoring unit,

In

Guide time of the current mode for the th periodic message

It is calculated according to the following mathematical formula, [Mathematical formula]

Here,

is the flow

In

is the arrival time of the second message,

is the release jitter of each periodic message,

is the flow

The current mode cycle is in , and the above

If the arrival time of the th message is less than the guide time, the message is determined to indicate an action in the emergency mode, or if the size of the message is greater than a size condition of the current mode, the message is determined to indicate an action in the emergency mode, and if it is determined to indicate an action in the emergency mode, it can be configured to determine a mode violation.

은 상기 수학식 뿐만 아니라 패킷의 도착 시간을 제한하는 다른 어떠한 형태의 수학식으로 표현 가능할 수 있다.Also, the guide time of the current mode

can be expressed not only by the above mathematical formula but also by any other mathematical formula that limits the arrival time of a packet.

In addition, the mode management module may be configured to include a shadow table memory in which a shadow table corresponding to a packet processing mode is stored; and a mode change handling unit that swaps the shadow table stored in the shadow table memory with a lookup table of the lookup table memory and stores the shadow table as a lookup table in the lookup table memory to change the packet processing mode corresponding to a violation message output in real time from the flow behavior monitoring unit by referring to the shadow table stored in the shadow table memory.

In addition, the mode management module may be configured to include a shadow table memory storing a shadow table including packet processing rules corresponding to packet processing modes; a mode change handling unit that changes the packet processing mode corresponding to a violation message output in real time from the flow behavior monitoring unit by referring to the shadow table stored in the shadow table memory, and swaps the corresponding shadow table stored in the shadow table memory with a lookup table of the lookup table memory for mode change and stores the shadow table as a lookup table in the lookup table memory.

In addition, the mode change handling unit can be configured to, when the flow behavior monitoring unit determines a mode violation, identify a suitable change candidate mode in the flow behavior monitoring unit and change the current packet processing mode to the candidate mode.

Additionally, the output queue module may be configured to include a plurality of priority-based output queues in which packets are stored for each input device.

Additionally, the output interface module may be configured to include a plurality of output interface units that each output packet stored in an output queue of the output queue module to a corresponding output device.

According to another object of the present invention, a hardware-implemented mode-based ultra-low-latency packet scheduling method may be configured to include the steps of: an input interface module provided in a network interface controller (NIC) card receiving a packet stream from a plurality of input devices; a packet processing module implemented in a field programmable gate array (FPGA) on the NIC card processing the packet stream received from the input interface module; a mode management module implemented in the FPGA on the NIC card changing and setting a packet processing mode in real time based on a processing result of the packet stream by the packet processing module; a step of an output decision module implemented in the FPGA on the NIC card setting and outputting a packet priority according to the packet processing mode changed in real time by the mode management module and storing the output in an output queue module on a memory; and a step of an output interface module provided on the NIC card outputting the packets stored in the output queue module to a corresponding output device according to the priorities.

In addition, the step of processing the packet stream input from the input interface module by the packet processing module implemented in the FPGA on the NIC card may be configured to simultaneously and in parallel parse and identify each field header of the packet stream input from the input interface module by using a plurality of multiplexers provided in the FPGA.

Additionally, a mode management module implemented in an FPGA on a NIC card may be configured to request propagation of the packet processing mode set to be changed in real time to other switching devices.

In addition, the mode propagation module provided on the NIC card may be configured to further include a step of propagating the corresponding mode to the other switch device according to a request of the mode management module.

In addition, the step of processing the packet stream input from the input interface module by the packet processing module implemented in the FPGA on the NIC card may be configured to identify each field header being parsed by referring to a lookup table stored in a lookup table memory, determine whether the behavior of the corresponding flow violates the current packet processing mode on the lookup table, and if the determination result is violated, generate a violation message and output it to the mode management module in real time.

를 패킷의 도착 시간을 제한하는 형태의 수학식에 따라 산출하도록 구성될 수 있다.In addition, the step of processing the packet stream input from the input interface module by the packet processing module implemented in the FPGA on the NIC card includes matching each of the parsed field headers with the header of the lookup table, extracting overlapping candidate rules among packet processing candidate rules specified in each matched header, determining a packet processing rule corresponding to the current flow processing among the extracted candidate rules, and determining the guide time of the current mode.

can be configured to produce a mathematical expression that limits the arrival time of packets.

In addition, the step of changing and setting the packet processing mode in real time based on the result of processing the packet stream of the packet processing module by the mode management module implemented in the FPGA on the NIC card may be configured to swap the shadow table stored in the shadow table memory with the lookup table of the lookup table memory and store it as a lookup table in the lookup table memory in order to change the packet processing mode to a packet corresponding to a violation message output in real time from the flow behavior monitoring unit by referring to the shadow table stored in the shadow table memory.

In addition, the step of processing a packet stream input from the input interface module by the packet processing module implemented in the FPGA on the NIC card may be configured to determine that the current packet processing mode is violated if the flow generates more messages than the condition of the current packet processing mode.

에서의

번째 주기적 메시지에 대하여 현재 모드의 가이드 타임(guide time)

를 하기 수학식에 따라 산출하고, [수학식]

여기서,

는 플로우

에서의

번째 메시지의 도착 시간이고,

는 각 주기적 메시지의 릴리스 지터(release jitter)이고,

는 플로우

에서의 현재 모드 주기가 될 수 있다.Additionally, the packet processing module flows

In

Guide time of the current mode for the th periodic message

It is calculated according to the following mathematical formula, [Mathematical formula]

Here,

is the flow

In

is the arrival time of the second message,

is the release jitter of each periodic message,

is the flow

The current mode cycle can be in .

번째 메시지의 도착 시간이 상기 가이드 타임보다 작은 경우 해당 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 상기 메시지의 크기가 현재 모드의 크기 조건보다 더 큰 경우 상기 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 긴급 모드의 행동을 나타내는 것으로 판단하는 경우 모드 위반으로 판단하도록 구성될 수 있다.In addition, the packet processing module is

If the arrival time of the th message is less than the guide time, the message is determined to indicate an action in the emergency mode, if the size of the message is greater than a size condition of the current mode, the message is determined to indicate an action in the emergency mode, and if it is determined to indicate an action in the emergency mode, it can be configured to determine a mode violation.

은 상기 수학식 뿐만 아니라 패킷의 도착 시간을 제한하는 다른 어떠한 형태의 수학식으로 표현 가능할 수 있다.Also, the guide time of the current mode

can be expressed not only by the above mathematical formula but also by any other mathematical formula that limits the arrival time of a packet.

According to one aspect of the disclosed invention, a mode change of an ultra-low latency mode can be achieved by configuring a network switch to perform parallel processing based on hardware for changing the packet processing mode.

In addition, according to an embodiment of the present invention, a safe and smooth autonomous driving process can be implemented by configuring the mode to be changed immediately with almost no delay in changing the mode in an emergency situation such as an autonomous vehicle, and efficient network switching can be performed with limited resources.

FIG. 1 is a block diagram illustrating the basic concept of a mode-based ultra-low-latency packet scheduling device in a hardware implementation manner according to one embodiment of the present invention.

FIG. 2 is a block diagram of a mode-based ultra-low-latency packet scheduling device in a hardware implementation manner according to one embodiment of the present invention.

FIG. 3 is a schematic diagram of a packet processing process according to one embodiment of the present invention.

FIG. 4 is an example diagram of signal processing for mode change according to one embodiment of the present invention.

Figure 5 is a contrast graph of the mode change delay of a single switch for slow pass.

Figure 6 is a comparative graph of the mode change delay of a single switch for fast pass.

Figure 7 is a comparative graph of the mode change delay of a single switch for the Berry Fast Pass.

Figure 8 is a contrast graph of the mode change delay of the triple switch for slow pass.

Figure 9 is a comparative graph of the mode change delay of the triple switch for the fast pass.

Figure 10 is a contrast graph of the mode change delay of the triple switch for the Berry Fast Pass.

Figure 11 is a contrast graph of the time until mode change after HI action detection for a fast pass.

Figure 12 is a contrast graph of the time until mode change after HI action detection for Berry Fast Pass.

FIG. 13 is a flowchart of a mode-based ultra-low-latency packet scheduling method in a hardware implementation manner according to one embodiment of the present invention.

Like reference numerals refer to like elements throughout the specification. This specification does not describe all elements of the embodiments, and general contents in the technical field to which the disclosed invention belongs or contents that are duplicated between the embodiments are omitted. The term '~ section' or '~ module' used in the specification can be implemented by software or hardware, and according to the embodiments, multiple '~ sections' or '~ modules' can be implemented as a single component, or a single '~ section' or '~ module' can include multiple elements.

Also, when a part is said to "include" a component, this does not mean that other components are excluded, unless otherwise specifically stated, but rather that other components may be included. The term "part" or "module" as used herein refers to a unit that processes at least one function or operation, and may refer to, for example, software, an FPGA, or a hardware component. The function provided by the "part" or "module" may be performed separately by a plurality of components, or may be integrated with other additional components. The "part" or "module" as used herein is not necessarily limited to software or hardware, and may be configured to be on an addressable storage medium, or may be configured to cause one or more processors to reproduce.

Singular expressions include plural expressions unless the context clearly indicates otherwise. The identification codes in each step are used for convenience of explanation and do not describe the order of each step. Each step may be performed in a different order from the stated order unless the context clearly indicates a specific order. Hereinafter, the operating principle and embodiments of the disclosed invention will be described with reference to the attached drawings.

FIG. 1 is a block diagram illustrating the basic concept of a mode-based ultra-low-latency packet scheduling device in a hardware implementation manner according to one embodiment of the present invention.

Referring to FIG. 1, first, the configuration of an existing software-defined network (SDN) is illustrated, which is comprised of an SDN (software-defined network) control device (20) and an Ethernet switch (10) (10A). The Ethernet switch (10) is connected to numerous other Ethernet switches (10A), and the SDN control device (20) is configured to control the network switching of these Ethernet switches (10) (10A).

Ethernet switches (10)(10A) can be connected to each other in hundreds of thousands or millions to form a network, and in such cases, network management of the Ethernet switches (10)(10A) inevitably becomes difficult. Accordingly, the SDN control device (20) defines rules or policies for network switching using software, and the remote mode management unit (21) controls the switching of each Ethernet switch (10)(10A) to implement flexible and convenient network control. In this method, a packet processing process is performed through the slow path of Fig. 1, and a typical existing SDN process is understood.

Meanwhile, as a more advanced method, the method via the Fast Path of Fig. 1 is a method in which the Ethernet switch (10) independently sets rules or policies for network switching to perform switching more quickly. In the method via the Fast Path, each Ethernet switch (10) (10A) does not depend on remote control of the SDN control device (20), and the Ethernet switch (10) itself sets rules or policies for network switching to perform packet processing more quickly. In the method via the Fast Path, the Ethernet switch (10) is configured such that a local mode management unit (11) configured as a software layer performs the packet processing process.

In the method via Fast Pass, a local mode management unit (11) based on a software switch analyzes packets to detect emergency situations, etc., and is configured to change rules or policies for network switching in real time, and the Ethernet switch (10) is configured to immediately apply the changed rules or policies in real time. Accordingly, since the Ethernet switch (10) itself variably applies rules or policies for network switching without remote detection or remote control of the SDN control device (20), the speed for changing rules or policies can be rapidly increased. In addition, the local mode management unit (11) is configured to propagate all real-time changed rules or policies to other Ethernet switches (10A) so that other Ethernet switches (10A) can immediately apply the changed rules or policies and link them, thereby rapidly increasing the efficiency of the overall network process.

However, the method via Fast Pass has a structural disadvantage in the packet processing process because the local mode management unit (11) is based on a software switch. Specifically, in the method via Fast Pass, it is necessary to quickly detect an emergency situation or determine the need for a change in a rule or policy by analyzing the header of packets input to the Ethernet switch (10), but there is a problem that a significant delay occurs in the parsing and analysis of a continuous packet stream.

Accordingly, in the present invention, a network switching method using a very fast path was derived by improving the existing method using a fast pass.

In the present invention, a data path mode management unit (12) based on a hardware switch, rather than a local mode management unit (11) based on a software switch, is configured to analyze packet headers by processing them in parallel using hardware, and to change and apply rules or policies for network switching in real time. That is, according to an embodiment of the present invention, it is possible to quickly detect emergency situations through packet analysis or to quickly detect the need for changes to rules or policies.

Accordingly, the network switching method using the very fast pass according to the embodiment of the present invention significantly improves the delay in changing rules or policies for network switching that may occur within the Ethernet switch (10) itself.

In addition, the data path mode management unit (12) is configured to propagate all real-time changed rules or policies to other Ethernet switches (10A) so that the changed rules or policies are immediately applied and linked to other Ethernet switches (10A).

FIG. 2 is a block diagram of a mode-based ultra-low-latency packet scheduling device in a hardware implementation manner according to one embodiment of the present invention.

Referring to FIG. 2, a hardware-implemented mode-based ultra-low-latency packet scheduling device (100) according to one embodiment of the present invention may include an input interface module (110), a packet processing module (120), a mode management module (130), an output decision module (140), an output queue module (150), a mode propagation module (160), an output interface module (170), and a control interface module (180).

The input interface module (110) may be configured to receive packet streams from a plurality of input devices. The input devices may be, but are not limited to, a lidar sensor, a radar sensor, a camera sensor, an ECU, a computing node, an MP3 player, etc. installed in a vehicle.

The input interface module (110) may be equipped with a NIC (network interface controller) card.

The packet processing module (120) may be configured to process a packet stream received from the input interface module (110). The packet processing module (120) may be configured to include a lookup table memory (121) and a flow behavior monitoring unit (122).

The lookup table memory (121) may be configured to store a lookup table regarding packet processing modes. Here, the packet processing mode may be configured as a current mode and an emergency mode.

When packets are scheduled according to importance, the current mode can be LO mode and the emergency mode can be HI mode. For example, when packets are scheduled according to importance (Criticality) mode, the system mode can be configured as two modes, LO and HI. However, the current mode is not necessarily limited to LO mode, and the emergency mode is not necessarily limited to HI mode. The LO mode can be a mode that normally switches and transmits signals for non-urgent situations, such as a signal regarding the execution of an MP3 player. The HI mode can be a mode that preferentially switches and transmits camera signals or braking signals in cases where braking is urgently required, such as when an obstacle is detected during autonomous driving.

Here, the packet processing mode may be set to more than two modes as described above, depending on the criticality of the signal. In addition, the packet processing mode is not limited to the distinction based on the criticality, and any form of mode distinction can be applied.

The lookup table can be configured to specify multiple packet processing candidate modes for each signal.

The lookup table memory (121) may be provided in a separate memory element on the NIC card.

The flow behavior monitoring unit (122) can be implemented as a logic circuit in an FPGA (field programmable gate array) on a NIC card.

FIG. 3 is a schematic diagram of a packet processing process according to one embodiment of the present invention.

Referring to FIG. 3, the flow behavior monitoring unit (122) can be configured to parse a packet stream and identify each field header by referring to a lookup table stored in a lookup table memory (121).

Specifically, as illustrated in FIG. 3, the flow behavior monitoring unit (122) can be configured to simultaneously and in parallel parse and identify each field header of a packet stream received from an input interface module (110) by using a plurality of multiplexers provided in the FPGA.

Because the FPGA's multiplexer parses all field headers within a packet stream simultaneously, packet processing speed is dramatically increased compared to conventional software layer-based fast pass methods.

And the flow behavior monitoring unit (122) can be configured to determine whether the behavior of the corresponding flow violates the current packet processing mode on the lookup table, and if so, to generate a violation message and output it in real time to the mode management module (130).

Here, a flow can be defined as a set of packets divided based on a shim-header in a single packet stream.

The flow behavior monitoring unit (122) can match each field header being parsed with a header of a lookup table, and extract overlapping candidate rules from among packet processing candidate rules specified in each matched header. The flow behavior monitoring unit (122) can determine a packet processing rule corresponding to the current flow processing from among the extracted candidate rules. At this time, the flow behavior monitoring unit (122) can determine the packet processing rule corresponding to the current flow processing by determining which packet processing rule is the most suitable for processing the current flow from among the extracted candidate rules, and determining the packet processing rule that is the most suitable for processing the current flow as the packet processing rule corresponding to the current flow processing.

The flow behavior monitoring unit (122) can be configured to match each field header of each flow with the header of the lookup table in Phase 1 of FIG. 3, and extract overlapping candidate rules from among packet processing candidate rules specified in each matched header in Phase 2 of FIG. 3. Here, the packet processing candidate rules can be viewed as a set of packet processing rules on which a specific header signal can operate.

In Fig. 3, header signals of aa, yy, and cc are extracted from each header field, and by referring to the lookup table for these, packet processing candidate rules 10, 20, and 30 of each header signal aa, packet processing candidate rule 20 of each header signal yy, and packet processing candidate rules 20, 30, and 40 of each header signal cc are extracted, respectively. At this time, among each packet processing candidate rule, the overlapping candidate rule is 20. Accordingly, the packet processing rule of the current input signals, that is, the signal processing rule or signal processing policy can be detected as 20.

If there are multiple extracted candidate rules, the flow behavior monitoring unit (122) can determine a packet processing rule corresponding to the current flow processing from among the above extracted candidate rules. For example, if candidate rules extracted overlapping each other are 20 and 30, and the packet processing rule most suitable for processing the current flow is 20, the flow behavior monitoring unit (122) can determine candidate rule 20 as the packet processing rule corresponding to the current flow processing.

At this time, the flow behavior monitoring unit (122) may detect and determine whether a mode violation occurs by comparing the mode corresponding to packet processing rule 20 with the preset current packet processing mode. That is, if the current packet processing mode is the same as the preset current packet processing mode, the current packet processing mode is not a mode violation, but if it is different, the current packet processing mode becomes a mode violation, and the current packet processing mode may be configured to be changed to a newly extracted candidate mode. That is, it may be configured to be changed from a specific mode to a mode with higher criticality.

In general, high criticality modes, such as vehicle driving control, are implemented in a predictable system, and low criticality modes, such as music output, are implemented in a separate system. At this time, since the implementation of each mode is performed in a separate system, cost and resource waste may be severe. However, a mode-based ultra-low-latency packet scheduling device (100) implemented in a hardware manner according to an embodiment can be implemented through a single shared system using mixed-criticality (MC) instead of separate systems for the high criticality mode and the low criticality mode. However, the scheduling performed by the mode-based ultra-low-latency packet scheduling device (100) implemented in a hardware manner according to an embodiment is not limited to mixed-criticality (MC) packet scheduling.

Determination of whether a mod has been violated can be made according to the following process.

The flow behavior monitoring unit (122) may be configured to determine that if the flow generates more messages than the conditions of the current packet processing mode, it is a violation of the current packet processing mode. For example, when listening to music in a vehicle and the music signal is mainly networked, if an obstacle suddenly occurs, camera hazard signals, lidar signals, radar signals, etc. may suddenly increase. In this case, it may be determined that it is a violation of the current packet processing mode.

Additionally, the flow behavior monitoring unit (122) can be configured to determine whether the current mode is violated based on the size of the message.

에서의

번째 주기적 메시지에 대하여 현재 모드의 가이드 타임(guide time)

를 하기 수학식 1에 따라 산출하도록 구성될 수 있다.Specifically, the flow behavior monitoring unit (122)

In

Guide time of the current mode for the th periodic message

It can be configured to be calculated according to the following mathematical formula 1.

는 플로우

에서의

번째 메시지의 도착 시간이고,

는 각 주기적 메시지의 릴리스 지터(release jitter)이고,

는 플로우

에서의 현재 모드 주기이다.Here,

is the flow

In

is the arrival time of the second message,

is the release jitter of each periodic message,

is the flow

is the current mode cycle.

번째 메시지의 도착 시간이 가이드 타임보다 작은 경우 해당 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 메시지의 크기가 현재 모드의 크기 조건보다 더 큰 경우 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하도록 구성될 수 있다. 이때, 긴급 모드의 행동을 나타내는 것으로 판단하는 경우 모드 위반으로 판단하도록 구성될 수 있다.The flow behavior monitoring unit (122)

If the arrival time of the th message is less than the guide time, the message is determined to indicate an emergency mode behavior, and if the size of the message is greater than the size condition of the current mode, the message is determined to indicate an emergency mode behavior. In this case, if it is determined to indicate an emergency mode behavior, the message can be configured to be determined to be a mode violation.

은 상기 수학식 뿐만 아니라 패킷의 도착 시간을 제한하는 다른 어떠한 형태의 수학식으로 표현 가능할 수 있다.At this time, the guide time of the current mode

can be expressed not only by the above mathematical formula but also by any other mathematical formula that limits the arrival time of a packet.

Meanwhile, the mode management module (130) may be configured to change the packet processing mode in real time based on the result of processing the packet stream of the packet processing module (120). That is, it may be set to change in real time from a specific packet processing mode to a packet processing mode with higher priority so as to give priority to the switching of a signal or message with higher priority.

The mode management module (130) may be implemented as a logic circuit in an FPGA on a NIC card and may be implemented in a memory storage on the NIC card.

And the mode management module (130) can request the mode propagation module (160) to propagate the packet processing mode that is set to be changed in real time to other switch devices. Since the network switches must be interlocked with each other in the same packet processing mode to reduce the overall network transmission signal, they can be configured to interlock immediately through propagation and reception of the packet processing mode even if other network switches do not directly detect it.

The mode management module (130) may be configured to include a shadow table memory (131) and a mode change handling unit (132).

The shadow table memory (131) can be configured to store a shadow table corresponding to a packet processing mode.

The mode change handling unit (132) may be configured to change the packet processing mode corresponding to a violation message output in real time from the flow behavior monitoring unit (122) by referring to the shadow table stored in the shadow table memory (131), swap the shadow table with the lookup table of the lookup table memory (121), and store the shadow table as a lookup table in the lookup table memory (121).

The mode change handling unit (132) can be configured to change the candidate mode extracted from the flow behavior monitoring unit (122) to the current mode when the flow behavior monitoring unit (122) determines that a mode violation has occurred.

The output decision module (140) can be configured to set the priority of a packet and output it according to the packet processing mode that is changed in real time in the mode management module (130).

The output decision module (140) can be implemented as a logic circuit in an FPGA on a NIC card.

The output queue module (150) may be configured to store packets whose priority is set in the output decision module (140). The output queue module (150) may be provided in a memory device on a NIC card.

The output queue module (150) may be equipped with an output queue (151) for each input device. That is, if the input device is an MP3 player, a separate output queue (151) for the MP3 player may be equipped, and if the input device is a camera sensor, a separate output queue (151) for the camera sensor may be equipped.

The mode propagation module (160) may be configured to propagate the corresponding mode to other switch devices according to a request from the mode management module (130). The mode propagation module (160) may propagate a mode propagation notification signal through a separate channel. When other switch devices receive the mode propagation notification signal, they may be configured to empty all output queues and perform network switching according to the newly propagated packet processing mode.

The mode propagation module (160) can be implemented as a logic circuit in an FPGA on a NIC card.

The output interface module (170) can be configured to output packets stored in the output queue module (150) to the corresponding output device according to priority.

The output interface module (170) may be provided on a NIC card.

The output interface module (170) may be configured to include a plurality of output interface units (171) that output packets stored in the output queue of the output queue module (150) to respective output devices. Here, the output devices may be speakers, brake driving devices, wheel driving devices, engine driving devices, wiper driving devices, etc.

The control interface module (180) may be configured to receive an OpenFlow message from an SDN (software defined network) control device (not shown) and input it to the mode management module (130). Even though the SDN control device (not shown) is not normally involved in network switching, it may be involved in changing or controlling packet processing modes through OpenFlow messages when overall network switching control is required. The SDN control device (not shown) may add or change a new packet processing mode and update a shadow table.

The mode management module (130) can be configured to operate according to an openflow message received from the SDN control device.

FIG. 4 is an example diagram of signal processing for mode change according to one embodiment of the present invention.

Figure 4 shows a signal processing diagram in which the packet processing mode is changed, expressed as a clock unit signal.

Referring to Fig. 4, input signals In_1 and In_2 are input, and when A_2 is input from In_1, it can be seen that packet processing mode violation is detected with just 1 clock signal, and the mode is changed to emergency mode with just 1 clock signal again. It can be seen that the mode change is made by ultra-low latency (ULL) switching.

Meanwhile, FIGS. 5 and 6 illustrate examples of mode change delay in a single switch and a triple switch.

FIG. 5 is a contrast graph of mode change delay of a single switch for a slow pass, FIG. 6 is a contrast graph of mode change delay of a single switch for a fast pass, FIG. 7 is a contrast graph of mode change delay of a single switch for a very fast pass, FIG. 8 is a contrast graph of mode change delay of a triple switch for a slow pass, FIG. 9 is a contrast graph of mode change delay of a triple switch for a fast pass, and FIG. 10 is a contrast graph of mode change delay of a triple switch for a very fast pass.

Fig. 5 shows an example of a time for mode change delay to occur depending on the number of switching rules in a conventional SDN according to slow path. That is, it can be seen that the delay increases from 20 ms to 50 ms as the number of rules increases.

In Fig. 6, it can be seen that the mode change delay time increases rapidly from 200 μs to 800 μs in a software-based network switch according to Fast Pass. However, Fig. 7 shows a hardware-based network switch according to Very Fast Pass, and shows that the mode change delay time remains almost the same at 2.2 μs even though the number of rules increases.

Likewise, in Fig. 8, it can be seen that it occurs from 40 ms to 100 ms depending on the number of rules, and in Fig. 9, it increases slightly from 2000 μs depending on the number of rules. However, in Fig. 10, it can be seen that it is maintained at 4.5 μs even if the number of rules changes. By following the very fast pass according to the present invention, not only is the time of the mode change delay itself significantly lower than other methods, but it can also be seen that the time of the mode change delay itself is maintained the same even if the number of rules increases due to mode propagation.

Figure 11 is a contrast graph of the time until mode change after HI action detection for Fast Pass, and Figure 12 is a contrast graph of the time until mode change after HI action detection for Very Fast Pass.

Fig. 11 shows the end-to-end message transmission time according to Fast Pass, and Fig. 12 shows the end-to-end message transmission time according to Very Fast Pass. Each shows the end-to-end message transmission time when a mode change occurs, and when the HI behavior of the blue graph appears, it indicates that the mode change occurs immediately, transmission of messages in the current mode is stopped, and messages in the emergency mode are transmitted with priority for a much shorter time. At this time, it can be seen that Fast Pass detected the HI behavior at message 20 and the mode change occurred at message 121, but in Very Fast Pass, the mode change occurred immediately at message 21 as soon as the HI behavior was detected at message 20.

At least one component may be added or deleted in response to the performance of the components described above. In addition, it will be readily understood by those skilled in the art that the mutual positions of the components may be changed in response to the performance or structure of the system.

Fig. 13 is a flow chart of a mode-based ultra-low delay packet scheduling method in a hardware implementation manner according to one embodiment of the present invention. This is only a preferred embodiment for achieving the purpose of the present invention, and it is obvious that some configurations may be added or deleted as needed.

Referring to FIG. 13, an input interface module (110) equipped on a NIC (network interface controller) card can receive packet streams from multiple input devices (1001).

Next, a packet processing module (120) implemented in an FPGA (field programmable gate array) on a NIC card can process a packet stream received from an input interface module (110) (1002).

Here, the packet processing module (120) can be configured to simultaneously and in parallel parse and identify each field header of the packet stream received from the input interface module (110) by using a plurality of multiplexers provided in the FPGA.

At this time, the packet processing module (120) can be configured to identify each field header by referring to the lookup table stored in the lookup table memory (121), determine whether the behavior of the corresponding flow violates the current packet processing mode on the lookup table, and, if the determination result is violated, generate a violation message and output it in real time to the mode management module (130).

In addition, the packet processing module (120) may be configured to match each field header with a header of a lookup table, extract overlapping candidate modes from among packet processing candidate modes specified in each matched header, and detect and determine whether a mode is violated by comparing the extracted candidate modes with the already set modes.

And the packet processing module (120) can be configured to determine that a violation of the current packet processing mode occurs when the flow generates more messages than the conditions of the current mode.

에서의

번째 주기적 메시지에 대하여 현재 모드의 가이드 타임(guide time)

를 하기 수학식 2에 따라 산출하도록 구성될 수 있다.Meanwhile, the packet processing module (120)

In

Guide time of the current mode for the th periodic message

It can be configured to be calculated according to the following mathematical formula 2.

는 플로우

에서의

번째 메시지의 도착 시간이고,

는 각 주기적 메시지의 릴리스 지터(release jitter)이고,

는 플로우

에서의 현재 모드 주기이다.Here,

is the flow

In

is the arrival time of the second message,

is the release jitter of each periodic message,

is the flow

is the current mode cycle.

번째 메시지의 도착 시간이 가이드 타임보다 작은 경우 해당 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 메시지의 크기가 현재 모드의 크기 조건보다 더 큰 경우 메시지가 긴급 모드의 행동을 나타내는 것으로 판단하고, 긴급 모드의 행동을 나타내는 것으로 판단하는 경우 모드 위반으로 판단하도록 구성될 수 있다.And the packet processing module (120)

If the arrival time of the th message is less than the guide time, the message is judged to indicate an emergency mode behavior, if the size of the message is greater than the size condition of the current mode, the message is judged to indicate an emergency mode behavior, and if it is judged to indicate an emergency mode behavior, it can be configured to determine a mode violation.

은 상기 수학식 뿐만 아니라 패킷의 도착 시간을 제한하는 다른 어떠한 형태의 수학식으로 표현 가능할 수 있다.At this time, the guide time of the current mode

can be expressed not only by the above mathematical formula but also by any other mathematical formula that limits the arrival time of a packet.

Next, a mode management module (130) implemented in an FPGA on a NIC card changes the packet processing mode in real time based on the processing result of the packet stream of the packet processing module (120) (1003).

At this time, the mode management module (130) may be configured to change the packet processing mode corresponding to the violation message output in real time from the flow behavior monitoring unit (122) by referring to the shadow table stored in the shadow table memory (131) and swap the shadow table with the lookup table of the lookup table memory (131) and store it as a lookup table in the lookup table memory (131).

Next, the output decision module (140) implemented in the FPGA on the NIC card sets the priority of packets in the packet stream processed by the packet processing module (120) and outputs the packet processing mode set to be changed in real time by the mode management module (130) and stores it in the output queue module (150) on the memory (1004).

Next, the output interface module (170) equipped on the NIC card outputs packets stored in the output queue module (150) to the corresponding output device according to priority (1005).

Next, the mode management module (130) implemented in the FPGA on the NIC card requests that the packet processing mode being changed in real time be propagated to other switch devices (1006).

Next, the mode propagation module (160) equipped on the NIC card propagates the corresponding mode to another switch device (1007) according to the request of the mode management module (130).

The input interface module (110), the packet processing module (120), the mode management module (130), the output decision module (140), the output queue module (150), the mode propagation module (160), the output interface module (170), and the control interface module (180) may include any one of the processors or memories included in the hardware-implemented mode-based ultra-low-latency packet scheduling device (100). In addition, the control method of the hardware-implemented mode-based ultra-low-latency packet scheduling device (100) according to the embodiments of the present invention described so far and the embodiments to be described in the future may be implemented in the form of a program that can be driven by a processor.

Here, the program may include program commands, data files, and data structures, either singly or in combination. The program may be designed and produced using machine language codes or high-level language codes. The program may be specially designed to implement a method for controlling the above-described hardware-implemented mode-based ultra-low-latency packet scheduling device (100), or may be implemented using various functions or definitions that are known and available to those skilled in the art in computer software. The program for implementing the above-described hardware-implemented mode-based ultra-low-latency packet scheduling device (100) control method may be recorded on a recording medium readable by a processor. At this time, the recording medium may be a memory.

The memory can store a program that performs the aforementioned operations and the operations described below, and the memory can execute the stored program. In the case where there are a plurality of processors and memories, they can be integrated into a single chip or provided in physically separate locations. The memory can include volatile memory such as S-RAM (Static Random Access Memory) and D-RAM (Dynamic Random Access Memory) for temporarily storing data. In addition, the memory can include nonvolatile memory such as ROM (Read Only Memory), EPROM (Erasable Programmable Read Only Memory), and EEPROM (Electrically Erasable Programmable Read Only Memory) for long-term storing a control program and control data. The processor can include various logic circuits and arithmetic circuits, and can process data according to a program provided from the memory and generate a control signal according to the processing result.

As described above, the disclosed embodiments have been described with reference to the attached drawings. Those skilled in the art to which the present invention pertains will understand that the present invention can be implemented in forms other than the disclosed embodiments without changing the technical idea or essential features of the present invention. The disclosed embodiments are exemplary and should not be construed as limiting.

Claims (20)

An input interface module that receives packet streams from multiple input devices; A packet processing module that processes a packet stream received from the above input interface module; A mode management module that changes and sets the packet processing mode in real time based on the processing result of the packet stream of the packet processing module; An output decision module that sets the priority of packets in the packet stream processed by the packet processing module and outputs a packet processing mode that is changed in real time by the mode management module; An output queue module in which packets with priorities set in the above output decision module are stored; and Includes an output interface module that outputs packets stored in the above output queue module to the corresponding output device according to priority. The above packet processing module, A hardware-implemented mode-based ultra-low-latency packet scheduling device implemented as a logic circuit in an FPGA (field programmable gate array) on a NIC (network interface controller) card, configured to simultaneously and in parallel parse and identify each field header of a packet stream input from the input interface module using a plurality of multiplexers provided in the FPGA. In the first paragraph, The above mode management module, A hardware-implemented mode-based ultra-low latency packet scheduling device that requests that the above real-time changed packet processing mode be propagated to other switching devices. In the second paragraph, A hardware-implemented mode-based ultra-low latency packet scheduling device further comprising a mode propagation module for propagating the mode to another switching device according to a request from the mode management module. In the first paragraph, A hardware-implemented mode-based ultra-low-latency packet scheduling device further comprising a control interface module that receives an OpenFlow message from an SDN (software defined network) control device and inputs it into the mode management module. In paragraph 4, The above mode management module, A hardware-implemented mode-based ultra-low-latency packet scheduling device configured to operate according to an openflow message received from the above SDN control device. In the first paragraph, The above packet processing module: A lookup table memory in which a lookup table regarding packet processing modes is stored; and A hardware-implemented mode-based ultra-low-latency packet scheduling device, comprising a flow behavior monitoring unit configured to identify each of the above-mentioned field headers being parsed by referring to a lookup table stored in the lookup table memory, determine whether the behavior of the corresponding flow violates the current packet processing mode on the lookup table, and, if so, generate a violation message and output it in real time to the mode management module. In Article 6, The above flow behavior monitoring unit, Each of the above-mentioned field headers being parsed is matched with the header of the above-mentioned lookup table, and candidate rules that overlap with each other are extracted from among the packet processing candidate rules specified in each matched header, and a packet processing rule corresponding to the current flow processing is determined from among the extracted candidate rules. The above mode management module, Guide time of current mode

A hardware-implemented mode-based ultra-low latency packet scheduling device configured to calculate a packet arrival time according to a mathematical formula that limits the arrival time of the packet. In Article 7, The above mode management module, If the above flow generates more messages than the conditions of the current packet processing mode, it is judged as a violation of the current packet processing mode. Flow

In

Guide time of the current mode for the th periodic message

It is calculated according to the following mathematical formula, [Mathematical formula]

Here,

is the flow

In

is the arrival time of the second message,

is the release jitter of each periodic message,

is the flow

is the current mode cycle in , Above

A hardware-implemented mode-based ultra-low-latency packet scheduling device configured to determine that if the arrival time of the th message is less than the guide time, the message indicates an emergency mode behavior, if the size of the message is greater than a size condition of the current mode, the message indicates an emergency mode behavior, and if it is determined that the message indicates an emergency mode behavior, a mode violation occurs. In Article 6, The above mode management module: Shadow table memory where a shadow table corresponding to the packet processing mode is stored; and A hardware-implemented mode-based ultra-low-latency packet scheduling device, comprising: a mode change handling unit configured to swap the shadow table stored in the shadow table memory with the lookup table of the lookup table memory and store the shadow table as a lookup table in the lookup table memory to change the packet processing mode corresponding to the violation message output in real time from the flow behavior monitoring unit. In Article 9, The above mode management module: Shadow table memory where a shadow table corresponding to the packet processing mode is stored; and A hardware-implemented mode-based ultra-low-latency packet scheduling device configured to change a packet processing mode corresponding to a violation message output in real time from the flow behavior monitoring unit by referring to the shadow table stored in the shadow table memory, and including a mode change handling unit that swaps the corresponding shadow table stored in the shadow table memory with the lookup table of the lookup table memory and stores it as a lookup table in the lookup table memory for the mode change. In Article 10, The above mode change handling unit is, A hardware-implemented mode-based ultra-low-latency packet scheduling device configured to change a suitable change candidate mode identified by the flow behavior monitoring unit to a current packet processing mode when the flow behavior monitoring unit determines that a mode violation has occurred. In the first paragraph, The above output queue module, A hardware-implemented mode-based ultra-low latency packet scheduling device, wherein an output queue is provided for each of the above input devices. In the first paragraph, The above output interface module, A hardware-implemented mode-based ultra-low-latency packet scheduling device configured to include a plurality of output interface sections each of which outputs packets stored in an output queue of the above output queue module to a corresponding output device. A step in which an input interface module equipped on a NIC (network interface controller) card receives packet streams from multiple input devices; A step in which a packet processing module implemented in an FPGA (field programmable gate array) on the NIC card processes a packet stream received from the input interface module; A step for changing and setting a packet processing mode in real time based on the processing result of a packet stream of the packet processing module by a mode management module implemented in an FPGA on the NIC card; A step in which an output decision module implemented in an FPGA on the NIC card sets the priority of a packet in a packet stream processed by the packet processing module and outputs a packet processing mode set to be changed in real time by the mode management module and stores it in an output queue module on the memory; and The output interface module provided on the NIC card includes a step of outputting packets stored in the output queue module to the corresponding output device according to priority. The step of processing a packet stream received from the input interface module by the packet processing module implemented in the FPGA on the above NIC card is as follows: A hardware-implemented mode-based ultra-low-latency packet scheduling method characterized in that it is configured to simultaneously and in parallel parse and identify each field header of a packet stream input from the input interface module by using a plurality of multiplexers provided in the FPGA. In Article 14, A hardware-implemented mode-based ultra-low latency packet scheduling method further comprising a step of requesting a mode management module implemented in an FPGA on the NIC card to propagate the packet processing mode set in real time to another switch device. In Article 15, A hardware-implemented mode-based ultra-low-latency packet scheduling method further comprising a step of a mode propagation module provided on the NIC card propagating the corresponding mode to another switch device according to a request of the mode management module. In Article 14, The step of processing a packet stream received from the input interface module by the packet processing module implemented in the FPGA on the above NIC card is as follows: A hardware-implemented mode-based ultra-low-latency packet scheduling method characterized in that it is configured to identify each of the above-mentioned field headers to be parsed by referring to a lookup table stored in a lookup table memory, determine whether the behavior of the corresponding flow violates the current packet processing mode on the lookup table, and, if the result of the determination violates, generate a violation message and output it in real time to the mode management module. In Article 17, The step of processing a packet stream received from the input interface module by the packet processing module implemented in the FPGA on the above NIC card is as follows: Match each of the above-mentioned field headers to be parsed with the header of the above-mentioned lookup table, extract overlapping candidate rules from among the packet processing candidate rules specified in each matched header, and determine the packet processing rule corresponding to the current flow processing from among the extracted candidate rules. Guide time of current mode

A hardware-implemented mode-based ultra-low-latency packet scheduling method, characterized in that it is configured to calculate a packet arrival time according to a mathematical formula that limits the arrival time of the packet. In Article 18, The step of changing and setting the packet processing mode in real time based on the processing result of the packet stream of the packet processing module by the mode management module implemented in the FPGA on the above NIC card is as follows. A hardware-implemented mode-based ultra-low-latency packet scheduling method, characterized in that the shadow table stored in the shadow table memory is configured to be swapped with a lookup table of the lookup table memory and stored as a lookup table in the lookup table memory to change to a packet processing mode corresponding to a violation message output in real time from the flow behavior monitoring unit by referring to the shadow table stored in the shadow table memory. In Article 18, The step of processing a packet stream received from the input interface module by the packet processing module implemented in the FPGA on the above NIC card is as follows: If the above flow generates more messages than the conditions of the current packet processing mode, it is judged as a violation of the current packet processing mode. Flow

In

Guide time of the current mode for the th periodic message

It is calculated according to the following mathematical formula, [Mathematical formula]

Here,

is the flow

In

is the arrival time of the second message,

is the release jitter of each periodic message,

is the flow

is the current mode cycle in , Above

A hardware-implemented mode-based ultra-low-latency packet scheduling method, characterized in that if the arrival time of the th message is less than the guide time, the message is determined to indicate an emergency mode behavior, if the size of the message is greater than a size condition of the current mode, the message is determined to indicate an emergency mode behavior, and if it is determined to indicate an emergency mode behavior, a mode violation is determined.

Images