Vehicle networking event-oriented roadside wired dynamic qos guarantee method and system

Abstract

The present application relates to the field of multi-modal network and Internet of Vehicles communication technology, in particular to a roadside wired dynamic QoS guarantee method and system for Internet of Vehicles events, by deploying SDN controller and supporting OpenFlow protocol switch at roadside, using IPv6 extension header TLV field to carry V2X event mapping information, by software programming, the SDN controller automatically generates QoS strategy and issues to the switch to execute, thereby providing deterministic communication guarantee for Internet of Vehicles mode in multi-modal network environment, and providing specific technical verification instance for multi-modal network QoS software programmable characteristics, the present application deeply fuses SDN centralized control and roadside real-time sensing, realizes millisecond-level dynamic response of QoS strategy to traffic events, provides data basis for network fine scheduling, improves network overall resource utilization, and can realize automatic deletion of temporary high-priority flow table item after the event ends and automatic recovery of network resources.

Description

Technical Field

[0001] This invention relates to the field of multimodal network and vehicle-to-everything (V2X) communication technology, and in particular to a roadside wired dynamic QoS guarantee method and system for V2X events. Background Technology

[0002] Multimodal networking is a novel network architecture. Its core idea is to enable the coexistence and collaborative operation of multiple network modalities on a single physical infrastructure network through software-defined and dynamically programmable technologies. Among the key technical characteristics defined by multimodal networking, the software-definable and programmable nature of QoS (Quality of Service) is a core capability—it requires that network service quality policies be able to break free from dependence on static hardware configurations and instead be dynamically generated and adjusted in real time through software programming. However, this characteristic currently remains largely theoretical, lacking concrete application scenarios for verification and programmable implementation solutions.

[0003] In V2X communication systems, static QoS configuration schemes are typically used to ensure priority transmission of safety-related messages. Network administrators pre-configure fixed classification and labeling policies on roadside switches, for example, mapping packets with a DSCP value of EF to the highest priority queue and packets with a DSCP value of AF to the second-highest priority queue. This configuration is written once and remains unchanged over time.

[0004] In traditional QoS assurance solutions for connected vehicles, network administrators need to manually log in to each switch and input classification rules and queue mapping commands one by one through the command-line interface to embed the QoS policy into the hardware. When a traffic incident occurs, the administrator cannot modify the embedded policy in real time through software programming; after the incident, the temporary configuration cannot be automatically reclaimed. The entire lifecycle management of the QoS policy relies entirely on manual operation and lacks software programmability. The QoS policy is pre-set and fixed, and cannot be dynamically adjusted according to sudden real-time traffic events (such as ambulance approach, traffic accidents, pedestrian crossings, etc.). When an emergency occurs, related V2X collaborative messages share the same network resources as ordinary messages, and deterministic communication guarantees cannot be obtained. Static configuration usually applies a "one-size-fits-all" approach to all V2X services, and cannot generate dedicated QoS assurance rules for specific vehicles and specific events, resulting in valuable network resources not being used accurately. In the traditional architecture, the roadside perception system (cameras, radar) and the network configuration system are independent of each other. The perceived emergency events require manual intervention to be converted into network policies, resulting in slow response speeds and difficulty in meeting the millisecond-level latency requirements of connected vehicles. Existing solutions mostly rely on the fixed DSCP field in the IP header (only 6 bits, with a maximum of 64 priority levels), which cannot carry rich event semantic information (such as event type, vehicle identity, validity period, etc.), resulting in the network being unable to achieve fine-grained differentiated services. Staticly configured QoS policies are effective for a long time, occupying queue resources even during network idle periods, and cannot be automatically adjusted and reclaimed according to the event lifecycle, resulting in low network resource utilization. Summary of the Invention

[0005] To address the issues of existing V2X communication systems relying on manual static configuration of QoS policies, lacking software programmability, and being unable to dynamically respond to real-time traffic events, this invention provides a roadside wired dynamic QoS assurance method and system oriented towards V2X events. By encapsulating traffic event information into the TLV field of the IPv6 extension header, the SDN controller automatically generates and distributes QoS policies based on event type through software programming. The switch performs event-driven priority scheduling, thereby providing deterministic communication guarantees for V2X modes in a multimodal network environment. At the same time, it provides a concrete technical verification example for the software programmable characteristics of multimodal network QoS.

[0006] According to the design scheme provided by the present invention, on the one hand, a method for roadside wired dynamic QoS guarantee system oriented towards vehicle-to-everything (V2X) events is provided, comprising:

[0007] Real-time traffic event information is encapsulated into the TLV field of the IPv6 extension header and mapped to V2X event TLV, so that the SDN controller can generate QoS policies based on the traffic event type and send them to the SDN switch through flow tables.

[0008] SDN switches perform traffic event-driven priority scheduling based on flow tables and automatically reclaim network resources after a traffic event ends.

