A V2X communication load simulation method based on edge nodes

Abstract

This invention relates to the field of edge computing technology, specifically to a V2X communication load simulation method based on edge nodes, comprising the following steps: obtaining a fleet coordination state matrix based on the node identifier, speed vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area; predicting the synchronization spatial coordinates crossing the service boundary of the edge node based on the fleet coordination state matrix, and aligning the trigger time parameters of the preset application layer data download instructions. This invention, by parsing the failed data identifier parameters, drives each virtual vehicle node to generate a conditional verification retransmission request carrying an entity tag field or a modified time verification field, and concurrently pushes the conditional verification retransmission request to the edge node. This can further induce conditional verification back-to-origin behavior after consistency comparison failure, thereby reflecting the concurrent protocol stack processing pressure from the perspectives of active connections, request queuing, message retransmission, response latency, and connection release.

Description

Technical Field

[0001] This invention relates to the field of edge computing technology, and in particular to a method for simulating V2X communication load based on edge nodes. Background Technology

[0002] Edge computing technology refers to deploying computing, data storage, network communication, resource scheduling, and application service capabilities at the network edge, close to the data generation end or business execution end. This enables data generated by terminal devices to be collected, parsed, filtered, calculated, cached, and responded to at the edge, reducing the communication latency, bandwidth consumption, and centralized processing pressure caused by transmitting all data to the cloud central server.

[0003] Current edge computing operation modes typically focus on collecting, parsing, computing, caching, and responding to terminal data locally, relying on edge nodes to forward cross-regional data or request supplementary data to the cloud central server. In actual operation, terminal requests often enter edge nodes in the natural arrival order. The lack of unified spatiotemporal constraints between vehicle movement status, service boundary crossing times, request triggering times, and data object identifiers leads to dispersed test traffic, making it difficult to reliably reproduce scenarios where a large number of vehicles access the same data file simultaneously within a short period. Even if cache mutexes have contention defects, they may not manifest due to excessively large request arrival intervals. Furthermore, the cached content within edge nodes is mostly updated according to the normal business write rhythm, and the event write frequency of local dynamic map layers is limited by the number of real traffic events. The timing of dirty data states and cache invalidation notifications is random, making continuous observation of the consistency maintenance process difficult and extending the testing cycle. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing a V2X communication load simulation method based on edge nodes.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a V2X communication load simulation method based on edge nodes, comprising the following steps: The fleet coordination state matrix is ​​obtained based on the node identifier, velocity vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area. Based on the fleet coordination state matrix, predict the synchronous spatial coordinates that cross the service boundary of the edge node, and align the preset application layer data download command trigger time parameters to generate a synchronous application layer request payload set with a unified absolute trigger time. When the unified absolute trigger time is reached, each of the virtual vehicle nodes is controlled to concurrently send the synchronous application layer request payload set to the edge node so that it reaches the edge node within the concurrency window period; During the concurrency window, monitor the uplink network traffic forwarded by the edge node to the cloud central server; if multiple back-to-source data synchronization messages for the same data file identifier are parsed from the uplink network traffic within a preset time threshold, it is determined that the cache mutex lock of the edge node has been breached and recorded as a penetration failure feature. The frequency of sudden events written to the local dynamic map layer is obtained based on the spatial coordinate span parameters of the edge coverage area and the preset time dimension coordinate system. Based on the frequency of emergency event writes, the preset dynamic map layer identifiers, and simulated traffic event elements, an application layer write message containing overwrite instructions is generated; the application layer write message is sent according to the frequency of emergency event writes to overwrite the local dynamic map layer data inside the edge node, forcing the edge node to generate a dirty data state and triggering a cache invalidation notification message.

[0006] Preferably, the method further includes: Receive the cache invalidation notification message sent by the edge node through the message queue telemetry transmission protocol publishing port; Parse the invalid data identifier parameter in the cache invalidation notification message, trigger each of the virtual vehicle nodes to generate a conditional verification retransmission request carrying an entity tag field or modification time verification field corresponding to the invalid data identifier parameter; push the conditional verification retransmission request to the edge node, and monitor the concurrent protocol stack processing pressure of the edge node initiating a conditional verification back-to-origin request to the cloud center server.

[0007] Preferably, the steps for obtaining the fleet coordination state matrix are as follows: Read the node identifier, velocity vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area. Establish a node row index according to the character order of the node identifier. Decompose the velocity vector parameters into lateral velocity components, longitudinal velocity components, and height velocity components. Decompose the spatial coordinate parameters into lateral coordinate components, longitudinal coordinate components, and height coordinate components. Calculate the vector mean of each component in all virtual vehicle nodes. Call the preset velocity weight parameters and spatial coordinate weight parameters to perform component product superposition on the original components and corresponding vector mean of each virtual vehicle node. Write the superposition result into the corresponding matrix row and column according to the node row index to obtain the fleet coordination state matrix.

[0008] Preferably, the step of obtaining the synchronous application layer request payload set is as follows: According to the fleet coordination state matrix, the lateral velocity component, longitudinal velocity component, height velocity component, lateral coordinate component, longitudinal coordinate component, and height coordinate component of each virtual vehicle node are read row by row according to the node row index. The spatial movement direction of each virtual vehicle node is determined according to the positive and negative directions of the velocity components. The current position is extended along the spatial movement direction to form a movement trajectory. The boundary coordinate sequence of the service boundary of the edge node is extracted. The intersection position of the movement trajectory and the boundary coordinate sequence is determined segment by segment. The spatial distance from the current position to the intersection position is calculated. The boundary crossing time is determined according to the spatial distance and the velocity vector length. The latest time among all boundary crossing times is selected as the synchronous boundary crossing time. The position coordinates corresponding to each virtual vehicle node are calculated according to the synchronous boundary crossing time to obtain the synchronous spatial coordinates. Read the synchronization boundary crossing time associated with the synchronization spatial coordinates, convert the synchronization boundary crossing time into an absolute timestamp under a unified time zone and unified time precision, determine the absolute timestamp as the unified absolute trigger time, read the preset application layer data download instructions and trigger time parameters one by one, delete the original relative trigger time parameters of each application layer data download instruction, write the unified absolute trigger time into the corresponding trigger field, establish the correspondence between virtual vehicle nodes and application layer data download instructions according to node identifiers, write the node identifier, application layer data download instructions, and unified absolute trigger time into the request payload in sequence, merge all request payloads according to the unified absolute trigger time, and generate a synchronization application layer request payload set.

[0009] Preferably, the step of acquiring the uplink network traffic is as follows: When the unified absolute trigger time is reached, the node row index in the fleet coordination state matrix is ​​read, each virtual vehicle node is located according to the node row index, the node identifier and sending status corresponding to each virtual vehicle node are verified, the synchronous application layer request payload set is called, each synchronous application layer request payload is allocated to the corresponding virtual vehicle node according to the node identifier, the sending clock of each virtual vehicle node is uniformly locked to the unified absolute trigger time, the sending port of each virtual vehicle node is synchronously opened when the unified absolute trigger time is reached, the sending timestamp, arrival timestamp, and data file identifier of each application layer request are continuously recorded, and application layer requests whose arrival timestamps are within the concurrent window period are filtered to form an application layer request arrival record within the concurrent window period. Based on the application layer request arrival records within the concurrency window, the start and end timestamps of the concurrency window are extracted. The edge node uplink port listening is started according to the start timestamp and ended according to the end timestamp. The packets forwarded by the edge node to the cloud central server are read frame by frame. The packet generation timestamp, packet sending timestamp, source port identifier, destination port identifier, transport protocol identifier, and data file identifier of each packet are recorded. Packets whose generation timestamps exceed the concurrency window are removed. Packets whose destination port identifiers point to the cloud central server are retained. The retained packets are arranged in the order of their generation timestamps to generate uplink network traffic.

