Congestion-aware buffer scheduling method and system for a multi-port in-vehicle gateway

Abstract

The application relates to a congestion-aware buffer scheduling method and system of a multi-port vehicle-mounted gateway, which comprises the following steps: configuring the CAN port and the Ethernet port as fixed-length receiving buffers, and writing messages into the corresponding receiving buffers; in the main loop process, when the water level of any receiving buffer exceeds the congestion threshold, it is determined that the vehicle-mounted gateway enters a congestion state, and the budget of the current rule filtering is increased from a regular value to an enhanced value; in the congestion state, according to the budget quantity corresponding to the enhanced value, the to-be-processed frames are read from the receiving buffer to perform the entry port rule matching, and based on the matching result, the to-be-processed frames are selectively subjected to congestion priority discarding or are subjected to sending based on the output port bitmap; in the Ethernet receiving interrupt service program, the frame analysis operation of the preset budget quantity is performed, and if there are still unprocessed frames in the MAC layer, a to-be-processed flag is set. The application improves the real-time performance, stability and key traffic forwarding reliability of the system.

Description

Technical Field

[0001] This invention relates to the field of vehicle network communication technology, and in particular to a congestion-aware buffer scheduling method and system for a multi-port vehicle gateway. Background Technology

[0002] With the rapid development of intelligent connected vehicles, in-vehicle electronic systems are becoming increasingly complex. A large number of electronic control units and sensors are deployed inside vehicles, forming an in-vehicle backbone network dominated by the Controller Area Network (CAN) bus. Meanwhile, with the widespread adoption of in-vehicle infotainment systems, advanced driver assistance systems, and vehicle-to-everything (V2X) applications, Ethernet, with its high bandwidth advantage, is gradually entering the in-vehicle network architecture. Therefore, multi-port in-vehicle gateways integrating multiple CAN and Ethernet ports are needed to undertake critical tasks such as cross-bus message routing, protocol conversion, and traffic aggregation.

[0003] In the actual operation of multi-port vehicle gateways, CAN ports and Ethernet ports often need to handle concurrent traffic from multiple directions simultaneously. Due to significant differences between CAN bus and Ethernet in communication speed, frame format, and quality of service requirements, the vehicle gateway must manage message reception, rule filtering, buffer management, and cross-port forwarding across multiple ports within limited processing power and storage resources. However, because the microcontroller (MCU) resources of the vehicle gateway are limited, especially the limited random access memory (RAM) capacity, concurrent traffic from multiple ports can easily cause the receive buffer to fill up quickly.

[0004] To address the buffer overflow problem, existing technologies typically employ two approaches. One is to simply increase the depth of the receive buffer to absorb more burst traffic; the other is to implement passive packet dropping strategies, such as tail dropping, head dropping, or random early detection, when the buffer exceeds its limit.

[0005] However, in practical applications of multi-port CAN / Ethernet embedded gateways, the MCU's RAM resources are extremely limited and usually require static allocation. Simply expanding the buffer will consume a large amount of RAM space and increase the queuing latency of messages in the buffer. Furthermore, when the buffer is full, existing technologies often indiscriminately discard all newly arriving messages. Critical control messages with configured routes may be discarded, while invalid messages or illegal frames with no matching rules may occupy buffer space and consume processing resources, leading to the consumption of system resources by invalid traffic. Additionally, when the Ethernet port is subjected to broadcast storms or sudden UDP traffic attacks, frequent receive interrupts may cause the interrupt service routine to continuously occupy the CPU, preventing background tasks from executing and potentially causing watchdog resets or CAN port scan task starvation. Summary of the Invention

[0006] (a) Technical problems to be solved In view of the above-mentioned shortcomings and deficiencies of the prior art, the present invention provides a congestion-aware buffer scheduling method and system for multi-port vehicle gateways, which solves the technical problems of limited RAM resources in multi-channel CAN / Ethernet embedded gateways, such as the inability to dynamically expand the buffer, indiscriminately discarding critical messages after the buffer is full, and interrupt starvation and CPU overload caused by burst Ethernet traffic.

[0007] (II) Technical Solution To achieve the above objectives, the main technical solutions adopted by the present invention include: In a first aspect, embodiments of the present invention provide a congestion-aware buffer scheduling method for a multi-port vehicle gateway, comprising: Both the CAN port and Ethernet port in the vehicle gateway are configured with fixed-length receive buffers, and the received messages are written into the corresponding receive buffers through receive interrupt or callback service routines. During the main loop, when the water level of any receiving buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to the enhanced value. In a congested state, according to the budget quantity corresponding to the enhancement value, the frames to be processed are read from the receive buffer to perform ingress port rule matching, and based on the matching results, the frames to be processed are selectively discarded with congestion priority or sent based on the output port bitmap. In the Ethernet receive interrupt service routine, a preset budget of frame parsing operations are performed. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget.

[0008] Optionally, both the CAN port and Ethernet port in the vehicle gateway are configured with fixed-length receive buffers, and the received messages are written into the corresponding receive buffers through receive interrupts or callback service routines, including: Both the CAN port and Ethernet port in the vehicle gateway are configured as fixed-length receive buffers. Each receive buffer maintains a head pointer, a tail pointer, the current number, a lock state, a port output bitmap, a retransmission count, and a diagnostic count. The diagnostic counts include port drop count, high-water mark, congestion event count, congestion drop count, Ethernet receive backlog count, and transmit failure count. The received message is written to the receive buffer of the corresponding port by receiving interrupt or callback service routine; When the current number of packets in the receive buffer reaches a fixed length, the packet is discarded and the receive drop count is incremented by the source port.

[0009] Optionally, when the water level of any receive buffer exceeds a preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to an enhanced value, including: During the main loop, the current water level information of the receiving cache is obtained; When the water level of any receive buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to the enhanced value. When the water level of any receive buffer does not exceed the preset congestion threshold, the vehicle gateway is determined to be in a non-congested state, and ingress port rule matching is performed according to the budget number limited by the normal value. In a non-congestion state, if a frame to be processed read from the receive buffer does not match any pre-configured rule, the frame is released without increasing the congestion-priority drop count.