[0009] As a roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to the present invention, the real-time sensed traffic event information is further encapsulated into the TLV field of the IPv6 extension header, including:

[0010] The current traffic events and their corresponding priorities on the roadside are perceived based on real-time data from multiple sources of sensors, including roadside cameras and radar.

[0011] If the current traffic event priority meets the preset reporting conditions, an event notification message is generated and sent to the SDN controller. At the same time, the current traffic event information is mapped to a V2X event TLV, and the V2X event TLV is inserted into the IPv6 packet extension header so that the encapsulated IPv6 packet can be sent to the SDN switch.

[0012] As a roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to the present invention, the V2X event TLV further includes: a V2X event emergency type identifier field, a length field, an event type encoding field, a vehicle identifier field that triggered the event, an event location encoding field, and an event validity period field.

[0013] As a roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to the present invention, the SDN controller further generates a QoS policy based on the traffic event type and distributes it to the SDN switch via a flow table, including:

[0014] Based on the event notification message, the corresponding QoS policy parameters are matched from the QoS policy mapping table, which pre-stores the mapping relationship between traffic event types and QoS policy parameters;

[0015] QoS policies are generated based on QoS policy parameters, and the QoS policies are converted into Flow-Mod messages in OpenFlow protocol format and sent to SDN switches through flow tables.

[0016] As a roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to the present invention, the flow table structure further includes: a matching field for identifying data packet characteristics, a priority field for indicating the matching priority of flow table entries, an instruction behavior field for indicating the operation to be performed on the matched data packet, a hard timeout field for indicating the lifespan of the flow table entry, and an idle timeout field for indicating the idle time of the flow table entry.

[0017] As a roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to the present invention, the SDN switch further performs traffic event-driven priority scheduling based on flow tables, including:

[0018] Parse the TLV field in the IPv6 packet extension header and obtain the traffic event priority based on the flow table;

[0019] Traffic event-driven priority queue scheduling is performed based on the priority of traffic events.

[0020] As a roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to the present invention, further, automatically reclaiming network resources after a traffic event ends includes:

[0021] A timeout timer is used to count down the time. When the timeout period is reached, the current flow table is set to automatically expire and be deleted, and the QoS scheduling policy of the SDN switch is restored to the default state.

[0022] Furthermore, this invention also provides a roadside wired dynamic QoS guarantee system for vehicle-to-everything (V2X) events, comprising: a sensor module, a roadside computing unit, a roadside publishing unit, and an SDN switch connected to an SDN controller, wherein the SDN controller is deployed in a regional cloud.

[0023] The sensor module is used to collect real-time roadside data based on sensors, including cameras and radar.

[0024] The roadside computing unit is used to fuse real-time roadside data, use a preset algorithm to sense current traffic events on the roadside, encapsulate the real-time sensed traffic event information into the TLV field of the IPv6 extension header, and map the traffic event information into V2X event TLV, so that the SDN controller can generate QoS policies according to the traffic event type and send them to the SDN switch through the flow table.

[0025] Roadside broadcasting units are used to broadcast V2X event information to vehicles;

[0026] SDN switches perform traffic event-driven priority scheduling based on flow tables and automatically reclaim network resources after a traffic event ends.

[0027] The beneficial effects of this invention are:

[0028] 1. In a multimodal network environment, this invention comprises a three-layer architecture: a roadside sensing layer (RSCU, responsible for event perception and TLV encapsulation), an SDN control layer (controller, responsible for software programming generation of QoS policies and flow table distribution, internally containing policy mapping tables and flow table programming modules), and a data plane layer (SDN switch, responsible for TLV matching and QoS execution). On a shared physical link for multimodal communication, it achieves a closed-loop system from physical world event perception to network layer QoS policy software definition programming, dynamic distribution, hardware execution, and automatic lifecycle management, without affecting the overall system design of default resource allocation policies for other modes. The entire process is event-driven and fully automated, eliminating the delays and errors of manual configuration. Using vehicle-to-everything (V2X) communication as a typical verification scenario, it demonstrates the core capability of dynamically defined, real-time programmed, and automatically deployed QoS policies in multimodal networks. Deeply integrating SDN centralized control with real-time roadside perception, it achieves millisecond-level dynamic response of QoS policies to traffic events, solving the technical challenge of traditional static QoS configuration being unable to adapt to dynamic traffic scenarios. By using the TLV field in the IPv6 extension header to carry rich semantic information such as event type and vehicle identity, SDN switches can generate dedicated fine-grained flow tables for specific events (such as a specific ambulance at a certain intersection), giving priority to only that specific data flow, thus achieving precise allocation of network resources.