[0010] Preferably, the step of obtaining the penetration failure feature is as follows: Based on the uplink network traffic, the starting timestamp of the concurrent window period is used as the timing start point. The packet parsing deadline timestamp is determined according to a preset time threshold. The packet type field, data file identifier field, origin direction field, and synchronization status field are parsed frame by frame. Packets whose packet type field points to data synchronization packets and whose origin direction field points to the cloud central server are identified as origin data synchronization packets. The origin data synchronization packets are grouped and counted according to the data file identifier field. If the number of origin data synchronization packets corresponding to any data file identifier is greater than one within the preset time threshold, it is determined that the edge node has repeatedly initiated origin synchronization for the same data file identifier. It is confirmed that the cache mutex lock of the edge node has been broken. The corresponding data file identifier, the number of origin data synchronization packets, and the packet generation timestamp are recorded to form a penetration failure feature.

[0011] Preferably, the step of obtaining the frequency of writing sudden events is as follows: Extract the horizontal, vertical, and height coordinate parameters of each boundary point in the edge coverage area, arrange the corresponding coordinate parameters according to the coordinate axis direction, select the maximum and minimum coordinate parameters in each coordinate axis direction, calculate the coordinate difference obtained by subtracting the minimum coordinate parameter from the maximum coordinate parameter, and form a spatial coordinate span parameter. Read the start time parameter, time segment length, number of time segments, and time segment order in the preset time dimension coordinate system, divide the spatial coordinate span parameter into spatial event units according to the number of time segments, count the number of spatial event units corresponding to each time segment, call the preset basic trigger intensity parameter, determine the expected number of event triggers segment by segment based on the number of spatial event units and the time segment length, discretize the expected number of event triggers, and write the discretization result into the corresponding time segment to obtain the frequency of sudden events written to the local dynamic map layer.

[0012] Preferably, the step of obtaining the dirty data state is as follows: Read the write count corresponding to each time segment in the time segment order, establish an equal number of message sequence numbers based on the write count, read the preset dynamic map layer identifier, write the dynamic map layer identifier into the target layer field of each message according to the message sequence number, extract the traffic event type, event occurrence coordinates, event influence direction, event start time, event duration, and event status parameters from the simulated traffic event elements one by one, write the extraction results into the message content area according to the field arrangement order, set the message operation field to the overwrite instruction, write the corresponding message sequence number, generation timestamp, message length, and verification identifier into the message header, classify all messages by time segment according to the write frequency of the sudden event, and generate application layer write messages; The system calls the frequency of writing the sudden event, determines the number of messages to be sent according to the number of writes corresponding to each time segment, determines the sending interval of adjacent messages according to the length of the time segment, arranges the application layer write messages into the sending queue according to the message sequence number, and sends the application layer write messages to the edge node one by one when the corresponding sending timestamp is reached. It receives the write confirmation status returned by the edge node. When the write confirmation status indicates that the write was successful, it continues to send the next application layer write message. If the write confirmation status does not return within the preset confirmation time limit, it resends the current application layer write message. It locates the local dynamic map layer data inside the edge node according to the dynamic map layer identifier, replaces the simulated traffic event elements to the corresponding layer position according to the overwrite instruction, and records the layer version parameters, modification time parameters, and persistence synchronization status after each replacement. If the layer version parameters corresponding to the same dynamic map layer identifier change again before the persistence synchronization is completed, the local dynamic map layer data corresponding to the latest layer version parameters is marked as dirty data. It generates invalid data identifier parameters according to the dynamic map layer identifier, controls the edge node to publish a cache invalidation notification message carrying the invalid data identifier parameters, generates dirty data status and triggers the cache invalidation notification message.

[0013] Preferably, the step of obtaining the conditional verification retransmission request is as follows: The message queue telemetry transmission protocol publishing port of the edge node is monitored. The fixed header, topic name, quality of service level, message identifier, remaining length, and payload content of the output message of the publishing port are read. The published messages with topic names pointing to the cache invalidation notification topic are filtered. Duplicate published messages are deduplicated according to the message identifier. The segmented payload content is sequentially concatenated according to the fragment sequence number. The message length, verification identifier, and publishing timestamp of the concatenated payload content are verified. Published messages with matching message lengths and consistent verification identifiers are retained. The corresponding receiving timestamp is recorded to obtain the cache invalidation notification message. According to the cache failure notification message, the failure data identifier parameter, dynamic map layer identifier, layer version parameter, and modification time parameter are parsed in the order of the load fields. Based on the failure data identifier parameter, the associated node identifier in the fleet coordination state matrix is ​​retrieved. Each virtual vehicle node is located row by row. The entity tag field and modification time verification field of the corresponding failure data identifier parameter in the local cache of each virtual vehicle node are read. If the entity tag field exists, it is written to the corresponding protocol header. If the entity tag field does not exist, it is written to the corresponding protocol header. The failure data identifier parameter is written to the request resource location field, and the node identifier is written to the request source field. A conditional verification retransmission request is generated. Establish concurrent sending queues for each virtual vehicle node according to the node identifier, lock the sending timestamps of each concurrent sending queue to the same sending time, synchronously open the sending ports of each virtual vehicle node, concurrently push the conditional verification retransmission request to the edge node, listen to the consistency comparison status returned by the edge node, filter the conditional verification retransmission requests where the entity label field does not match or the modification time verification field is earlier than the current layer modification time parameter, track the conditional verification back-to-origin requests initiated by the edge node to the cloud center server based on the filtering results, continuously record the number of active connections, the number of connections waiting, the number of backlogged sending queues, the number of backlogged receiving queues, the number of message retransmissions, the number of request timeouts, and the connection release timestamp, summarize the records according to the sampling time order to obtain the concurrent protocol stack processing pressure.