[0010] Optionally, in a congested state, according to the budgeted quantity corresponding to the enhancement value, frames to be processed are read from the receive buffer to perform ingress port rule matching, and based on the matching results, frames to be processed are selectively either congestion-priority dropped or transmitted based on the output port bitmap, including: Read the number of frames to be processed sequentially from the header of the receive buffer, as specified by the enhancement value; Perform ingress port rule matching on each frame to be processed. If the frame to be processed does not match any pre-configured rule, the frame is released and the congestion-priority drop count is incremented; If the frame to be processed matches a pre-configured rule, an output port bitmap is generated based on the matching result, and the frame to be processed is handed over to the transmitter for transmission.

[0011] Optionally, ingress port rule matching includes: Obtain the ingress port identifier and frame header feature fields of the frame to be processed; The ingress port identifier and frame header feature fields are compared with each rule in the pre-configured rule list; If all pre-configured rules fail to match, the rule is considered not to match. If any pre-configured rule is successfully matched, it is determined to be a match, and the output port information corresponding to that rule is obtained.

[0012] Optionally, after handing the frame to be processed over to the transmitter for transmission, the method further includes: During transmission, if some output ports in the output port bitmap are successfully transmitted while the rest fail to be transmitted, the corresponding buffer entry of the frame to be processed in the receive buffer is retained, and the output port bits that have been successfully transmitted are cleared, leaving only the output port bits that have not been successfully transmitted. Within the set limit of retries, the cached item will be sent to the output port that failed to send. If the number of retries does not exceed the limit and the retry is successful, then the buffer item is released; If the number of retries exceeds the limit, the buffer entry is released and the send failure count is incremented.

[0013] Optionally, in the Ethernet receive interrupt service routine, a preset budget of frame parsing operations is performed. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget. These include: When an Ethernet receive interrupt is triggered, the Ethernet receive interrupt service routine is entered. In the Ethernet receive interrupt service routine, with a preset budget as the upper limit for processing in a single session, unprocessed frames are read sequentially from the MAC layer and frame parsing operations are performed. Each time a frame is successfully parsed, the remaining budget is reduced until the number of parsed frames reaches the preset budget or there are no unprocessed frames remaining in the MAC layer. If the MAC layer still has unprocessed frames after the frame parsing operation of the preset budget number is completed, the pending flag is set and the current interrupt service routine is exited. In subsequent iterations of the main loop, when the pending flag is detected to be set, the backlog of frames in the MAC layer continues to be processed in batches according to the preset budget number in a non-interruptible context until all the backlog of frames in the MAC layer has been processed and the pending flag is cleared.

[0014] Optionally, it also includes: During the main cycle, multiple preset maintenance tasks are arranged in a round-robin manner, with only one maintenance task executed in each maintenance cycle. The maintenance tasks include analog-to-digital conversion protection task, physical layer link detection task, CAN bus recovery task, and Ethernet recovery task. In addition, the high-water mark of the received buffer, congestion event count, congestion-priority drop count and port drop count are included in the remotely readable diagnostic information, so that external devices can determine the rationality of the ingress port rule configuration and / or the abnormal state of network traffic by reading the remotely readable diagnostic information.

[0015] Secondly, embodiments of the present invention provide a congestion-aware buffer scheduling system for a multi-port vehicle gateway, comprising: The receive buffer configuration and message writing module is used to configure both the CAN port and Ethernet port in the vehicle gateway as a fixed-length receive buffer, and to write the received messages into the corresponding receive buffer through the receive interrupt or callback service program. The congestion detection and budget adjustment module is used to determine that the vehicle gateway has entered a congestion state when the water level of any receiving buffer exceeds the preset congestion threshold during the main loop, and to increase the budget of the rule filtering in this round from the normal value to the enhanced value. The rule matching and scheduling processing module is used to read frames to be processed from the receive buffer in the state of congestion according to the budget quantity corresponding to the enhancement value to perform ingress port rule matching, and selectively perform congestion-priority discarding or transmission based on the output port bitmap based on the matching result. The Ethernet interrupt budget processing module is used to perform frame parsing operations with a preset budget number in the Ethernet receive interrupt service routine. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget.

[0016] Thirdly, embodiments of the present invention provide a multi-port vehicle gateway, comprising: At least one processor; and memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by the processor. When the processor executes the instructions, it implements the congestion-aware buffer scheduling method for a multi-port vehicle gateway described above.

[0017] (III) Beneficial Effects The beneficial effects of the present invention are as follows: The congestion-aware buffer scheduling method of the multi-port vehicle gateway of the present invention avoids the memory fragmentation problem and uncontrollable queuing delay growth caused by dynamic memory allocation due to the use of a fixed-length receive buffer configuration, so as to enable stable operation in the MCU environment with limited RAM resources and ensure the predictability of message queuing delay.

[0018] Meanwhile, the present invention also adopts a mechanism that actively checks the receiving buffer level in the main loop and dynamically increases the rule filtering budget from the normal value to the enhanced value when the level exceeds the preset congestion threshold. This actively speeds up frame processing before the buffer is full, avoiding the problem of passively and indiscriminately discarding packets after the buffer is full, and moving congestion control to the early warning stage.

[0019] Furthermore, the present invention employs a differentiated processing strategy that prioritizes discarding frames that do not match the pre-configured rules under congestion conditions, while retaining frames that match the rules and forwarding them normally according to the output port bitmap. This ensures that when cache resources are scarce, limited processing capacity and storage space are prioritized to serve critical control messages with configured routes, significantly improving the retention probability of critical traffic and the success rate of cross-port forwarding.