[0029] 2. The Roadside Computing Unit (RSCU) of this invention utilizes the programmable message processing capabilities of multimodal network edge elements to act as a message encapsulation gateway. It maps traffic events identified by the V2X application layer into structured TLVs containing fields such as Type, Event ID, Vehicle ID, Location ID, and Event TTL, and inserts them into the IPv6 extension header. Leveraging the variable-length nature of the TLV, it carries multi-dimensional information such as event type, vehicle ID, location, and validity period, providing a data foundation for fine-grained network scheduling. The SDN controller, based on the traffic event type, automatically queries the policy mapping table and generates OpenFlow flow table entries through software programming. The matching field is specified as a specific field in the V2X event TLV within the IPv6 extension header, and the entry is distributed to switches in the affected area via a standardized API call through the southbound interface. The Hard Timeout of the flow table entry matches the Event TLV in the V2X event TLV. The TTL field is linked, and the temporary flow table is automatically deleted after the event ends, so that network resources are reclaimed in a timely manner, improving the overall resource utilization of the network. The software defines the policy lifespan in the program when generating the policy, so as to realize the automatic deletion of temporary high-priority flow table entries and the automatic reclamation of network resources after the event ends. Attached Figure Description

[0030] Figure 1This is a schematic diagram of the roadside wired dynamic QoS guarantee process for vehicle-to-everything (V2X) events in the embodiment.

[0031] Figure 2 This is a schematic diagram of the dynamic QoS guarantee architecture for vehicle-to-everything (V2X) events in a multimodal network, as illustrated in the embodiment.

[0032] Figure 3 This is a schematic diagram of the flow table structure in the embodiment;

[0033] Figure 4 This is a schematic diagram illustrating the principle of the dynamic QoS guarantee algorithm for vehicle-to-everything (V2X) events in a multimodal network implementation example. Detailed Implementation

[0034] To make the objectives, technical solutions, and advantages of this invention clearer and more understandable, the invention will be further described in detail below with reference to the accompanying drawings and technical solutions.

[0035] Multimodal networking is a novel network architecture. Its core idea is to enable the coexistence and collaborative operation of multiple network modes on a single physical infrastructure network through software-defined and dynamically programmable technologies. Among the many key technical characteristics defined by multimodal networks, the software-definable and programmable nature of QoS is a core capability. It requires that network service quality policies be able to break free from dependence on static hardware configurations and instead be dynamically defined and adjusted in real time according to changes in the service requirements within each mode through software programming.

[0036] However, the definable and programmable characteristics of QoS software currently remain largely theoretical, lacking concrete application scenarios for verification and technical implementation solutions. Vehicle-to-everything (V2X) communication, as a typical network mode in multimodal networks carrying safety and efficiency messages between vehicles and roadside infrastructure, provides an ideal application scenario for verifying this characteristic. In scenarios such as urban intersection collaborative scheduling and autonomous driving, emergency messages typically require communication latency to be controlled within 10 milliseconds. When high-priority traffic events occur, the network needs to respond rapidly, temporarily providing higher quality-of-service guarantees for relevant data streams—this is precisely the typical requirement of the definable and programmable characteristics of QoS software.

[0037] Software-defined networking (SDN) is one of the key enabling technologies for achieving software-defined and dynamically programmable characteristics in multimodal networks. Multimodal networks inherently utilize the centralized control capabilities of SDN, allowing various network modes operating on them to dynamically adjust resource allocation through software programming. This invention, within the framework of multimodal network architecture, leverages the programmable management capabilities of SDN to verify the feasibility of QoS software programmability, using vehicular network communication as a specific example.

[0038] In this embodiment of the invention, the specific manifestations of QoS software programmability include the following three aspects:

[0039] (1) Software-programmable policy generation: The components of the QoS policy (which data flows to match, what priority to assign, how much bandwidth to guarantee, and how long to last) are all described and stored by the software data structure (policy mapping table). When a traffic event is triggered, the SDN controller's control program automatically queries the mapping table and automatically constructs the corresponding QoS policy parameters through code, without the need for manual configuration.

[0040] (2) Software programmable policy deployment: The SDN controller automatically converts the generated QoS policy into Flow-Mod messages in the OpenFlow protocol format through code, and sends them to the switch in the form of standardized API calls. In essence, it is real-time software programming of the switch forwarding pipeline.

[0041] (3) Software programmable policy lifecycle: The software not only defines the triggering conditions of the QoS policy, but also programmatically defines the policy's lifespan (Hard Timeout). After the expiration, the flow table automatically expires and is deleted, which is equivalent to setting an automatic destructor function for each temporary QoS policy, realizing software programmable management of the entire lifecycle.

[0042] It should be noted that in a multimodal network environment, the vehicle-to-everything (V2X) communication mode shares the same roadside wired backhaul network bandwidth resources with other network modes such as video surveillance and IoT. The dynamic QoS policy guaranteed by this embodiment of the invention temporarily allocates a higher transmission priority to the V2X mode on the shared physical link between the multimodal networks. This solution fully utilizes the inherent characteristics of multimodal networks—software-defined and dynamically programmable—to achieve fine-grained scheduling of data flows within the V2X mode through software programming via an SDN controller, without affecting the default resource allocation strategies of other modes.