[0014] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, by calling the node identifier, velocity vector parameters, and spatial coordinate parameters of virtual vehicle nodes, a fleet coordination state matrix reflecting the overall motion relationship of the fleet is formed. Based on this matrix, the synchronization spatial coordinates of each virtual vehicle node when crossing the service boundary of the edge node are predicted. Application layer data download instructions are uniformly calibrated to the same absolute trigger time, enabling dispersed requests to arrive at the edge node concentratedly within the concurrency window. This constructs an instantaneous communication load with clear spatiotemporal correlation, avoiding the temporal discrepancy problem caused by simply increasing the number of requests, and improving the authenticity and reproducibility of the high-concurrency carrying capacity test results of the edge node. By monitoring the uplink network traffic forwarded by the edge node to the cloud central server and identifying repeated source synchronization messages for the same data file identifier within a preset time threshold, cache mutex breakdown can be transformed into a detectable and recordable penetration failure characteristic, providing clear data evidence for cache concurrency control anomalies. Spatial coordinate span parameters and time dimension coordinate system determine the frequency of sudden event writes to the local dynamic map layer. Then, the dynamic map layer identifier, simulated traffic event elements and overwrite instructions are concatenated into the application layer write message. This can continuously change the local dynamic map layer data inside the edge node, actively form a dirty data state and trigger cache failure notification messages, so that the cache consistency test is extended from static reading to dynamic writing, version change and failure propagation process. By parsing the failure data identifier parameter, each virtual vehicle node is driven to generate a conditional verification retransmission request with entity label field or modification time verification field, and the conditional verification retransmission request is pushed concurrently to the edge node. This can further induce conditional verification back-to-origin behavior after consistency comparison failure, thereby reflecting the concurrent protocol stack processing pressure from the aspects of active connection, request queuing, message retransmission, response delay and connection release, forming a continuous load link covering synchronization request, cache breakdown, data overwrite, failure propagation and conditional back-to-origin. Attached Figure Description

[0015] Figure 1 This is a schematic diagram illustrating the characteristics of penetration failure. Figure 2 A diagram illustrating the frequency of events. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0017] Please see Figure 1-2 This invention provides a technical solution, a method for simulating V2X communication load based on edge nodes, comprising the following steps: The fleet coordination state matrix is ​​obtained based on the node identifier, velocity vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area; the synchronous spatial coordinates that cross the service boundary of the edge node are predicted based on the fleet coordination state matrix, and the trigger time parameters of the preset application layer data download instructions are aligned to generate a synchronous application layer request payload set with a unified absolute trigger time. When the unified absolute trigger time is reached, control each virtual vehicle node to send the synchronous application layer request payload set to the edge node concurrently, so that it reaches the edge node within the concurrency window period; during the concurrency window period, listen to the uplink network traffic forwarded by the edge node to the cloud central server; if multiple back-to-source data synchronization messages for the same data file identifier are parsed from the uplink network traffic within the preset time threshold, it is determined that the cache mutex lock of the edge node has been broken and recorded as a penetration failure feature; The frequency of sudden events written to the local dynamic map layer is obtained based on the spatial coordinate span parameters of the edge coverage area and the preset time dimension coordinate system; an application layer write message containing overwrite instructions is generated by splicing the sudden event write frequency, the preset dynamic map layer identifier and the simulated traffic event elements; the application layer write message is sent according to the sudden event write frequency to overwrite the local dynamic map layer data inside the edge node, force the edge node to generate a dirty data state and trigger a cache invalidation notification message; Receive cache invalidation notification messages from edge nodes via the message queue telemetry transmission protocol; parse the invalidation data identifier parameter in the cache invalidation notification message, trigger each virtual vehicle node to generate a conditional verification retransmission request carrying an entity tag field or modification time verification field corresponding to the invalidation data identifier parameter; push the conditional verification retransmission request to the edge nodes, and monitor the concurrent protocol stack processing pressure of the edge nodes initiating conditional verification back-to-origin requests to the cloud central server.

[0018] The steps to obtain the fleet coordination state matrix are as follows: Read the node identifier, velocity vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area. Establish a node row index according to the character order of the node identifier. Decompose the velocity vector parameters into lateral velocity components, longitudinal velocity components, and height velocity components. Decompose the spatial coordinate parameters into lateral coordinate components, longitudinal coordinate components, and height coordinate components. Calculate the vector mean of each component in all virtual vehicle nodes. Call the preset velocity weight parameters and spatial coordinate weight parameters to perform component product superposition on the original components and corresponding vector mean of each virtual vehicle node. Write the superposition result into the corresponding matrix row and column according to the node row index to obtain the fleet coordination state matrix.

[0019] Specifically, the node identifier, velocity vector parameters, and spatial coordinate parameters already collected for each virtual vehicle node are read and arranged lexicographically by node identifier to form a node row index. The velocity vector and spatial coordinate parameters are then decomposed into lateral, longitudinal, and height components, with velocity uniformly expressed in m / s and coordinates uniformly expressed in meters. The six components are normalized from their minimum to maximum values, with the maximum and minimum values ​​being the same and recorded as 0. The vector mean of each normalized component is then calculated. The velocity weight and spatial coordinate weight parameters are set based on the boundary crossing time error of the most recent 10 trial runs of a similar-sized fleet. The reciprocals of the two types of errors are taken, and then normalized so that the sum of the two weights is 1. For example, when the velocity error is 0.4s and the coordinate error is 0.6s, the reciprocals are 2.5 and 1.67, respectively. After normalization, the velocity weight is set to 0.60, and the spatial coordinate weight is set to 0.40. according to Calculate the co-operation vector, where, Representative node The three-directional cooperative vector, Represents the node row index. Represents the speed weighting parameter. Representative node The normalized velocity vector, Represents the normalized mean velocity vector. Represents the spatial coordinate weight parameter. Representative node The normalized coordinate vector, Represents the normalized coordinate mean vector. Multiplying the corresponding directional components, the six original components and the cooperative vector are written into the corresponding matrix rows to obtain the vehicle cooperative state matrix.

[0020] The steps for obtaining the synchronous application layer request payload set are as follows: Based on the fleet coordination state matrix, the lateral velocity component, longitudinal velocity component, height velocity component, lateral coordinate component, longitudinal coordinate component, and height coordinate component of each virtual vehicle node are read row by row according to the node row index. The spatial movement direction of each virtual vehicle node is determined according to the positive and negative directions of the velocity components. The current position is extended along the spatial movement direction to form a movement trajectory. The boundary coordinate sequence of the service boundary of the edge node is extracted. The intersection position of the movement trajectory and the boundary coordinate sequence is determined segment by segment. The spatial distance from the current position to the intersection position is calculated. The boundary crossing time is determined according to the spatial distance and the velocity vector length. The latest time among all boundary crossing times is selected as the synchronous boundary crossing time. The position coordinates corresponding to each virtual vehicle node are calculated according to the synchronous boundary crossing time to obtain the synchronous spatial coordinates. Read the synchronization boundary crossing time associated with the synchronization spatial coordinates, convert the synchronization boundary crossing time into an absolute timestamp under a unified time zone and unified time precision, determine the absolute timestamp as the unified absolute trigger time, read the preset application layer data download instructions and trigger time parameters one by one, delete the original relative trigger time parameters of each application layer data download instruction, write the unified absolute trigger time into the corresponding trigger field, establish the correspondence between virtual vehicle nodes and application layer data download instructions according to the node identifier, write the node identifier, application layer data download instruction, and unified absolute trigger time into the request payload in sequence, merge all request payloads according to the unified absolute trigger time, and generate a synchronization application layer request payload set.