[0020] Finally, this invention also employs an anti-burst reception mechanism that limits the number of frames parsed in a single session by pre-setting a budget quantity in the Ethernet receive interrupt service routine, and exits the interrupt after setting a pending flag when there is still a backlog at the MAC layer, with the main loop continuing to process the data in subsequent rounds. This effectively prevents the interrupt service routine from occupying the CPU for a long time and being unable to return due to broadcast storms or sudden UDP traffic, avoiding serious faults such as watchdog reset, CAN scan starvation, and unrecoverable system failures caused by this, while ensuring the determinism of interrupt latency and the real-time response capability of the system. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating a congestion-aware buffer scheduling method for a multi-port vehicle gateway according to an embodiment of the present invention. Figure 2 This is a schematic diagram illustrating the process of receiving buffer configuration and message writing according to an embodiment of the present invention; Figure 3 This is a schematic diagram of a congestion detection and budget adjustment process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the entry port rule matching process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the rule matching and scheduling process provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of the process for forwarding frames to be processed according to an embodiment of the present invention; Figure 7 This is a schematic diagram of the Ethernet interrupt budget processing provided in an embodiment of the present invention. Detailed Implementation

[0022] To better explain and facilitate understanding of the present invention, the present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0023] refer to Figures 1 to 7As shown in the embodiment of the present invention, a congestion-aware buffer scheduling method for a multi-port vehicle gateway includes: configuring both the CAN port and the Ethernet port in the vehicle gateway as fixed-length receive buffers, and writing the received messages into the corresponding receive buffers through a receive interrupt or callback service routine; during the main loop, when the level of any receive buffer exceeds a preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for rule filtering in this round is increased from a normal value to an enhanced value; in the congested state, according to the budget quantity corresponding to the enhanced value, frames to be processed are read from the receive buffer to perform entry port rule matching, and based on the matching result, frames to be processed are selectively discarded due to congestion or sent based on the output port bitmap; in the Ethernet receive interrupt service routine, a frame parsing operation with a preset budget quantity is performed, and if there are still unprocessed frames in the MAC layer, a pending processing flag is set to remind the main loop to continue processing the backlog frames corresponding to the pending processing flag according to the budget in subsequent rounds.

[0024] This embodiment, by employing a fixed-length receive buffer configuration, avoids memory fragmentation issues and uncontrollable queuing latency increases caused by dynamic memory allocation. This ensures stable operation in MCU environments with limited RAM resources and guarantees the predictability of packet queuing latency. Furthermore, this embodiment employs a mechanism where the main loop actively checks the receive buffer level and dynamically increases the rule filtering budget from a normal value to an enhanced value when the level exceeds a preset congestion threshold. This proactively accelerates frame processing before the buffer is full, avoiding the problem of passively and indiscriminately discarding packets after the buffer is full, thus bringing congestion control forward to the early warning stage. Additionally, this embodiment adopts a differentiated processing strategy in congested conditions, prioritizing the discarding of frames that do not match pre-configured rules while retaining frames that match rules and forwarding them normally according to the output port bitmap. This ensures that limited processing capacity and storage space prioritize serving critical control packets with configured routes when buffer resources are scarce, significantly improving the retention probability of critical traffic and the success rate of cross-port forwarding. Finally, this embodiment also employs an anti-burst reception mechanism that limits the number of frames parsed in a single session by pre-setting a budget quantity in the Ethernet receive interrupt service routine, and exits the interrupt after setting a pending flag when there is still a backlog at the MAC layer, with the main loop continuing to process the data in subsequent rounds. This effectively prevents the interrupt service routine from occupying the CPU for a long time and being unable to return due to broadcast storms or sudden UDP traffic, avoiding serious faults such as watchdog reset, CAN scan starvation, and unrecoverable system failures caused by this, while ensuring the determinism of interrupt latency and the real-time response capability of the system.

[0025] To better understand the above technical solutions, exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although exemplary embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the present invention can be understood more clearly and thoroughly, and that the scope of the present invention can be fully conveyed to those skilled in the art.

[0026] Specifically, refer to Figure 1 As shown in the embodiment of the present invention, a congestion-aware buffer scheduling method for a multi-port vehicle gateway may include the following steps S100 to S400: S100 configures both the CAN port and Ethernet port in the vehicle gateway as fixed-length receive buffers, and writes the received messages into the corresponding receive buffers through receive interrupt or callback service routines.

[0027] In this embodiment, due to the limited MCU resources of the vehicle gateway, its RAM capacity is fixed and typically does not support dynamic memory allocation, or dynamic allocation introduces memory fragmentation and uncertain allocation latency. Therefore, this embodiment pre-allocates a fixed-length receive buffer for each port that needs to receive messages. Simultaneously, because message arrivals are sudden and asynchronous, if a main loop polling method is used to detect whether a new message has arrived at a port, the uncertain execution cycle of the main loop will lead to message reception delays or loss. Therefore, this embodiment also utilizes hardware interrupt mechanisms, namely CAN receive interrupt and Ethernet receive interrupt, or underlying driver callback service routines to implement real-time message capture and enqueue operations, ensuring that each arriving message is written to the corresponding receive buffer in a timely manner. Specifically, refer to... Figure 2 As shown, step S100 may include the following steps S110 to S130: S110. Configure both the CAN port and Ethernet port in the vehicle gateway as fixed-length receive buffers. Each receive buffer maintains a head pointer, tail pointer, current quantity, lock state, port output bitmap, retransmission count, and diagnostic count. The diagnostic count includes port drop count, high water mark, congestion event count, congestion drop count, Ethernet receive backlog count, and transmit failure count.