[0043] The Roadside Computing Unit (RSCU), acting as a packet encapsulation gateway, identifies high-priority traffic events and maps information such as the event type, vehicle identity, and validity period into a set of structured parameters, encapsulating them into the Type-Length-Value (TLV) field of the IPv6 packet's extension header. The SDN controller dynamically generates corresponding QoS policies based on the event type and sends flow table entries matching the TLV field to the switch via the OpenFlow protocol. The switch then performs high-priority queue scheduling on IPv6 packets carrying emergency event information based on the flow table, ensuring deterministic communication.

[0044] Specifically, such as Figure 1As shown in the embodiment of this case, a roadside wired dynamic QoS guarantee system method for vehicle-to-everything (V2X) events includes:

[0045] S101. Encapsulate the real-time traffic event information into the TLV field of the IPv6 extension header and map the traffic event information to a V2X event TLV so that the SDN controller can generate QoS policies based on the traffic event type and send them to the SDN switch through the flow table.

[0046] Specifically, the system perceives current traffic events and their corresponding priorities on the roadside based on real-time data from multiple sensors, including roadside cameras and radar. If the priority of the current traffic event meets the preset reporting conditions, an event notification message is generated and sent to the SDN controller. At the same time, the current traffic event information is mapped to a V2X event TLV, and the V2X event TLV is inserted into the IPv6 packet extension header to send the encapsulated IPv6 packet to the SDN switch.

[0047] The V2X event TLV includes: V2X event emergency type identifier field, length field, event type code field, vehicle identifier field that triggered the event, event location code field, and event validity period field.

[0048] The SDN controller matches the corresponding QoS policy parameters from the QoS policy mapping table based on the event notification message. The QoS policy mapping table stores the mapping relationship between traffic event types and QoS policy parameters in advance. The controller generates a QoS policy based on the QoS policy parameters, converts the QoS policy into a Flow-Mod message in OpenFlow protocol format, and sends it to the SDN switch through the flow table.

[0049] The flow table structure includes: a matching field for identifying packet characteristics, a priority field for indicating the matching priority of the flow table entry, an instruction behavior field for indicating the operation to be performed on the matched packet, a hard timeout field for indicating the lifespan of the flow table entry, and an idle timeout field for indicating the idle time of the flow table entry.

[0050] like Figure 2 As shown, the multimodal network infrastructure layer is a software layer that orchestrates hardware resources, and its core components include:

[0051] 1) SDN Controller: The core orchestration engine, responsible for centralized management and dynamic flow table distribution of SDN switches in the data plane layer through the southbound interface (OpenFlow protocol), and providing programmable call capabilities to the upper-layer SDN control layer through the northbound interface (REST API).

[0052] 2) Resource abstraction and programmable interface: The forwarding and computing capabilities of underlying physical network resources (switches, computing nodes, etc.) are abstracted into standardized APIs.

[0053] 3) Multimodal management module: responsible for identifying and distinguishing traffic of different network modes, and providing an independent resource allocation view for each mode.

[0054] Vehicle-to-everything (V2X) communication, video surveillance, and Internet of Things (IoT) modes all run on the programmable infrastructure provided by this software layer, sharing the bandwidth resources of the roadside wired backhaul network. In this embodiment of the invention, the SDN programmable management capabilities of this layer are directly utilized. The SDN control layer calls the APIs exposed by this layer through the northbound interface to implement dynamic QoS scheduling of data streams within the V2X mode through software programming. On physical links shared with other modes, higher transmission priority is temporarily allocated to the V2X mode, thereby verifying the core characteristics of multimodal network QoS software being definable and programmable.

[0055] Roadside perception layer: This layer comprises sensors such as cameras, millimeter-wave radar, and lidar deployed at intersections, as well as roadside computing units (RSCUs) responsible for multi-source data fusion and event recognition. The RSCU acts as both the "sensor" and the "reporter" of events. In a multimodal network architecture, edge network elements (such as RSCUs) possess software-programmable packet processing capabilities, enabling them to dynamically construct and encapsulate data packets according to upper-layer service requirements. In this embodiment of the invention, the RSCU leverages this programmable characteristic of multimodal network edge network elements to act as a packet encapsulation gateway, responsible for encapsulating traffic event information into the TLV field of the IPv6 extension header.

[0056] SDN Control Layer (QoS Software-Programmable Execution Entity): The SDN controller deployed in a regional cloud or edge cloud. The controller internally maintains the following software-programmable components:

[0057] 1) QoS Policy Mapping Table: A software-defined data structure that stores the mapping relationship between event types (such as ambulance approach, collision warning) and QoS policy parameters (matching domain, target queue, guaranteed bandwidth, timeout). This mapping table can be updated by network administrators through the northbound interface via software programming without modifying the switch hardware configuration.

[0058] 2) Flow table programming module: Responsible for automatically converting QoS policy parameters into OpenFlow Flow-Mod messages through code, and performing real-time software programming of the switch in a standardized API call manner.

[0059] The SDN controller is the core execution unit for verifying the QoS software programmability of multimodal networks. It automatically converts event requirements within the vehicle-to-everything (V2X) mode into QoS policies at the network layer through software programming and issues them for execution. The entire process does not require manual login to the switch for command-line operations.

[0060] Data plane: SDN switches (supporting OpenFlow protocol) and Roadside Units (RSUs) deployed in roadside cabinets. The switches are the "enforcers" of QoS policies, responsible for parsing the TLV field in the IPv6 extension header and performing priority queue scheduling. The RSUs are the "broadcasters" of V2X messages, broadcasting security messages to vehicles via the PC5 interface.

[0061] Onboard Unit (OBU): The Onboard Unit (OBU) deployed on the vehicle is responsible for receiving V2X messages broadcast by the RSU.

[0062] In this embodiment, traffic event information is encapsulated into the TLV field of the IPv6 extension header, enabling the switch to quickly match and execute fine-grained QoS policies based on the TLV content.

[0063] The IPv6 extension header can be placed in the Hop-by-Hop Options Header (HBH) to ensure that each hop is checked.

[0064] The V2X event TLV structure can be described as follows:

[0065]

[0066] By mapping V2X application layer events to the aforementioned TLV fields, network layer switches can quickly obtain key semantic information of events without parsing application layer messages.

[0067] The QoS guarantee policies dynamically generated by the SDN controller are ultimately distributed to the SDN switch in the form of OpenFlow flow table entries. The core structure of a flow table entry is as follows: Figure 3 As shown, it includes the following fields:

[0068] Match Fields: Used to identify packet characteristics. In this scheme, the match fields may include: ingress port (the port connected to the RSU), source MAC address (the RSU's MAC address), source IPv6 address, and the V2X event TLV field in the IPv6 extension header (such as matching Type=0x1A, or exactly matching Event ID=0x0001).

[0069] Priority: The matching priority of flow table entries. In this scheme, dynamic flow table entries generated for emergency events are assigned the highest priority (e.g., 65535) to ensure that they are matched before statically configured ordinary flow table entries.

[0070] Instructions: The operations to be performed on successfully matched packets. In this scheme, the instructions include:

[0071] Enqueue operation: Place the data packet into strict priority queue 7 (highest priority hardware queue).

[0072] Forwarding operation: Sends data packets from the specified uplink port.

[0073] Hard Timeout: The lifespan of a flow table entry. In this scheme, the hard timeout is dynamically set based on the Event TTL field in the V2X event TLV (e.g., 120 seconds), and the flow table entry is automatically deleted after the timeout.

[0074] Idle Timeout: The idle time for a flow table entry. If no data packet is matched within the specified time, the flow table entry is automatically deleted.

[0075] S102, the SDN switch performs traffic event-driven priority scheduling based on flow tables, and automatically reclaims network resources after the traffic event ends.

[0076] Specifically, traffic event priorities can be obtained by parsing the TLV field in the IPv6 packet extension header and based on the flow table; traffic event-driven priority queue scheduling can then be performed based on the traffic event priorities.

[0077] A timeout timer is used to count down the time. When the timeout period is reached, the current flow table is set to automatically expire and be deleted, and the QoS scheduling policy of the SDN switch is restored to the default state.

[0078] The overall algorithm steps are as follows Figure 4 As shown, it can be summarized as including:

[0079] Step S1: Event Detection and Reporting

[0080] The Roadside Computing Unit (RSCU) integrates data from multiple sensors, including cameras and radar, and uses AI algorithms to perceive traffic events at intersections in real time. When a preset high-priority event is detected, the RSCU generates an event notification message. The message includes: event type (e.g., ambulance approach), event location (intersection ID), triggering vehicle ID, and estimated duration. The RSCU sends this event notification message to the SDN controller via the southbound interface.

[0081] Step S2: Dynamic Policy Generation—The Core Step in QoS Software Programmability

[0082] The SDN controller receives the event notification message and parses the event type, location information, and impact range. Internally, the controller maintains a QoS policy mapping table, a software-defined data structure that stores the mapping relationship from event types to QoS policy parameters. The controller automatically queries this mapping table through software, matches the corresponding QoS policy parameters, and automatically constructs a set of QoS policy data structures using program code. This policy generation is entirely automated by the software program based on the event type, without requiring manual login to the switch or input of any command lines. This embodies the "software-programmable QoS" characteristic in multimodal networks.

[0083] Step S3: IPv6 extension header TLV packaging

[0084] RSCU leverages the programmable message processing capabilities of multimodal network edge elements to act as a message encapsulation gateway, mapping traffic event information into V2X event TLVs, inserting them into the extended header of IPv6 packets (such as HBH or SRH), and then sending the encapsulated packets from the wired interface to the SDN switch.

[0085] Step S4: Flow table construction and distribution – automatic conversion from software programming strategy to hardware execution

[0086] The SDN controller's flow table programming module automatically converts the QoS policy data structure generated in step S2 into Flow-Mod messages in OpenFlow protocol format via program code. These messages contain matching domain programming instructions, action programming instructions, and lifecycle programming instructions. These instructions are issued to the switch via standardized API calls, essentially performing real-time software programming of the switch's forwarding pipeline. Upon receiving the Flow-Mod message, the switch parses it into hardware flow table entries and installs them into the TCAM. From then on, the switch no longer executes manually pre-defined static configurations, but rather dynamic forwarding rules programmed and issued in real-time by the SDN controller software.

[0087] Step S5: Switch Matching and QoS Execution

[0088] The target SDN switch receives and installs the flow table entry into its hardware flow table. This flow table entry is a general programmable rule based on TLV field matching. Within its validity period, all V2X cooperative messages carrying the same TLV can be repeatedly matched and priority scheduling is performed. For packets with successful TLV field matching, the switch executes the following instruction set: the packet is placed in a strict priority queue for scheduling and forwarding, achieving end-to-end millisecond-level low-latency communication.

[0089] Step S6: Strategy Aging and Resource Recycling – Lifecycle Software Programmable

[0090] The Hard Timeout timer set in the flow table entry begins its countdown. When the timeout period expires (consistent with the Event TTL in the V2X Event TLV), the flow table entry automatically expires and is deleted. The switch's QoS scheduling policy reverts to its default state, and all network resources are automatically reclaimed. This automatic policy reclamation demonstrates the concrete implementation of QoS software programmability at the lifecycle management level: when the software generates QoS policies, it simultaneously defines the policy's lifespan, essentially setting an "automatic destructor" for each temporary QoS policy. From triggering and execution to reclamation, the entire lifecycle of a QoS policy is defined by software programming, requiring no manual intervention.

[0091] Furthermore, based on the above method, embodiments of the present invention also provide a roadside wired dynamic QoS guarantee system for vehicle-to-everything (V2X) events, comprising: a sensor module, a roadside computing unit, a roadside publishing unit, and an SDN switch connected to an SDN controller, wherein the SDN controller is deployed in a regional cloud.

[0092] The sensor module is used to collect real-time roadside data based on sensors, including cameras and radar.

[0093] The roadside computing unit is used to fuse real-time roadside data, use a preset algorithm to sense current traffic events on the roadside, encapsulate the real-time sensed traffic event information into the TLV field of the IPv6 extension header, and map the traffic event information into V2X event TLV, so that the SDN controller can generate QoS policies according to the traffic event type and send them to the SDN switch through the flow table.

[0094] Roadside broadcasting units are used to broadcast V2X event information to vehicles;

[0095] SDN switches perform traffic event-driven priority scheduling based on flow tables and automatically reclaim network resources after a traffic event ends.

[0096] By deploying an SDN controller and OpenFlow-enabled switches on the roadside, and using the IPv6 extension header TLV (Type-Length-Value) field to carry V2X (Vehicle-to-Everything) event mapping information, the SDN controller automatically generates QoS policies through software programming and distributes them to the switches for execution. This provides deterministic communication guarantees for vehicle-to-everything (V2X) modes in a multimodal network environment, and provides a concrete technical verification example for the software programmable characteristics of multimodal network QoS.

[0097] To verify the effectiveness of the proposed solution, the following explanation will be provided in a specific scenario:

[0098] Taking the scenario of giving priority to ambulances at urban intersections as an example, this scenario also serves as a typical embodiment for verifying the programmable nature of QoS software in multimodal networks.

[0099] Scenario Description: At the intersection of a main road and a secondary road in a city, a complete vehicle-to-infrastructure (V2I) system is deployed, running on a multimodal network infrastructure. The V2I communication mode shares the bandwidth resources of the roadside fiber optic backhaul network with video surveillance, IoT, and other modes. This includes: high-definition cameras, millimeter-wave radar, roadside computing units (RSCU), roadside publishing units (RSU), SDN switches, and 5G base stations. The SDN controller and the V2I engine are jointly deployed in a regional cloud, managing the SDN switches at all intersections within the region. Implementation steps include the following:

[0100] 1. Initial state:

[0101] Upon system startup, the SDN controller has acquired the global network topology via the southbound interface and established OpenFlow connections with each SDN switch. Basic static QoS configurations are already loaded on each switch. The RSCU continuously runs the AI ​​fusion perception algorithm to monitor the intersection area in real time. At this point, the vehicle-to-everything (V2X) mode is operating normally in the multimodal network environment, sharing the bandwidth resources of the roadside wired backhaul network with other network modes. The QoS policies in the network are in a default static configuration state and have not yet been triggered for software-defined dynamic adjustments.

[0102] 2. Event Triggering and Reporting (corresponding to step S1):

[0103] At a certain moment, an ambulance on an emergency mission approaches the intersection from east to west. The RSCU at the intersection, using a fusion of camera and radar sensors, identifies the vehicle as an emergency vehicle and determines that it is traveling straight through the intersection. The RSCU classifies this as a high-priority traffic event and immediately generates an event notification message, including:

[0104] Event type: AMBULANCE_APPROACHING

[0105] Event location: INTERSECTION_ID = 1024

[0106] Triggering vehicle ID: VEHICLE_ID = 0x00AB1234

[0107] Estimated duration: EXPECTED_DURATION = 120s

[0108] RSCU sends this message to the SDN controller via the southbound interface.

[0109] 3. Strategy Decision-Making – The Core Component of QoS Software Programmability (Corresponding to Step S2):

[0110] After receiving the event notification message, the SDN controller's internal software program performs the following operations:

[0111] 1) Parse the message and extract the event type AMBULANCE_APPROACHING;