[0021] Specifically, based on the vehicle coordination state matrix, the three velocity components and three coordinate components corresponding to the node identifier are extracted row by row. The coordinate components are combined into the current position vector, and the velocity components are combined into a spatial velocity vector. Nodes with a velocity vector length less than 0.1 m / s are treated as stationary nodes. The 0.1 m / s value is obtained by rounding up the maximum velocity fluctuation of 0.07 m / s from the last 10 static simulations, using the minimum resolution of 0.1 m / s in the velocity field. The moment when a stationary node crosses the boundary is recorded as the prediction time domain endpoint. Non-stationary nodes are treated using uniform kinematic relationships. Extend the movement trajectory, among which, Representative node Over time The spatial position after Representative node The current position vector, Representative node Spatial velocity vector, This represents the cumulative prediction time since the current sampling time. The node row index is represented. The service boundary of the edge node is formed by line segments based on adjacent boundary points. When the height changes, it is formed by triangular facets to form a closed boundary. The first intersection point of the movement trajectory with the boundary line segment or boundary facet is calculated segment by segment. Results with intersection point parameters less than 0 are discarded. Results with intersection points falling within the range of the line segment endpoints or the centroid coordinate range of the facet are retained. The boundary crossing time is obtained by dividing the spatial distance from the current position to the intersection point by the velocity vector length. The prediction time domain is taken as the remaining duration of the current edge service session. For example, if the session has 30 seconds remaining, only the intersection points within 0 seconds to 30 seconds are retained. The first boundary crossing time of a node is determined by the minimum time value of multiple intersection points. The first boundary crossing time of all nodes is determined by the maximum time value to determine the synchronous boundary crossing time. Then, the synchronous boundary crossing time is substituted into the corresponding current position vector and spatial velocity vector to generate position coordinates in three directions row by row. The synchronous spatial coordinates are then summarized.

[0022] Read the synchronization boundary violation time corresponding to the synchronization spatial coordinates. First, obtain the time zone offset, time server synchronization result, and timestamp accuracy used in the edge simulation environment. Convert the synchronization boundary violation time to UTC absolute time, and then truncate the extra decimal places with a precision of 1μs. 1μs is taken as the smallest adjustable granularity of the virtual vehicle's sending clock. If the node clock deviations obtained from the most recent synchronization are 20μs, 35μs, and 18μs, then subtract the corresponding deviations from the trigger times of each node to make the converted time fields of each node point to the same absolute time. Register this time as the unified absolute trigger time. Then, read the request method, resource location field, data file identifier, protocol version, original relative delay, and node identifier in the application layer data download instruction one by one. After deleting the original relative delay, check whether the resource location field is consistent with the data file identifier. The last-level name of the resource location field is consistent with the data file identifier. Inconsistent instructions are not included in the current merging round. Consistent instructions have their unified absolute trigger time written to the trigger field, node identifier written to the request source field, and data file identifier written to the request resource field. A one-to-one correspondence is then established between the node identifier and the node row index of the vehicle coordination state matrix. When node identifiers are duplicated, the load sequence number is appended according to the order of instruction reading. When a node identifier is missing, the assembly of that instruction is stopped according to the node row index. Each request load is arranged in the following order: node identifier, load sequence number, request method, resource location field, data file identifier, protocol version, unified absolute trigger time, and load length. Concurrency groups are formed according to the merging rules of the same unified absolute trigger time, the same data file identifier, and different node identifiers. The merged groups are sorted in ascending order by unified absolute trigger time, and requests at the same time are sorted in ascending order by node row index, generating a synchronous application layer request load set.

[0023] The steps for obtaining uplink network traffic are as follows: When the unified absolute trigger time is reached, the node row index in the fleet coordination state matrix is ​​read, each virtual vehicle node is located according to the node row index, the node identifier and sending status of each virtual vehicle node are verified, the synchronous application layer request payload set is called, each synchronous application layer request payload is allocated to the corresponding virtual vehicle node according to the node identifier, the sending clock of each virtual vehicle node is uniformly locked to the unified absolute trigger time, the sending port of each virtual vehicle node is synchronously opened when the unified absolute trigger time is reached, the sending timestamp, arrival timestamp, and data file identifier of each application layer request are continuously recorded, and the application layer requests whose arrival timestamps are within the concurrent window period are filtered to form the application layer request arrival record within the concurrent window period; Based on the application layer request arrival records within the concurrent window period, the start and end timestamps of the concurrent window period are extracted. The uplink port listening of the edge node is started according to the start timestamp and ended according to the end timestamp. The packets forwarded by the edge node to the cloud central server are read frame by frame. The packet generation timestamp, packet sending timestamp, source port identifier, destination port identifier, transport protocol identifier, and data file identifier of each packet are recorded. Packets whose generation timestamps exceed the concurrent window period are removed. Packets whose destination port identifiers point to the cloud central server are retained. The retained packets are arranged in the order of their generation timestamps to generate uplink network traffic.

[0024] Specifically, before reaching the unified absolute trigger time, the node row index of the fleet coordination state matrix is ​​read, and the node identifier is checked row by row to see if it exists in the synchronous application layer request payload set. The sending status is checked to see if it is in the "pending" state. Sending ports are not open in the "sent," "paused," or "connection failed" states. For nodes in the "pending" state, the corresponding request payload is assigned according to the node identifier. The virtual clock of each node is corrected to the unified absolute trigger time. The clock correction is measured using the deviation value obtained from the most recent time synchronization. When the unified absolute trigger time arrives, the sending queue is simultaneously unblocked. The sending port reads the first payload according to the node row index and writes it to the network protocol stack. The timestamp of entering the sending queue, the timestamp of leaving the sending queue, the arrival timestamp captured by the edge node's receiving interface, the node identifier, the payload sequence number, and the data file identifier are recorded. The concurrent window length is based on the most recent... The maximum clock deviation, maximum virtual scheduling jitter, and one-way transmission delay discreteness obtained from the last 10 trial runs with the same number of nodes are summed to set a concurrency window period. For example, if the three values ​​are 0.8ms, 1.5ms, and 2.7ms respectively, and the sum is 5ms, then the concurrency window period is set from the unified absolute trigger time to 5ms thereafter. Only the trial run results with the same number of nodes as this round are called. If the number of nodes is inconsistent, the trial run is repeated 10 times with the same number of nodes as this round. Records whose arrival timestamp is earlier than the start of the window, later than the end of the window, or missing data file identifiers are marked as early arrival, late arrival, or missing fields, respectively. Records within the window range with complete node identifiers, payload sequence numbers, and data file identifiers are sorted in ascending order by arrival timestamp. If the arrival timestamps are the same, they are sorted by node row index to form the application layer request arrival record within the concurrency window period.

[0025] Based on the earliest and latest arrival timestamps of application layer requests arriving within the concurrent window, the earliest arrival timestamp is shifted forward by one network interface card (NIC) timestamp sampling period as the monitoring start point, and the latest arrival timestamp is shifted backward by one sampling period as the monitoring end point. The sampling period is determined by the hardware timestamp precision of the edge node's uplink interface; for example, if the timestamp precision is 1μs, it is extended by 1μs before and after. Mirrored traffic reading of the edge node's uplink interface is enabled at the monitoring start point, and new frame reception is stopped at the monitoring end point. For each Ethernet frame during the monitoring period, the link layer type, network layer source and destination addresses, transport layer source and destination ports, transport protocol identifier, packet generation timestamp, packet transmission timestamp, and application layer data file identifier are parsed sequentially. Fragmented packets are merged according to source address, destination address, transport protocol identifier, and fragment identifier. When the fragment sequence number is consecutive and the total length is consistent with the fragment declaration length in the header, the application layer packet is restored. When a fragment is missing, the frame-level record is retained and the fragment is marked as incomplete. When the destination address and destination port both match the address and port of the peer that has established a connection with the cloud central server, it is identified as an uplink packet. Packets with matching addresses but mismatched ports are processed as other cloud sessions. Records whose packet generation timestamps are outside the range from the start to the end of the listening session are discarded. When the timestamp is missing, the edge uplink interface is used to capture the timestamp and mark the time source. The retained packets are sorted in ascending order by the packet generation timestamp. When the timestamps are the same, they are sorted by the sending timestamp and frame sequence number. The uplink network traffic is then summarized.