[0028] Furthermore, the head pointer points to the next message position to be read in the receive buffer, used by the main loop to sequentially read frames from the buffer. The tail pointer points to the next writable free position in the receive buffer, used by interrupt service routines or callback functions to write newly arrived messages into the buffer. The current quantity records the number of message frames currently stored in the receive buffer, i.e., the number of messages between the head and tail pointers. The lock state is used to prevent race conditions caused by multiple tasks or multiple interrupt contexts accessing the same receive buffer simultaneously. Since concurrent access may exist between the receive interrupt and the main loop, as well as between interrupts from different ports, this embodiment implements simple mutual exclusion access protection through the lock state field. The port output bitmap is used to record the set of target output ports to which the current buffer item needs to be forwarded. The retransmission count records the number of times the current buffer item has attempted to retransmit. The diagnostic count records various statistical information during system operation, providing data support for remote diagnosis and on-site fault diagnosis. The diagnostic counts specifically include: port drop count, which records the number of packets dropped by each port due to a full receive buffer; high-water mark, which records the highest water level value reached by the receive buffer, used to assess whether the peak traffic and buffer capacity configuration are reasonable; congestion event count, which records the number of times the system enters a congestion state; congestion drop count, which records the number of frames that are preferentially dropped due to non-matching rules during congestion; Ethernet receive backlog count, which records the number of unprocessed backlog frames in the Ethernet MAC layer; and transmission failure count, which records the cumulative number of transmission failures for each output port.

[0029] S120: The received message is written to the receive buffer of the corresponding port through the receive interrupt or callback service routine.

[0030] Furthermore, when the CAN port receives a new message, the CAN controller hardware triggers a CAN receive interrupt, and the interrupt service routine (ISR) is invoked. In the CAN receive interrupt service routine, the program reads the message data from the CAN controller's receive mailbox, obtains the source port identifier of the message, and then locates the corresponding port's receive buffer control block. If the receive buffer is not full, the message data is copied to the free position pointed to by the tail pointer, and then the tail pointer is updated and incremented. Similarly, when the Ethernet port receives a new message, the Ethernet MAC controller triggers an Ethernet receive interrupt. The interrupt service routine reads the message data from the MAC layer's receive descriptor ring and writes the message to the Ethernet port's receive buffer in the same way. In some real-time operating system (RTOS) environments, callback service routines can also be used instead of direct interrupt handling. That is, a callback function is registered in the underlying driver, and the operating system calls this callback function in the interrupt context or task context to complete the message writing operation.

[0031] S130. When the current number of packets in the receive buffer reaches a fixed length, the packet is discarded and the receive discard count is incremented by the source port.

[0032] Furthermore, when a message write operation is performed and the receive buffer of the corresponding port is detected to be full (i.e., the current count equals a fixed length), it indicates that the message arrival rate of that port exceeds the system's processing capacity, and the buffer has no free space to accommodate newly arriving messages. In this case, the new message cannot be written to the buffer, so it is directly discarded. Simultaneously, to prevent such events from being ignored and causing maintenance personnel to be unaware of buffer overload issues, after discarding the message, the receive drop count of the source port is incremented by 1, i.e., added to the port drop count in the diagnostic count. It is important to note that this discarding is a passive discarding within the interrupt context, fundamentally different from the proactive congestion-priority discarding within the main loop context in subsequent steps: the former occurs when the buffer is full, is executed by the interrupt service routine, and is a last resort of passive packet dropping; the latter occurs during the warning stage when the buffer level exceeds the threshold, is executed by the main loop, and is proactive packet dropping with early intervention. The combination of these two approaches allows for both protecting the buffer from overflow under extreme overload conditions and proactively releasing invalid messages in the early stages of congestion to delay or even prevent the buffer from filling up, thus achieving a better congestion management effect.

[0033] S200. During the main loop, when the water level of any receiving buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to the enhanced value.

[0034] In this embodiment, because the receiving buffer of the vehicle gateway is configured with a fixed length, it cannot be dynamically expanded at runtime. Once the buffer is full, newly arriving packets can only be passively discarded. However, when passive discarding occurs, the interrupt service routine returns immediately after discarding the packet, making it impossible to differentiate and clean up existing packets in the buffer. Critical control packets with configured rules and invalid frames that do not match the rules are mixed and queued in the buffer, causing the limited buffer space and processing resources to be occupied by invalid traffic. Therefore, this embodiment adopts a proactive congestion prediction and budget dynamic adjustment mechanism based on water level detection: the current water level of each receiving buffer is periodically checked in the main loop. When the water level exceeds the preset congestion threshold, the congestion state is determined in advance before the buffer is completely filled, and the budget for rule filtering in this round is immediately increased from the normal value to the enhanced value. By increasing the number of frames processed in a single round, the buffer release is actively accelerated, and congestion control is transformed from passive response to proactive prevention. Specifically, refer to Figure 3 As shown, step S200 may include the following steps S210 to S230: S210. During the main loop, obtain the current water level information of the receiving buffer.

[0035] Furthermore, at the beginning of each iteration, the main loop iterates through the receive buffers of all ports and reads the current quantity field in each receive buffer as the current water level information of that buffer.

[0036] S220a. When the water level of any receiving buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to the enhanced value.

[0037] Furthermore, the congestion threshold is a preset percentage of the receive buffer capacity, such as 70% or 80%, determined comprehensively based on the MCU's processing capabilities, the traffic characteristics of each port, and the target cycle of the main loop. When the level of any receive buffer exceeds this threshold, it indicates that at least one port's buffer is about to fill up, and the entire vehicle gateway is deemed to be in a congested state. At this time, the main loop increases the budget for this round of rule filtering from the normal value to an enhanced value, for example, increasing it from 4 frames per round to 16 frames per round. This accelerates the release of packets in the receive buffer by increasing the upper limit of the number of frames processed per round, proactively freeing up space before the buffer reaches a full state, and delaying or even avoiding passive packet drop events.

[0038] S220b: When the water level of any receiving buffer does not exceed the preset congestion threshold, the vehicle gateway is determined to be in a non-congested state, and ingress port rule matching is performed according to the budget quantity limited by the normal value.

[0039] Further, refer to Figure 4 As shown, the ingress port rule matching process includes steps G100 to G300: G100: Obtain the ingress port identifier and frame header feature field of the frame to be processed.