[0112] 2) The program code automatically queries the QoS policy mapping table and matches the corresponding policy parameters;

[0113] 3) The QoS policy data structure is automatically constructed by the program code, including: matching field (TLV Type=0x1A, EventID=0x0001), target queue (strict priority queue 7), and timeout (120s).

[0114] The generation of this strategy is entirely automated by the SDN controller's software program, without any manual command-line configuration, which is a concrete manifestation of the "QoS software programmable" characteristic in multimodal networks.

[0115] 4. IPv6 extension header TLV encapsulation (corresponding to step S3):

[0116] The RSCU leverages the programmable packet processing capabilities of multimodal network edge elements to act as a packet encapsulation gateway, mapping traffic event information into a V2X event TLV: Type=0x1A, Event ID=0x0001, Vehicle ID=0x00AB1234, Location ID=0x00000400, Event TTL=120. The RSCU inserts this TLV into the extended header of the IPv6 packet and then sends the encapsulated packet from the wired interface to the SDN switch SWITCH_1024.

[0117] 5. Flow table distribution – automatic conversion from software programming strategy to hardware execution (corresponding to step S4):

[0118] The SDN controller's flow table programming module automatically converts the above strategy into OpenFlow Flow-Mod messages via program code. These messages include match domain programming instructions (Match(IPv6_ExtHdr_TLV_Type=0x1A, Event_ID=0x0001)), action programming instructions (Action(Enqueue(Queue=7), Output(Port=Uplink))), and lifecycle programming instructions (Hard_Timeout=120s). This message is sent to SWITCH_1024 via standardized API calls, essentially performing real-time software programming of the switch's forwarding pipeline.

[0119] 6. Result achieved (corresponding to step S5):

[0120] SWITCH_1024 receives and installs this flow table entry. This flow table entry is a general programmable rule based on TLV field matching. Within its validity period, all V2X cooperative messages carrying the same TLV (such as traffic light priority requests sent to the traffic signal control platform, event status data reported to the regional cloud platform, etc.) can be repeatedly matched and priority scheduling is performed. These messages obtain deterministic highest priority guarantee on the multimodal shared physical link through the roadside wired backhaul network with a latency of less than 10 milliseconds, and reach the traffic signal control platform, triggering the traffic light controller to open the green light for the ambulance in advance, while not affecting the default resource allocation strategy of other modalities, ensuring the safe and efficient passage of the ambulance.

[0121] 7. Policy Recycling – Lifecycle Software Programmable (corresponding to step S6):

[0122] After 120 seconds (consistent with the Event TTL in the V2X Event TLV), the Hard Timeout of the flow table entry is triggered, the temporary flow table automatically expires and is deleted, and the switch's QoS policy returns to its default state. When the software generates QoS policies, it synchronously defines the policy's lifespan, essentially setting an "automatic destructor" for each temporary QoS policy. From triggering and execution to recycling, the entire lifecycle of the QoS policy is defined by software programming, eliminating the need for manual login to the switch for any deletion operations.

[0123] Using the above-mentioned vehicle-to-everything (V2X) communication modes as typical verification scenarios, on a multimodal shared physical link, the QoS policy of this solution is automatically generated by the SDN controller program by querying the mapping table based on the event type and automatically constructing policy parameters, without manual configuration. Furthermore, the QoS policy is automatically converted into OpenFlow API calls by the flow table programming module, enabling real-time software programming of the switches. The software synchronously defines the lifespan of the policy during policy generation, and automatically reclaims it upon expiration, achieving automated management throughout its entire lifecycle. While solving the QoS guarantee problem of roadside wired communication in V2X, this solution also objectively provides a complete technical verification example of the programmable nature of QoS software in multimodal networks, demonstrating the feasibility of dynamically defining, real-time programming, automatically deploying, and managing QoS policies throughout their entire lifecycle in a multimodal network architecture.