[0026] The steps for obtaining penetration failure characteristics are as follows: Based on the uplink network traffic, the starting timestamp of the concurrent window period is used as the timing start point. The packet parsing deadline timestamp is determined according to the preset time threshold. The packet type field, data file identifier field, origin direction field, and synchronization status field are parsed frame by frame. Packets whose packet type field points to data synchronization packets and whose origin direction field points to the cloud central server are identified as origin data synchronization packets. The origin data synchronization packets are grouped and counted according to the data file identifier field. If the number of origin data synchronization packets corresponding to any data file identifier is greater than one within the preset time threshold, it is determined that the edge node has repeatedly initiated origin synchronization for the same data file identifier. It is confirmed that the cache mutex lock of the edge node has been broken. The corresponding data file identifier, the number of origin data synchronization packets, and the packet generation timestamp are recorded to form a penetration failure feature.

[0027] Specifically, the concurrent window start timestamp is used as the timing starting point based on the uplink network traffic. The message parsing time limit is set according to the most recent 20 tests that did not break the cache mutex lock. The duration from the first concurrent request to the first normal origin data synchronization message is read for each test, and the maximum value is taken plus one uplink interface sampling period. The data file size, number of nodes, and cache status of the test are consistent with this round. For example, when the maximum duration is 18ms and the sampling period is 1ms, the message parsing time limit is 19ms. The message type field, data file identifier field, origin direction field, and synchronization status field are parsed. Messages with the message type of data synchronization, the destination pointing to the cloud central server, and the synchronization status of start or in transmission are classified as origin data synchronization messages. Each data file identifier is processed according to... Count, among which, Represents data file identifier The number of messages, Represents the message sequence number, Represents the total number of uplink network traffic packets. The expression represents a functional and takes the value 1 if the condition within the parentheses is true, otherwise takes the value 0. Represents the start timestamp of the concurrent window period. Representing the The timestamp of each message's generation. Represents the message parsing time limit. Representing the The data file identifier for each message. The data file identifier representing the current group. Representing the When the source direction determination value of a message points to the cloud central server, it is set to 1. When the number of the same data file identifier is greater than 1, the data file identifier, the number, and the message generation timestamp are recorded to form a penetration failure feature.

[0028] The steps to obtain the write frequency of sudden events are as follows: Extract the horizontal, vertical, and height coordinate parameters of each boundary point in the edge coverage area. Arrange the corresponding coordinate parameters according to the coordinate axis direction. Select the maximum and minimum coordinate parameters in each coordinate axis direction. Calculate the coordinate difference between the maximum and minimum coordinate parameters to form the spatial coordinate span parameter. Read the start time parameter, time segment length, number of time segments, and time segment order from the preset time dimension coordinate system. Divide the spatial coordinate span parameter into spatial event units according to the number of time segments. Count the number of spatial event units corresponding to each time segment. Call the preset basic trigger intensity parameter. Determine the expected number of event triggers segment by segment based on the number of spatial event units and the time segment length. Discretize the expected number of event triggers and write the discretization result into the corresponding time segment to obtain the frequency of sudden events written to the local dynamic map layer.

[0029] Specifically, the horizontal, vertical, and height coordinate parameters of the boundary points of the edge coverage area are extracted. The maximum and minimum values ​​of the three coordinate axes are taken, and the span is calculated. The span of each coordinate axis is divided equally according to the number of time segments. The number of segments is determined by the segment length and total duration of the time dimension coordinate system. For example, when the total duration is 60s and the segment length is 10s, 6 segments are obtained. The equally divided intervals are then combined into spatial event units. For two-dimensional roads, horizontal and vertical intervals are combined, and height intervals are added for interchanges. The number of spatial event units associated with each segment is counted. The basic trigger strength parameter adopts the Poisson process unit spatial event unit write rate. It is based on the total number of actual writes in the last 10 simulations of the same layer with the same number of nodes, divided by the number of spatial event units and the duration setting. For example, if there are 600 writes, covering 20 spatial event units and 300s, then the basic trigger strength parameter is 0.1 times / spatial event unit / s. The time is segmented. according to Calculate the expected number of events to be triggered, where, Representing time segments The expected number of events triggered. Represents the time segment sequence number. Represents the base trigger strength parameter. Represents the number of associated spatial event units. Representing the length of time segments, a random seed and a uniform number from 0 to 1 are generated using the edge coverage area identifier and the time segment sequence number. The number of writes is the integer whose cumulative probability is not less than the uniform number for the first time according to the Poisson distribution. For example, when the expected number is 4 and the uniform number is 0.62, the cumulative probability reaches 0.629 at the integer 4, so the number of writes is 4. The number of writes for each time segment is recorded to obtain the frequency of sudden events written to the local dynamic map layer.

[0030] The steps to obtain the dirty data status are as follows: Read the write count corresponding to each time segment in the time segment order, establish an equal number of message sequence numbers based on the write count, read the preset dynamic map layer identifier, write the dynamic map layer identifier into the target layer field of each message according to the message sequence number, extract the traffic event type, event occurrence coordinates, event impact direction, event start time, event duration, and event status parameters from the simulated traffic event elements one by one, write the extraction results into the message content area in the order of field arrangement, set the message operation field to the overwrite instruction, write the corresponding message sequence number, generation timestamp, message length, and verification identifier into the message header, classify all messages into time segments according to the write frequency of the sudden event, and generate application layer write messages; The system calls the frequency of writes for sudden events, determines the number of messages to be sent based on the number of writes corresponding to each time segment, and determines the sending interval between adjacent messages based on the length of the time segment. Application layer write messages are arranged into a sending queue according to their sequence number. When the corresponding sending timestamp is reached, the application layer write message is sent to the edge node one by one. The system receives write confirmation status returned by the edge node. If the write confirmation status indicates successful writing, the next application layer write message is sent. If the write confirmation status does not return within the preset confirmation time limit, the current application layer write message is resent. The system locates the local dynamic map layer data within the edge node based on the dynamic map layer identifier, replaces the simulated traffic event elements to the corresponding layer positions according to the overwrite instruction, and records the layer version parameters, modification time parameters, and persistence synchronization status after each replacement. If the layer version parameters corresponding to the same dynamic map layer identifier change again before persistence synchronization is completed, the local dynamic map layer data corresponding to the latest layer version parameters is marked as dirty data. An invalid data identifier parameter is generated based on the dynamic map layer identifier, and the edge node is controlled to publish a cache invalidation notification message carrying the invalid data identifier parameter, generating a dirty data status and triggering the cache invalidation notification message.