[0040] For example, the source port identifier, such as CAN0 to CAN8, is obtained from the metadata of the frame to be processed, and key feature fields in the frame header are extracted from the frame content. For CAN frames, the frame header feature fields include, but are not limited to, an 11-bit or 29-bit CAN identifier and a data length code; for Ethernet frames, the frame header feature fields include, but are not limited to, Ethernet type, source MAC address, destination MAC address, and relevant fields from the IP layer and transport layer.

[0041] G200 compares the ingress port identifier and frame header feature fields with each rule in the pre-configured rule list.

[0042] For example, each rule in the pre-configured rule list includes: a matching condition composed of ingress port conditions and frame feature conditions, specifying the set of output ports or specifying the discard action.

[0043] G300a: If all pre-configured rules fail to match, the rule is considered unmatched.

[0044] G300b: If any pre-configured rule is successfully compared, it is determined to be a match, and the output port information corresponding to that rule is obtained.

[0045] S230. In a non-congestion state, if a frame to be processed read from the receive buffer does not match any pre-configured rule, the frame is released without increasing the congestion-priority drop count.

[0046] Furthermore, in a non-congested state, with ample buffer space, frames that do not match the rules, while having no forwarding target, do not cause significant buffer pressure. Therefore, these frames are released normally without increasing the congestion-priority drop count. By strictly limiting the congestion-priority drop count to proactive drop behavior under congested conditions, the semantics of this diagnostic metric are clearer. Its value directly reflects the number of frames prioritized for cleanup due to invalid traffic during congestion, avoiding confusion with regular drop behavior in non-congested states.

[0047] S300: In congested conditions, according to the budget quantity corresponding to the enhancement value, read the frames to be processed from the receive buffer to perform ingress port rule matching, and based on the matching result, selectively perform congestion-priority discarding or transmit based on the output port bitmap of the frames to be processed.

[0048] In this embodiment, since the buffer level has exceeded the threshold and new packets are still being received under congested conditions, if all frames in the buffer are forwarded or discarded indiscriminately, critical control packets with configured routes may be delayed or even discarded due to their later queuing order, while invalid frames that do not match the rules and do not need to be forwarded occupy buffer space. Therefore, this embodiment adopts a differentiated processing strategy based on rule matching results: read the frames to be processed from the buffer header according to the budget quantity corresponding to the enhancement value, perform ingress port rule matching on each frame, and determine its final processing method based on the matching results: frames that match the rules belong to legitimate traffic with a clear forwarding target, are retained, and forwarded according to the output port bitmap; frames that do not match the rules belong to invalid traffic without a forwarding target, and are preferentially discarded under congested conditions, thereby prioritizing the release of limited processing capacity and buffer space to critical packets with configured rules. Specifically, refer to Figure 5 As shown, step S300 may include the following steps S310 to S330: S310: Read the number of frames to be processed sequentially from the header of the receive buffer, which is limited by the enhancement value.

[0049] Furthermore, the main loop starts from the header of the receive buffer that triggered the congestion state and reads the message frames to be processed in the order indicated by the header pointer. The number of frames read is limited by the enhancement value determined in step S220a. For example, if the enhancement value is 16, then a maximum of 16 frames will be read from the buffer for processing in this round. Sequential reading ensures that the messages in the buffer are processed in a first-in, first-out order, avoiding the situation where some frames are backed up in the buffer for a long time due to skipped readings and cannot be processed.

[0050] S320. Perform entry port rule matching for each frame to be processed that is read.

[0051] S330a. If the frame to be processed does not match any pre-configured rule, the frame is released and the congestion-priority drop count is incremented.

[0052] S330b: If the frame to be processed matches a pre-configured rule, an output port bitmap is generated based on the matching result, and the frame to be processed is handed over to the transmitter for transmission.

[0053] Furthermore, after the frame to be processed is handed over to the transmitter for transmission, reference Figure 6 As shown, it also includes steps S341 to S343: S341. During the transmission process, if some output ports in the output port bitmap are successfully transmitted while the rest fail to be transmitted, the corresponding buffer entry of the frame to be processed in the receive buffer is retained, and the output port bits that have been successfully transmitted are cleared, while only the output port bits that have not been successfully transmitted are retained.

[0054] S342. Within the set limit of retries, attempt to send the buffered item to the output port that failed to send.

[0055] S343a. If the number of retries does not exceed the limit and the retry is successful, then release the cached item.

[0056] S343b: If the number of retries exceeds the limit, release the buffer entries and increment the transmission failure count.

[0057] For example, if the retry count is set to 3, and more than 3 retries have been attempted but some ports still fail to send, it indicates that these ports may be experiencing persistent failures or prolonged periods of high traffic. Continuing to retain the cached entry is pointless and would only consume cache space. Therefore, in this case, further retries should be abandoned, the cached entry released, and the transmission failure count incremented by 1. This count records the number of times transmissions were abandoned due to exceeding the retry limit, and can be used for remote diagnostic analysis of the health status of specific ports.

[0058] It is worth noting that the dropping in step S130 is a passive dropping in the interrupt context, which is fundamentally different from the active congestion-priority dropping in the main loop context: the former occurs when the cache is full and is executed by the interrupt service routine, representing a last resort of passive packet dropping; the latter occurs in the early warning stage when the cache level exceeds the threshold and is executed by the main loop, representing proactive packet dropping with early intervention. The combination of the two allows for both protecting the cache from overflow under extreme overload conditions and proactively releasing invalid packets in the early stages of congestion to delay or even prevent the cache from filling up, thus achieving a better congestion management effect.

[0059] S400. In the Ethernet receive interrupt service routine, perform frame parsing operations for a preset budget number. If there are still unprocessed frames in the MAC layer, set a pending flag to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget.