[0124] Unless otherwise specifically stated, the relative steps, numerical expressions, and values ​​of the components and steps described in these embodiments do not limit the scope of the invention.

[0125] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0126] The units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations are not considered to be beyond the scope of this invention.

[0127] Those skilled in the art will understand that all or part of the steps in the above methods can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk. Optionally, all or part of the steps in the above embodiments can also be implemented using one or more integrated circuits. Accordingly, each module / unit in the above embodiments can be implemented in hardware or as a software functional module. This invention is not limited to any particular combination of hardware and software.

[0128] Finally, it should be noted that the above-described embodiments are merely specific implementations of the present invention, used to illustrate the technical solutions of the present invention, and not to limit it. The scope of protection of the present invention is not limited thereto. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present invention, or make equivalent substitutions for some of the technical features; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events, characterized in that, Include: Real-time traffic event information is encapsulated into the TLV field of the IPv6 extension header and mapped to V2X event TLV, so that the SDN controller can generate QoS policies based on the traffic event type and send them to the SDN switch through flow tables. SDN switches perform traffic event-driven priority scheduling based on flow tables and automatically reclaim network resources after a traffic event ends.

2. The roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to claim 1, characterized in that, Real-time traffic event information is encapsulated into the TLV field of the IPv6 extension header, which includes: The current traffic events and their corresponding priorities on the roadside are perceived based on real-time data from multiple sources of sensors, including roadside cameras and radar. If the current traffic event priority meets the preset reporting conditions, an event notification message is generated and sent to the SDN controller. At the same time, the current traffic event information is mapped to a V2X event TLV, and the V2X event TLV is inserted into the IPv6 packet extension header so that the encapsulated IPv6 packet can be sent to the SDN switch.

3. The roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to claim 1, characterized in that, The V2X event TLV includes: V2X event emergency type identifier field, length field, event type code field, vehicle identifier field that triggered the event, event location code field, and event validity period field.

4. The roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to claim 1, characterized in that, The SDN controller generates QoS policies based on traffic event types and distributes them to the SDN switches via flow tables, including: Based on the event notification message, the corresponding QoS policy parameters are matched from the QoS policy mapping table, which pre-stores the mapping relationship between traffic event types and QoS policy parameters; QoS policies are generated based on QoS policy parameters, and the QoS policies are converted into Flow-Mod messages in OpenFlow protocol format and sent to SDN switches through flow tables.

5. The roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to claim 1, characterized in that, The flow table structure includes: a matching field for identifying packet characteristics, a priority field for indicating the matching priority of the flow table entry, an instruction behavior field for indicating the operation to be performed on the matched packet, a hard timeout field for indicating the lifespan of the flow table entry, and an idle timeout field for indicating the idle time of the flow table entry.

6. The roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to claim 1, characterized in that, SDN switches perform traffic event-driven priority scheduling based on flow tables, including: Parse the TLV field in the IPv6 packet extension header and obtain the traffic event priority based on the flow table; Traffic event-driven priority queue scheduling is performed based on the priority of traffic events.

7. The roadside wired dynamic QoS guarantee method for vehicle-to-everything (V2X) events according to claim 1 or 6, characterized in that, Automatically reclaim network resources after a traffic incident, including: A timeout timer is used to count down the time. When the timeout period is reached, the current flow table is set to automatically expire and be deleted, and the QoS scheduling policy of the SDN switch is restored to the default state.

8. A vehicle-road cooperative system for vehicle-to-everything (V2X) events, characterized in that, It includes: a sensor module, a roadside computing unit, a roadside publishing unit, and an SDN switch connected to an SDN controller, wherein the SDN controller is deployed in a regional cloud. The sensor module is used to collect real-time roadside data based on sensors, including cameras and radar. The roadside computing unit is used to fuse real-time roadside data, use a preset algorithm to sense current traffic events on the roadside, encapsulate the real-time sensed traffic event information into the TLV field of the IPv6 extension header, and map the traffic event information into V2X event TLV, so that the SDN controller can generate QoS policies according to the traffic event type and send them to the SDN switch through the flow table. Roadside broadcasting units are used to broadcast V2X event information to vehicles; SDN switches perform traffic event-driven priority scheduling based on flow tables and automatically reclaim network resources after a traffic event ends.

9. An electronic device, characterized in that, include: At least one processor, and a memory coupled to said at least one processor; The memory stores a computer program that can be executed by the at least one processor to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, enables the implementation of the method as described in any one of claims 1 to 7.

Images