[0031] Specifically, the integer write counts in the event write frequency are read sequentially according to time segments. For each time segment, a consecutive message sequence number is generated starting from 1. When the write count is 0, the time segment is retained without generating a message. When the write count is greater than 0, the dynamic map layer identifier is read, and the same layer identifier is written to the target layer field of all messages in that time segment. Then, the traffic event type, event coordinates, event direction of influence, event start time, event duration, and event status parameters are extracted item by item from the simulated traffic event elements. The traffic event type uses a pre-registered enumeration code: 01 for accidents, 02 for road construction, and 03 for temporary closures. The event coordinates are written in horizontal, vertical, and vertical order and uniformly use meters (m). The event direction of influence uses a directional code relative to the road centerline. The event start time uses UTC microseconds. The timestamp and event duration are in milliseconds. The event status parameters use three enumerated values: add, update, and deactivate. These fields are serialized into the message content area in a fixed order. The message operation field contains the overwrite instruction. The message header sequentially contains the protocol version, message sequence number, generation timestamp, target layer identifier, message length, and checksum. The message length is obtained by adding the number of bytes in the header to the number of bytes in the content area. The checksum is calculated using the CRC-32 polynomial 0x04C11DB7 for all bytes except the checksum field. If the message sequence number is repeated within the same time segment, it is renumbered. If the event start time exceeds the range of the corresponding time segment, it is classified into the next time segment. If a field is missing, the assembly of the message is stopped and the name of the missing field is recorded. All valid messages are arranged by time segment sequence number and message sequence number, and the application layer write message is generated.

[0032] The system retrieves the write count and time segment length segment by segment based on the burst event write frequency. When the write count is 0, the sending queue remains idle. When the write count is greater than 0, the sending interval between adjacent messages is obtained by dividing the time segment length by the write count. For example, if 5 writes are scheduled within 10 seconds, the sending interval is set to 2 seconds. Application layer write messages are written to the sending queue according to the time segment sequence number and message sequence number. After the corresponding sending timestamp is reached, the current message is sent to the edge node and waits for the write confirmation status. The confirmation time limit is set based on the round-trip time of the last 20 writes of the same message length, taking the maximum value of the maximum round-trip time plus the edge layer write time. For example, if the maximum round-trip time is 8ms and the maximum layer write time is 4ms, then the confirmation time limit is set to 12ms. After receiving the write success status, the next message is sent. If no status is received within 12ms, the current message is retransmitted. Each message is sent a maximum of 3 times, with the 3rd timeout based on the settings of the most recent 20 confirmations. All 20 confirmations return a confirmation status before the 3rd transmission. The corresponding layer position is located based on the dynamic map layer identifier. The traffic event type, event coordinates, event direction of influence, event start time, event duration, and event status parameters are replaced according to the overwrite instruction. After each replacement, the layer version parameter is incremented and the modification time parameter and persistent synchronization status are recorded. If the persistent synchronization status is still in progress and the same layer version is incremented again, the layer data corresponding to the latest version is marked as dirty data. Then, the dynamic map layer identifier, the latest layer version parameter, and the modification time parameter are concatenated to generate the invalid data identifier parameter. A cache invalidation notification message carrying the invalid data identifier parameter is issued to obtain the dirty data status and trigger the cache invalidation notification message.

[0033] The steps to obtain a condition-validated retransmission request are as follows: Listen to the message queue telemetry transmission protocol publishing port of the edge node, read the fixed header, topic name, quality of service level, message identifier, remaining length, and payload content of the output message of the publishing port, filter the published messages whose topic names point to the cache invalidation notification topic, perform deduplication on duplicate published messages according to the message identifier, perform sequential concatenation of segmented payload content according to the fragment sequence number, verify the message length, verification identifier, and publishing timestamp of the concatenated payload content, retain the published messages with matching message length and consistent verification identifier, record the corresponding receiving timestamp, and obtain the cache invalidation notification message; Based on the cache expiration notification message, the expired data identifier parameter, dynamic map layer identifier, layer version parameter, and modification time parameter are parsed in the order of the load fields. The node identifier associated in the fleet coordination status matrix is ​​retrieved based on the expired data identifier parameter. Each virtual vehicle node is located row by row. The entity label field and modification time verification field of the corresponding expired data identifier parameter are read from the local cache of each virtual vehicle node. If the entity label field exists, it is written to the corresponding protocol header. If the entity label field does not exist, the modification time verification field is written to the corresponding protocol header. The expired data identifier parameter is written to the request resource location field, and the node identifier is written to the request source field. A conditional verification retransmission request is generated. Establish concurrent sending queues for each virtual vehicle node according to the node identifier, lock the sending timestamps of each concurrent sending queue to the same sending time, synchronously open the sending ports of each virtual vehicle node, concurrently push conditional verification retransmission requests to edge nodes, listen to the consistency comparison status returned by edge nodes, filter conditional verification retransmission requests with mismatched entity label fields or modification time verification fields earlier than the current layer modification time parameter, track the conditional verification back-to-origin requests initiated by edge nodes to the cloud center server based on the filtering results, continuously record the number of active connections, the number of connections waiting, the number of backlogged sending queues, the number of backlogged receiving queues, the number of message retransmissions, the number of request timeouts, and the connection release timestamps, summarize the records according to the sampling time order, and obtain the concurrent protocol stack processing pressure.

[0034] Specifically, the message queue telemetry transmission protocol publishing port of the edge node is monitored. The message type, duplicate transmission flag, and service quality level in the fixed header of each PUBLISH message are read sequentially. Then, the topic name, message identifier, remaining length, and payload content are read. The topic name is compared using a step-by-step string comparison. Only messages that completely match the cache invalidation notification topic are processed further. If the service quality level is 1, the message identifier is retained and a publishing confirmation is returned. If the duplicate transmission flag is 1 and the message identifier, topic name, and publishing timestamp are all consistent with received messages, it is considered a duplicate publication and deduplication is performed. If the message payload is fragmented, the invalid data identifier parameter, fragment sequence number, total number of fragments, and fragment length are read. The fragments are concatenated in order from fragment sequence number 0 to the total number of fragments minus 1. If a fragment sequence number gap exists, the process waits until the end of the current session's retransmission. If there is still a gap in the bundle, discard the bundle. After splicing, first check the actual number of bytes of the load with the remaining length field, then recalculate and compare according to the CRC-32 check mark declared in the message. The allowed clock deviation range of the published timestamp is set by adding the maximum node deviation obtained from the most recent time synchronization and the maximum forwarding delay of the message queue. For example, the maximum node deviation is 35ms, the maximum forwarding delay is 120ms, and a 45ms scheduling margin is reserved. The allowed deviation is 200ms. Messages whose published timestamp is earlier than the received timestamp and exceeds the cache notification validity period or later than the received timestamp by 200ms are not retained. The cache notification validity period is the 30s version window retained by the corresponding layer version at the edge node. For messages with matching length, consistent verification, and valid time, record the received timestamp to obtain the cache invalidation notification message.