[0060] In this embodiment, because the communication rate of the Ethernet port is much higher than that of the CAN port, under the same traffic density, the number of receive interrupts generated by the Ethernet port per unit time is much higher than that of the CAN port. If the Ethernet receive interrupt service routine reads and processes all the frames to be processed in the MAC layer hardware receive descriptor ring at once, then in the event of a broadcast storm or a sudden large-volume UDP attack, the interrupt service routine may continue to run for several milliseconds or even tens of milliseconds. This causes the CPU to be in the interrupt context for a long time and unable to perform critical tasks such as message forwarding, maintenance tasks, and watchdog feeding in the main loop, ultimately leading to watchdog reset, CAN scan starvation, and other faults. Therefore, this embodiment adopts a mechanism that combines interrupt budget limitation with main loop continuation processing: the number of frames processed by the Ethernet receive interrupt service routine at one time is strictly limited to the preset budget number to ensure that the interrupt service routine returns within a fixed time period; when there are still backlogged frames in the MAC layer, the interrupt is exited after only setting the pending flag, and the main loop continues to process them in batches according to the same budget in the non-interrupt context, thereby transferring the processing pressure of sudden traffic from the interrupt context to the task context, which not only ensures the complete reception of sudden frames, but also prevents the interrupt from occupying the CPU for a long time. Specifically, refer to Figure 7 As shown, step S400 may include the following steps S410 to S450: S410. When an Ethernet receive interrupt is triggered, enter the Ethernet receive interrupt service routine.

[0061] Furthermore, when the Ethernet MAC controller receives one or more Ethernet frames and writes them to the receive descriptor ring, the MAC controller sends an Ethernet receive interrupt request to the MCU's CPU. Upon responding to the interrupt, the CPU jumps to the pre-registered Ethernet receive interrupt service routine (Ethernet Rx ISR) and begins executing the interrupt handling logic. The current CPU context is automatically saved upon entering the interrupt service routine and restored upon exiting the interrupt service routine.

[0062] S420. In the Ethernet receive interrupt service routine, with a preset budget quantity as the upper limit for processing in a single operation, unprocessed frames are read sequentially from the MAC layer, and frame parsing operations are performed.

[0063] Furthermore, the preset budget quantity is a configurable parameter, typically set to 4 to 16 frames in typical automotive gateway applications. The MAC layer is the receive descriptor ring or receive FIFO queue within the Ethernet MAC controller, storing Ethernet frames that have been received from the physical medium and verified by the MAC layer hardware, awaiting software reading and processing. Frame parsing operations include frame header verification, length checking, and protocol type parsing.

[0064] S430. After each frame is successfully parsed, the remaining budget is reduced until the number of parsed frames reaches the preset budget or there are no unprocessed frames remaining in the MAC layer.

[0065] S440. If there are still unprocessed frames in the MAC layer after the frame parsing operation of the preset budget number is completed, set the pending flag and exit the current interrupt service routine.

[0066] Furthermore, when the parsing loop exits due to reaching the preset budget number of parsed frames, but there are still unprocessed frames remaining in the MAC layer, it indicates that a large amount of burst traffic is continuously arriving, and the processing budget for this round of interrupts has been exhausted. At this point, the interrupt service routine cannot continue processing the remaining frames in the interrupt context, otherwise it will occupy the CPU for a long time. Therefore, the program sets a global pending flag to record the state that there are still backlogged frames to be processed in the Ethernet MAC layer, and then exits the current interrupt service routine and returns to the interrupted task.

[0067] S450. In subsequent iterations of the main loop, when the pending flag is detected to be set, the backlog of frames in the MAC layer continues to be processed in batches according to the preset budget number in the non-interrupt context until all the backlog of frames in the MAC layer has been processed and the pending flag is cleared.

[0068] Furthermore, in each iteration of the main loop, in addition to performing packet filtering and forwarding tasks, it is also necessary to check whether the aforementioned pending flag is set. When the pending flag is detected to be set, it indicates that there are unprocessed backlog frames remaining from previous interrupts in the Ethernet MAC layer. At this time, the main loop calls the same frame reading and parsing logic as the interrupt service routine in the non-interrupt context, and similarly uses a preset budget quantity as the upper limit for processing in a single run, reading the remaining frames from the MAC layer in batches and performing frame parsing.

[0069] In this embodiment, a round-robin scheduling method for maintenance tasks is adopted, with only one maintenance task executed per cycle. This reduces the concentrated impact of periodic maintenance tasks such as ADC protection detection, PHY link detection, CAN bus recovery, and Ethernet recovery on message forwarding latency, thus improving the jitter characteristics of forwarding latency. Furthermore, high-water mark, congestion event count, congestion-priority drop count, and port drop count are incorporated into remotely readable diagnostic information. This allows external devices to remotely obtain key status parameters of the gateway operation through the diagnostic interface, facilitating rapid on-site assessment of whether the ingress port rule configuration is reasonable and / or whether there are abnormalities in network traffic. This improves the system's diagnosticability and maintainability, and reduces the operation and maintenance costs after the on-site deployment of the vehicle gateway. Specifically, the following steps S500 and S600 are implemented.

[0070] S500: During the main cycle, multiple preset maintenance tasks are arranged in a round-robin manner. Only one maintenance task is executed in each maintenance cycle. The maintenance tasks include analog-to-digital conversion protection task, physical layer link detection task, CAN bus recovery task, and Ethernet recovery task.

[0071] Furthermore, multiple maintenance tasks are arranged in a round-robin fashion to form a maintenance task round-robin queue, and a round-robin pointer is maintained, initially pointing to the first task in the queue. At the end of each maintenance cycle (e.g., every 25ms), the maintenance task currently pointed to by the round-robin pointer is executed. After execution, the pointer moves to the next task in the queue. After the task at the end of the queue is completed, the pointer returns to the first task, forming a loop. Through round-robin scheduling, each maintenance task is executed at a preset cycle, but the execution time of any single maintenance cycle is only the execution time of one task, not the sum of all tasks, significantly reducing the impact on forwarding latency.

[0072] S600 incorporates the high-water mark of the receive buffer, congestion event count, congestion-priority drop count, and port drop count into remotely readable diagnostic information, so that external devices can determine the rationality of the ingress port rule configuration and / or the abnormal state of network traffic by reading the remotely readable diagnostic information.

[0073] Furthermore, the key diagnostic data collected and accumulated during operation is organized into remotely readable diagnostic information for external devices to read through diagnostic interfaces, such as vehicle diagnostic tools and telematics platforms. This diagnostic information includes: a high-water mark in the receive buffer, used to assess whether the buffer capacity configuration meets peak traffic requirements; congestion event counts, used to determine whether the traffic load exceeds the gateway's design capacity; a congestion-priority drop count, reflecting the number of frames actively dropped due to lack of rule matching during congestion; if this count is high while the port drop count is low, it indicates that a large amount of invalid traffic has not been filtered in advance, and the rule configuration may be incomplete; and a port drop count, reflecting the number of frames passively dropped by each port due to full buffers; if this count is high, it indicates insufficient buffer capacity configuration or abnormal traffic. The diagnostic interface includes any one of the following: the UDS protocol on the vehicle diagnostic interface, the DoIP protocol on Ethernet, or the UDS diagnostic protocol on CAN.

[0074] Furthermore, this invention also proposes a congestion-aware buffer scheduling system for a multi-port vehicle gateway, comprising: The receive buffer configuration and message writing module is used to configure both the CAN port and Ethernet port in the vehicle gateway as fixed-length receive buffers, and to write the received messages into the corresponding receive buffers through receive interrupt or callback service routines.

[0075] The congestion detection and budget adjustment module is used to determine that the vehicle gateway has entered a congestion state when the water level of any receive buffer exceeds the preset congestion threshold during the main loop, and to increase the budget of the current round of rule filtering from the normal value to the enhanced value.

[0076] The rule matching and scheduling processing module is used to read frames to be processed from the receive buffer in the state of congestion according to the budget quantity corresponding to the enhancement value to perform ingress port rule matching, and selectively perform congestion-priority discarding or transmission based on the output port bitmap based on the matching result.

[0077] The Ethernet interrupt budget processing module is used to perform frame parsing operations with a preset budget number in the Ethernet receive interrupt service routine. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget.

[0078] Furthermore, this invention also proposes a multi-port vehicle gateway, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the processor, and the processor executes the instructions to implement the congestion-aware buffer scheduling method for a multi-port vehicle gateway described above.

[0079] In summary, the congestion-aware buffer scheduling method and system for multi-port vehicle gateways proposed in this invention firstly avoids memory fragmentation and uncontrollable queuing latency increases caused by dynamic memory allocation by configuring a fixed-length receive buffer for each port in the vehicle gateway. Secondly, by real-time monitoring of the receive buffer level in the main loop and dynamically increasing the rule filtering budget from a normal value to an enhanced value when the level exceeds a preset congestion threshold, proactive prediction and early intervention scheduling before congestion occurs are achieved, avoiding the problem of passively and indiscriminately discarding packets only after the buffer is full. Thirdly, in congested conditions, frames that do not match pre-configured rules are preferentially discarded, while frames that match rules are forwarded normally according to the output port bitmap. This ensures that limited buffer space and processing capacity prioritize serving critical control packets with configured routes, improving the retention probability of critical traffic and the success rate of cross-port forwarding. Furthermore, by limiting the processing load of the Ethernet receive interrupt service routine to a preset budget, and by setting a pending flag and exiting the interrupt when there are still backlogged frames at the MAC layer, allowing the main loop to process them in batches in a non-interrupt context, the problem of the interrupt service routine occupying the CPU for a long time and being unable to return due to broadcast storms or sudden UDP traffic is effectively prevented. Then, by using a round-robin scheduling method for maintenance tasks, the maintenance tasks are distributed to different periods for execution, reducing the concentrated impact of maintenance tasks on packet forwarding latency. Finally, by incorporating high-water mark, congestion event count, congestion-priority drop count, and port drop count into remotely readable diagnostic information, external devices can remotely obtain key status parameters of the gateway operation, facilitating rapid on-site judgment of the rationality of rule configuration and abnormal network traffic conditions.

[0080] Since the systems / devices described in the above embodiments of the present invention are systems / devices used to implement the methods of the above embodiments of the present invention, those skilled in the art can understand the specific structure and modifications of the systems / devices based on the methods described in the above embodiments of the present invention, and therefore will not be repeated here. All systems / devices used in the methods of the above embodiments of the present invention fall within the scope of protection of the present invention.

[0081] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, as well as combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions.

[0083] It should be noted that in the description of this invention, the words "a" or "an" preceding a component do not exclude the existence of multiple such components. This invention can be implemented by means of hardware comprising several different components and by means of a suitably programmed computer. The use of terms such as "first," "second," "third," etc., is merely for convenience and does not indicate any order. These terms can be understood as part of the component names.

[0084] Furthermore, it should be noted that in the description of this specification, the terms "one embodiment," "some embodiments," "embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0085] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning of the basic inventive concept, can make other changes and modifications to these embodiments.

[0086] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from the spirit and scope of the invention.

Claims

1. A congestion-aware buffer scheduling method for a multi-port vehicle gateway, characterized in that, include: Both the CAN port and Ethernet port in the vehicle gateway are configured with fixed-length receive buffers, and the received messages are written into the corresponding receive buffers through receive interrupt or callback service routines. During the main loop, when the water level of any receiving buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to the enhanced value. In a congested state, according to the budget quantity corresponding to the enhancement value, the frames to be processed are read from the receive buffer to perform ingress port rule matching, and based on the matching results, the frames to be processed are selectively discarded with congestion priority or sent based on the output port bitmap. In the Ethernet receive interrupt service routine, a preset budget of frame parsing operations are performed. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget.