[0035] Based on the cache expiration notification message, the expiration data identifier parameter, dynamic map layer identifier, layer version parameter, and modification time parameter are parsed in the order of the load fields. First, the node identifier is obtained row by row according to the node row index of the fleet coordination status matrix. Then, the cache entries with the dynamic map layer identifier as the resource key are read from the cache of each node. If the cache entry does not exist, the node is added to the no-cache request queue. If the cache entry exists, its expiration data identifier parameter is compared with the expiration data identifier parameter in the notification. If they match, the entity tag field and modification time verification field are read. If they do not match, a new request is still assembled according to the expiration data identifier parameter in the notification. If the entity tag field exists, the value is written to the If-None-Match protocol header using the HTTP conditional request rule. If the entity tag field does not exist but the modification time verification field exists, the time is converted to HTTP date format and written to the If-Mod header. The `ified-Since` header is used. If neither of the two fields exists, the conditional header is omitted, and the request type is marked as a complete retry. The invalid data identifier parameter is written to the request resource location field, the node identifier is written to the request source field, and the dynamic map layer identifier, the layer version parameter from the notification, and the modification time parameter are written to the request extension field. When both the entity label field and the modification time validation field exist, the entity label field takes precedence, based on the HTTP conditional request processing order. After assembly, the header checks whether the resource location field contains the dynamic map layer identifier, whether the request source field matches the node row index, and whether the header length is within the 0KB to 8KB range configured in the edge node's HTTP request header. If it exceeds 8KB, the layer version parameter in the request extension field is deleted, and the length is recalculated. Valid requests are arranged by node row index, and a conditional validation retransmission request is generated.

[0036] Concurrent sending queues are established according to the node identifiers in the fleet coordination state matrix. Conditional verification retransmission requests are written to the corresponding queues according to the node row index, and the sending timestamp of the first request in all queues is set to the same sending time. This sending time is taken as the next 1ms clock increment after the cache invalidation notification message is received. 1ms is taken as the minimum virtual vehicle sending scheduling cycle. Upon reaching this time, all sending queues are simultaneously unblocked and sending ports are opened. The timestamps of each request entering the protocol stack, completing the handshake, sending completion, receiving the response, and connection release are recorded. The 304, 200, and timeout statuses returned by the edge nodes are read. 304 corresponds to consistent condition fields, while 200 corresponds to mismatched entity label fields or a cache modification time earlier than the current layer's modification time parameter. Only the cloud center server connection corresponding to 200 and timeout requests is tracked, and data is collected within the edge node network namespace at 5m intervals. The system reads the number of active connections, the number of connections waiting, the number of backlogged connections in the send queue, the number of backlogged connections in the receive queue, the number of message retransmissions, and the number of request timeouts at intervals of s. The 5ms interval is obtained by rounding down the minimum round-trip time of 6ms for the last 10 conditional validation origin requests. The connection release timestamp is obtained when the connection status changes from established to closed. The number of active connections is counted according to the established state. The number of connections waiting is counted according to half-connections and connections waiting to be accepted. The number of backlogged connections in the send and receive queues is counted according to the number of currently unprocessed messages in the protocol stack. The number of message retransmissions is counted according to the number of retransmissions with the same sequence number. The conditional validation request timeout is set according to the last 20 origin requests in the same layer. The maximum round-trip time of 25ms is taken and the edge comparison time of 5ms is added to get 30ms. The number of request timeouts is counted according to whether there is a response after 30ms. The above records are summarized in the order of sampling time to obtain the concurrent protocol stack processing pressure.

[0037] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for simulating V2X communication load based on edge nodes, characterized in that, Includes the following steps: The fleet coordination state matrix is ​​obtained based on the node identifier, velocity vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area. Based on the fleet coordination state matrix, predict the synchronous spatial coordinates that cross the service boundary of the edge node, and align the preset application layer data download command trigger time parameters to generate a synchronous application layer request payload set with a unified absolute trigger time. When the unified absolute trigger time is reached, each of the virtual vehicle nodes is controlled to concurrently send the synchronous application layer request payload set to the edge node so that it reaches the edge node within the concurrency window period; During the concurrency window, monitor the uplink network traffic forwarded by the edge node to the cloud central server; If multiple back-to-source data synchronization messages targeting the same data file identifier are parsed from the uplink network traffic within a preset time threshold, it is determined that the cache mutex lock of the edge node has been breached and recorded as a penetration failure feature. The frequency of sudden events written to the local dynamic map layer is obtained based on the spatial coordinate span parameters of the edge coverage area and the preset time dimension coordinate system. Based on the frequency of emergency event writes, the preset dynamic map layer identifiers, and simulated traffic event elements, an application layer write message containing overwrite instructions is generated; the application layer write message is sent according to the frequency of emergency event writes to overwrite the local dynamic map layer data inside the edge node, forcing the edge node to generate a dirty data state and triggering a cache invalidation notification message.

2. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The method further includes: Receive the cache invalidation notification message sent by the edge node through the message queue telemetry transmission protocol publishing port; Parse the invalid data identifier parameter in the cache invalidation notification message, trigger each of the virtual vehicle nodes to generate a conditional verification retransmission request carrying an entity tag field or modification time verification field corresponding to the invalid data identifier parameter; push the conditional verification retransmission request to the edge node, and monitor the concurrent protocol stack processing pressure of the edge node initiating a conditional verification back-to-origin request to the cloud center server.

3. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The steps for obtaining the fleet coordination state matrix are as follows: Read the node identifier, velocity vector parameters, and spatial coordinate parameters of each virtual vehicle node within the edge coverage area. Establish a node row index according to the character order of the node identifier. Decompose the velocity vector parameters into lateral velocity components, longitudinal velocity components, and height velocity components. Decompose the spatial coordinate parameters into lateral coordinate components, longitudinal coordinate components, and height coordinate components. Calculate the vector mean of each component in all virtual vehicle nodes. Call the preset velocity weight parameters and spatial coordinate weight parameters to perform component product superposition on the original components and corresponding vector mean of each virtual vehicle node. Write the superposition result into the corresponding matrix row and column according to the node row index to obtain the fleet coordination state matrix.

4. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The steps for obtaining the synchronous application layer request payload set are as follows: According to the fleet coordination state matrix, the lateral velocity component, longitudinal velocity component, height velocity component, lateral coordinate component, longitudinal coordinate component, and height coordinate component of each virtual vehicle node are read row by row according to the node row index. The spatial movement direction of each virtual vehicle node is determined according to the positive and negative directions of the velocity components. The current position is extended along the spatial movement direction to form a movement trajectory. The boundary coordinate sequence of the service boundary of the edge node is extracted. The intersection position of the movement trajectory and the boundary coordinate sequence is determined segment by segment. The spatial distance from the current position to the intersection position is calculated. The boundary crossing time is determined according to the spatial distance and the velocity vector length. The latest time among all boundary crossing times is selected as the synchronous boundary crossing time. The position coordinates corresponding to each virtual vehicle node are calculated according to the synchronous boundary crossing time to obtain the synchronous spatial coordinates. Read the synchronization boundary crossing time associated with the synchronization spatial coordinates, convert the synchronization boundary crossing time into an absolute timestamp under a unified time zone and unified time precision, determine the absolute timestamp as the unified absolute trigger time, read the preset application layer data download instructions and trigger time parameters one by one, delete the original relative trigger time parameters of each application layer data download instruction, write the unified absolute trigger time into the corresponding trigger field, establish the correspondence between virtual vehicle nodes and application layer data download instructions according to node identifiers, write the node identifier, application layer data download instructions, and unified absolute trigger time into the request payload in sequence, merge all request payloads according to the unified absolute trigger time, and generate a synchronization application layer request payload set.

5. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The steps for obtaining the uplink network traffic are as follows: When the unified absolute trigger time is reached, the node row index in the fleet coordination state matrix is ​​read, each virtual vehicle node is located according to the node row index, the node identifier and sending status corresponding to each virtual vehicle node are verified, the synchronous application layer request payload set is called, each synchronous application layer request payload is allocated to the corresponding virtual vehicle node according to the node identifier, the sending clock of each virtual vehicle node is uniformly locked to the unified absolute trigger time, the sending port of each virtual vehicle node is synchronously opened when the unified absolute trigger time is reached, the sending timestamp, arrival timestamp, and data file identifier of each application layer request are continuously recorded, and application layer requests whose arrival timestamps are within the concurrent window period are filtered to form an application layer request arrival record within the concurrent window period. Based on the application layer request arrival records within the concurrency window, the start and end timestamps of the concurrency window are extracted. The edge node uplink port listening is started according to the start timestamp and ended according to the end timestamp. The packets forwarded by the edge node to the cloud central server are read frame by frame. The packet generation timestamp, packet sending timestamp, source port identifier, destination port identifier, transport protocol identifier, and data file identifier of each packet are recorded. Packets whose generation timestamps exceed the concurrency window are removed. Packets whose destination port identifiers point to the cloud central server are retained. The retained packets are arranged in the order of their generation timestamps to generate uplink network traffic.

6. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The steps for obtaining the penetration failure characteristics are as follows: Based on the uplink network traffic, the starting timestamp of the concurrent window period is used as the timing start point. The packet parsing deadline timestamp is determined according to a preset time threshold. The packet type field, data file identifier field, origin direction field, and synchronization status field are parsed frame by frame. Packets whose packet type field points to data synchronization packets and whose origin direction field points to the cloud central server are identified as origin data synchronization packets. The origin data synchronization packets are grouped and counted according to the data file identifier field. If the number of origin data synchronization packets corresponding to any data file identifier is greater than one within the preset time threshold, it is determined that the edge node has repeatedly initiated origin synchronization for the same data file identifier. It is confirmed that the cache mutex lock of the edge node has been broken. The corresponding data file identifier, the number of origin data synchronization packets, and the packet generation timestamp are recorded to form a penetration failure feature.

7. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The steps for obtaining the frequency of writes to the sudden event are as follows: Extract the horizontal, vertical, and height coordinate parameters of each boundary point in the edge coverage area, arrange the corresponding coordinate parameters according to the coordinate axis direction, select the maximum and minimum coordinate parameters in each coordinate axis direction, calculate the coordinate difference obtained by subtracting the minimum coordinate parameter from the maximum coordinate parameter, and form a spatial coordinate span parameter. Read the start time parameter, time segment length, number of time segments, and time segment order in the preset time dimension coordinate system, divide the spatial coordinate span parameter into spatial event units according to the number of time segments, count the number of spatial event units corresponding to each time segment, call the preset basic trigger intensity parameter, determine the expected number of event triggers segment by segment based on the number of spatial event units and the time segment length, discretize the expected number of event triggers, and write the discretization result into the corresponding time segment to obtain the frequency of sudden events written to the local dynamic map layer.

8. The V2X communication load simulation method based on edge nodes according to claim 1, characterized in that, The steps for obtaining the dirty data status are as follows: Read the write count corresponding to each time segment in the time segment order, establish an equal number of message sequence numbers based on the write count, read the preset dynamic map layer identifier, write the dynamic map layer identifier into the target layer field of each message according to the message sequence number, extract the traffic event type, event occurrence coordinates, event influence direction, event start time, event duration, and event status parameters from the simulated traffic event elements one by one, write the extraction results into the message content area according to the field arrangement order, set the message operation field to the overwrite instruction, write the corresponding message sequence number, generation timestamp, message length, and verification identifier into the message header, classify all messages by time segment according to the write frequency of the sudden event, and generate application layer write messages; The system calls the frequency of writing the sudden event, determines the number of messages to be sent according to the number of writes corresponding to each time segment, determines the sending interval of adjacent messages according to the length of the time segment, arranges the application layer write messages into the sending queue according to the message sequence number, and sends the application layer write messages to the edge node one by one when the corresponding sending timestamp is reached. It receives the write confirmation status returned by the edge node. When the write confirmation status indicates that the write was successful, it continues to send the next application layer write message. If the write confirmation status does not return within the preset confirmation time limit, it resends the current application layer write message. It locates the local dynamic map layer data inside the edge node according to the dynamic map layer identifier, replaces the simulated traffic event elements to the corresponding layer position according to the overwrite instruction, and records the layer version parameters, modification time parameters, and persistence synchronization status after each replacement. If the layer version parameters corresponding to the same dynamic map layer identifier change again before the persistence synchronization is completed, the local dynamic map layer data corresponding to the latest layer version parameters is marked as dirty data. It generates invalid data identifier parameters according to the dynamic map layer identifier, controls the edge node to publish a cache invalidation notification message carrying the invalid data identifier parameters, generates dirty data status and triggers the cache invalidation notification message.

9. The V2X communication load simulation method based on edge nodes according to claim 2, characterized in that, The steps for obtaining the conditional verification retransmission request are as follows: The message queue telemetry transmission protocol publishing port of the edge node is monitored. The fixed header, topic name, quality of service level, message identifier, remaining length, and payload content of the output message of the publishing port are read. The published messages with topic names pointing to the cache invalidation notification topic are filtered. Duplicate published messages are deduplicated according to the message identifier. The segmented payload content is sequentially concatenated according to the fragment sequence number. The message length, verification identifier, and publishing timestamp of the concatenated payload content are verified. Published messages with matching message lengths and consistent verification identifiers are retained. The corresponding receiving timestamp is recorded to obtain the cache invalidation notification message. According to the cache failure notification message, the failure data identifier parameter, dynamic map layer identifier, layer version parameter, and modification time parameter are parsed in the order of the load fields. Based on the failure data identifier parameter, the associated node identifier in the fleet coordination state matrix is ​​retrieved. Each virtual vehicle node is located row by row. The entity tag field and modification time verification field of the corresponding failure data identifier parameter in the local cache of each virtual vehicle node are read. If the entity tag field exists, it is written to the corresponding protocol header. If the entity tag field does not exist, it is written to the corresponding protocol header. The failure data identifier parameter is written to the request resource location field, and the node identifier is written to the request source field. A conditional verification retransmission request is generated. Establish concurrent sending queues for each virtual vehicle node according to the node identifier, lock the sending timestamps of each concurrent sending queue to the same sending time, synchronously open the sending ports of each virtual vehicle node, concurrently push the conditional verification retransmission request to the edge node, listen to the consistency comparison status returned by the edge node, filter the conditional verification retransmission requests where the entity label field does not match or the modification time verification field is earlier than the current layer modification time parameter, track the conditional verification back-to-origin requests initiated by the edge node to the cloud center server based on the filtering results, continuously record the number of active connections, the number of connections waiting, the number of backlogged sending queues, the number of backlogged receiving queues, the number of message retransmissions, the number of request timeouts, and the connection release timestamp, summarize the records according to the sampling time order to obtain the concurrent protocol stack processing pressure.

Images