2. The method as described in claim 1, characterized in that, Both the CAN port and Ethernet port in the vehicle gateway are configured with fixed-length receive buffers, and the received messages are written into the corresponding receive buffers through receive interrupts or callback service routines, including: Both the CAN port and Ethernet port in the vehicle gateway are configured as fixed-length receive buffers. Each receive buffer maintains a head pointer, a tail pointer, the current number, a lock state, a port output bitmap, a retransmission count, and a diagnostic count. The diagnostic counts include port drop count, high-water mark, congestion event count, congestion drop count, Ethernet receive backlog count, and transmit failure count. The received message is written to the receive buffer of the corresponding port by receiving interrupt or callback service routine; When the current number of packets in the receive buffer reaches a fixed length, the packet is discarded and the receive drop count is incremented by the source port.

3. The method as described in claim 1, characterized in that, When the water level of any receive buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to an enhanced value, including: During the main loop, the current water level information of the receiving cache is obtained; When the water level of any receive buffer exceeds the preset congestion threshold, the vehicle gateway is determined to be in a congested state, and the budget for this round of rule filtering is increased from the normal value to the enhanced value. When the water level of any receive buffer does not exceed the preset congestion threshold, the vehicle gateway is determined to be in a non-congested state, and ingress port rule matching is performed according to the budget number limited by the normal value. In a non-congestion state, if a frame to be processed read from the receive buffer does not match any pre-configured rule, the frame is released without increasing the congestion-priority drop count.

4. The method as described in claim 1, characterized in that, In congested conditions, according to the budgeted quantity corresponding to the enhancement value, frames to be processed are read from the receive buffer to perform ingress port rule matching, and based on the matching results, frames to be processed are selectively either congestion-prioritized dropped or transmitted based on the output port bitmap, including: Read the number of frames to be processed sequentially from the header of the receive buffer, as specified by the enhancement value; Perform ingress port rule matching on each frame to be processed. If the frame to be processed does not match any pre-configured rule, the frame is released and the congestion-priority drop count is incremented; If the frame to be processed matches a pre-configured rule, an output port bitmap is generated based on the matching result, and the frame to be processed is handed over to the transmitter for transmission.

5. The method as described in claim 4, characterized in that, Ingress port rule matching includes: Obtain the ingress port identifier and frame header feature fields of the frame to be processed; The ingress port identifier and frame header feature fields are compared with each rule in the pre-configured rule list; If all pre-configured rules fail to match, the rule is considered not to match. If any pre-configured rule is successfully matched, it is determined to be a match, and the output port information corresponding to that rule is obtained.

6. The method as described in claim 4, characterized in that, After the frame to be processed is handed over to the transmitter for transmission, the following steps are also included: During transmission, if some output ports in the output port bitmap are successfully transmitted while the rest fail to be transmitted, the corresponding buffer entry of the frame to be processed in the receive buffer is retained, and the output port bits that have been successfully transmitted are cleared, leaving only the output port bits that have not been successfully transmitted. Within the set limit of retries, the cached item will be sent to the output port that failed to send. If the number of retries does not exceed the limit and the retry is successful, then the buffer item is released; If the number of retries exceeds the limit, the buffer entry is released and the send failure count is incremented.

7. The method as described in claim 1, characterized in that, In the Ethernet receive interrupt service routine, a preset budget of frame parsing operations are performed. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget. These include: When an Ethernet receive interrupt is triggered, the Ethernet receive interrupt service routine is entered. In the Ethernet receive interrupt service routine, with a preset budget as the upper limit for processing in a single session, unprocessed frames are read sequentially from the MAC layer and frame parsing operations are performed. Each time a frame is successfully parsed, the remaining budget is reduced until the number of parsed frames reaches the preset budget or there are no unprocessed frames remaining in the MAC layer. If the MAC layer still has unprocessed frames after the frame parsing operation of the preset budget number is completed, the pending flag is set and the current interrupt service routine is exited. In subsequent iterations of the main loop, when the pending flag is detected to be set, the backlog of frames in the MAC layer continues to be processed in batches according to the preset budget number in a non-interruptible context until all the backlog of frames in the MAC layer has been processed and the pending flag is cleared.

8. The method as described in claim 1, characterized in that, Also includes: During the main cycle, multiple preset maintenance tasks are arranged in a round-robin manner, with only one maintenance task executed in each maintenance cycle. The maintenance tasks include analog-to-digital conversion protection task, physical layer link detection task, CAN bus recovery task, and Ethernet recovery task. In addition, the high-water mark of the received buffer, congestion event count, congestion-priority drop count and port drop count are included in the remotely readable diagnostic information, so that external devices can determine the rationality of the ingress port rule configuration and / or the abnormal state of network traffic by reading the remotely readable diagnostic information.

9. A congestion-aware buffer scheduling system for a multi-port vehicle-mounted gateway, characterized in that, include: The receive buffer configuration and message writing module is used to configure both the CAN port and Ethernet port in the vehicle gateway as a fixed-length receive buffer, and to write the received messages into the corresponding receive buffer through the receive interrupt or callback service program. The congestion detection and budget adjustment module is used to determine that the vehicle gateway has entered a congestion state when the water level of any receiving buffer exceeds the preset congestion threshold during the main loop, and to increase the budget of the rule filtering in this round from the normal value to the enhanced value. The rule matching and scheduling processing module is used to read frames to be processed from the receive buffer in the state of congestion according to the budget quantity corresponding to the enhancement value to perform ingress port rule matching, and selectively perform congestion-priority discarding or transmission based on the output port bitmap based on the matching result. The Ethernet interrupt budget processing module is used to perform frame parsing operations with a preset budget number in the Ethernet receive interrupt service routine. If there are still unprocessed frames in the MAC layer, a pending flag is set to remind the main loop to continue processing the backlog of frames corresponding to the pending flag in subsequent rounds according to the budget.

10. A multi-port vehicle gateway, characterized in that, include: At least one processor; and memory that is communicatively connected to at least one processor; The memory stores instructions that can be executed by the processor, and when the processor executes the instructions, it implements the congestion-aware buffer scheduling method for a multi-port vehicle gateway as described in any one of claims 1-7.

Images