Entity on-demand pushing method and device for large-scale LVC simulation

Abstract

The invention discloses an entity on-demand pushing method for large-scale LVC simulation, and the method comprises the steps: dividing a region which needs to be simulated according to the position of a user, the type of a simulation task, and a region which is concerned by the user; identifying a user demand based on the user behavior pattern, and determining an entity list needing to be pushed in the area needing to be simulated according to the user demand; based on the importance and complexity of the entities and the degree of association with the users, corresponding pushing priority and pushing frequency are distributed to each entity in the entity list; compressing and encoding the entity data needing to be pushed; and pushing the compressed and coded entity data of each entity in the entity list according to the corresponding pushing priority and pushing frequency. The invention further discloses an entity on-demand pushing device for the large-scale LVC simulation. According to the method, related entity data can be intelligently and efficiently pushed according to different user requirements, so that information transmission and computing resource use in a large-scale LVC simulation system are optimized.

Description

Technical Field

[0001] The present invention relates to the field of simulation technology, and more particularly to an entity on-demand push method and device for large-scale LVC simulation. Background Art

[0002] With the continuous development of simulation technology, LVC simulation has been widely used in various fields such as military training, aerospace, transportation, and smart cities. LVC simulation systems are usually composed of a large number of virtual entities, on-site entities, and constructed entities, and have complex interactivity and real-time performance. However, in large-scale LVC simulation scenarios, due to the large number of entities and complex interactions, existing entity management and data push mechanisms have the following problems: 1. High bandwidth and computing resource pressure: In large-scale simulations, the system needs to handle the data transmission and calculation of a large number of entities, which may lead to insufficient bandwidth and computing resources, thus affecting the simulation quality and real-time performance; 2. Inefficient entity status update mechanism: Existing entity data update mechanisms are usually based on a global broadcast method. Each simulation participant must receive information from all entities. This results in excessive data redundancy and transmission overhead for large-scale simulation environments; 3. Inability to accurately meet the needs of different users: Because different users focus on different entities and information, a unified push mechanism cannot push the most relevant entity data to specific users on demand, resulting in information overload or omissions.

[0003] Large-scale LVC (Live, Virtual, Constructive) simulation systems typically operate in distributed network environments, involving numerous user nodes (such as simulators, C4ISR systems, and virtual force generators) interacting over wide area networks (WANs) or complex local area networks (LANs) or private networks. These environments face significant challenges related to highly complex and unstable network states, primarily manifested in the following aspects: Significant bandwidth fluctuations: The available network bandwidth is not constant and can fluctuate dramatically due to factors such as link congestion, cross-domain transmission, wireless signal attenuation, and background traffic bursts. It can even often drop to a threshold far below the expected level.

[0004] Large variations in transmission quality: The packet loss rate, delay, and jitter of the network paths where different user nodes are located vary greatly and change dynamically. Especially for mobile users or users accessing through unstable links (such as satellites and tactical radio stations), the quality of data transmission is difficult to guarantee.

[0005] Frequent failures and interruptions: Network node failures, link disconnections, route switching and other events are not uncommon in large distributed systems, resulting in data transmission failures or timeouts, affecting the continuity and consistency of simulation entity status information.

[0006] Insufficient end-to-end status perception: The server side can usually only monitor the network status of its own exit (such as local bandwidth, topology), and it is difficult to accurately and in real time perceive the quality of the data actually received by each user terminal (such as the actual packet loss and delay on the user side), resulting in a lack of accurate basis for push strategy adjustments.

[0007] The main limitations of existing technologies in this pain point include: Static or coarse-grained adaptation: Existing push policies are often based on preset rules or rely solely on coarse-grained server-side network status monitoring (such as global bandwidth thresholds). These policies lack closed-loop feedback and granular responsiveness to individual users' end-to-end quality of service (QoS). When a user experiences localized network degradation, the system may be unable to adjust their data flow in a timely and targeted manner.

[0008] Lack of or inflexible fault-tolerance mechanisms: Faced with frequent push failures or timeouts, existing solutions either lack effective automatic response mechanisms, resulting in continuous retransmissions that waste resources and increase network burdens. Alternatively, they employ overly simplistic and inflexible approaches (such as simply discarding data or disconnecting the connection), failing to gracefully degrade while ensuring basic simulation continuity. This results in a sharp decline in user experience during periods of network instability, loss of critical entity information, and even disruptions to the normal progress of simulation tasks.

[0009] Lack of closed-loop optimization: There is a lack of an effective feedback loop between the adjustment of push strategies and the end-user reception effect, making it difficult to achieve dynamic and adaptive optimization based on the actual reception experience.

[0010] Therefore, there is an urgent need for an entity push method that can effectively cope with the complex and changing network environment in large-scale LVC simulation. It needs to have the following features: Accurate end-to-end quality perception: Able to obtain and respond to actual reception quality feedback from user terminals in real time.

[0011] Fine-grained dynamic adaptation: Based on the above feedback, it can make real-time and precise push strategy adjustments (such as frequency, compression rate, and retransmission) to the data stream of a single user or entity.

[0012] Robust fault tolerance and degradation capabilities: When a transmission failure is detected, it can automatically trigger intelligent degradation strategies (such as switching to summary information, selective frequency reduction / compression), prioritizing the accessibility of critical information and basic consistency of the simulation, rather than complete interruption or inefficient retry. Summary of the Invention

[0013] The purpose of the present invention is to provide an entity on-demand push method and device for large-scale LVC simulation, which can intelligently and efficiently push relevant entity data according to different user needs to optimize information transmission and computing resource utilization in large-scale LVC simulation systems.

[0014] In order to achieve these objectives and other advantages according to the present invention, a method for entity on-demand push for large-scale LVC simulation is provided, comprising: Divide the simulation area according to the user's location, simulation task type and user's focus area; Identify user needs based on user behavior patterns and determine the list of entities that need to be pushed in the simulation area based on user needs; Assign corresponding push priority and push frequency to each entity in the entity list based on the entity's importance, complexity, and relevance to the user; Compress and encode the entity data to be pushed; Push the compressed and encoded entity data of each entity in the entity list according to the corresponding push priority and push frequency; Among them, during the push process: Receive QoS feedback information about the quality of entity data reception from the user end, and dynamically adjust the push frequency, compression rate or retransmission strategy of the entity data of the corresponding entity or user as a whole according to the QoS feedback information; Real-time monitoring of push failure or timeout events. When the push failure rate for a specific entity or user exceeds a preset threshold, a downgrade strategy is automatically triggered. The downgrade strategy includes: temporarily increasing the compression rate of the entity data, reducing the push frequency of the entity, or pausing the push of the entity and attempting to push its simplified status summary information.

[0015] Preferably, the compression and encoding of the entity data adopts a dynamic data compression method; wherein, the compression and encoding of the entity data adopts a dynamic data compression method, and when the network bandwidth is detected to be lower than a preset threshold, the compression rate of the entity data is increased; The preset threshold for push failure rate is a dynamic value, calculated in real time based on at least one of the following factors: The push priority of the entity. The higher the priority, the lower the threshold; User-side historical network stability indicator. The worse the stability, the higher the threshold. The criticality level of the current simulation task. The higher the criticality, the lower the threshold. A sliding time window mechanism is used to monitor the push failure rate. The window length is configurable, and the degradation strategy is triggered only when the number of consecutive sampling points exceeding the threshold in the window exceeds 50%.

[0016] Preferably, the dynamic data compression method includes: when it is monitored that the network bandwidth is lower than a preset threshold, increasing the compression rate of the entity data to reduce the data transmission volume.

[0017] Preferably, during the entity data push process, the push strategy is also adaptively adjusted based on the network topology and network bandwidth status; this includes: establishing a network status quantification model, converting the network topology into a topology complexity score based on node connectivity, path hop count, and link redundancy, and converting the network bandwidth status into bandwidth utilization: currently used bandwidth / total available bandwidth; Based on the topology complexity score and bandwidth utilization, the push policy adjustment plan and its effective range are determined according to the preset hierarchical decision rules, where: When the bandwidth utilization is higher than a first threshold and the topology complexity score is higher than a second threshold, the overall push frequency of the user is reduced; When the bandwidth utilization is higher than the third threshold and the topology complexity score is lower than the fourth threshold, only the push frequency of non-critical path users is reduced; When the bandwidth utilization is lower than the fifth threshold, the original push strategy is restored.

[0018] Preferably, adaptively adjusting the push strategy based on the network topology and network bandwidth status includes: when it is monitored that the network topology is a preset network topology and / or the network bandwidth is lower than a preset threshold, reducing the push frequency of entity data, or choosing to push only part of the entity data.

[0019] Preferably, when assigning push priority and push frequency to each entity in the entity list, a high push frequency is assigned to a high-priority entity, and a low push frequency is assigned to a low-priority entity.

[0020] Preferably, the system dynamically monitors changes in network load and user demand, and triggers a push frequency rebalancing mechanism when any of the following conditions are met: The total bandwidth usage of the high-priority entity group exceeds the preset threshold; Users proactively increase the attention level of specific low-priority entities; The status update delay of a low-priority entity exceeds its maximum tolerable delay; The rebalancing mechanism includes: Proportionally reduce the push frequency of high-priority entity groups, Or allocate temporary high-frequency channels for critical low-priority entities, At the same time, it ensures that the update delay of all entities does not exceed the maximum tolerable delay threshold corresponding to their priority level.

[0021] The present invention also provides an entity on-demand push device for large-scale LVC simulation, comprising: The area division module is used to divide the area to be simulated according to the user's location, simulation task type and user's focus area; The demand perception module is used to identify user needs based on user behavior patterns and determine the list of entities that need to be pushed in the simulation area according to user needs; Priority scheduling module, which is used to assign corresponding push priority and push frequency to each entity in the entity list based on the importance, complexity and relevance of the entity to the user; A data compression module is used to compress and encode the entity data that needs to be pushed; The entity push module is used to push the compressed and encoded entity data of each entity in the entity list according to the corresponding push priority and push frequency.

[0022] The present invention also provides an electronic device, comprising: at least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the above-mentioned method.

[0023] The present invention also provides a storage medium on which a computer program is stored. When the program is executed by a processor, the above method is implemented.

[0024] The present invention includes at least the following beneficial effects: the present invention adopts an on-demand push mechanism to avoid the transmission of redundant data, reduce the pressure on network bandwidth, and improve data transmission efficiency; at the same time, by dynamically adjusting the push frequency and compression rate, it reduces unnecessary data calculation and storage burdens and improves the utilization rate of computing resources; and adjusts the push content and frequency according to user needs, so that the system can accurately meet the user's simulation needs and improve the real-time response capability of the simulation system; in addition, it can flexibly adjust the push strategy according to different network environments and user needs to adapt to various changing simulation scenarios. In general, it can effectively solve the problems of insufficient bandwidth, high computing pressure, and information redundancy in traditional simulation systems, and optimize the performance and resource utilization of the simulation system. This method is applicable to various large-scale simulation scenarios and has broad application prospects.

[0025] Other advantages, objectives and features of the present invention will be reflected in part from the following description and will be understood by those skilled in the art through study and practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] Figure 1 This is a flowchart of the entity on-demand push method for large-scale LVC simulation according to an embodiment of the present invention; Figure 2This is a structural diagram of an entity on-demand push device for large-scale LVC simulation according to an embodiment of the present invention. DETAILED DESCRIPTION

[0027] The present invention will be described in further detail below in conjunction with the accompanying drawings so that those skilled in the art can implement the invention with reference to the description.

[0028] It should be noted that the experimental methods described in the following embodiments are conventional methods unless otherwise specified, and the reagents and materials are commercially available unless otherwise specified; in the description of the present invention, the terms "horizontal", "longitudinal", "upper", "lower", "front", "back", "left", "right", "vertical", "horizontal", "top", "bottom", "inside", "outside" and the like indicate orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation to the present invention.

[0029] In large-scale Live, Virtual, Constructive (LVC) simulation environments, pushing entity data is crucial for ensuring effective simulation and user experience. Given the vast simulation area and the large number of entities, efficiently and accurately pushing entity data based on user needs, entity characteristics, and the network environment is a pressing challenge. This paper proposes an on-demand entity push method for large-scale LVC simulations. This method comprehensively considers multiple factors, including user location, simulation task, user focus area, entity importance, complexity, user relevance, and network environment, to achieve intelligent and dynamic push of entity data.

[0030] like Figure 1 As shown, the entity on-demand push method for large-scale LVC simulation includes: S1. Divide the simulation area according to the user's location, simulation task type and user's focus area; In a large-scale LVC simulation environment, due to limited resources, it is impossible to perform a comprehensive and detailed simulation of the entire simulation space. Therefore, it is necessary to dynamically divide the area to be simulated based on the user's location, simulation task type, and user's focus area.

[0031] Specifically, the user's location is the basis for dividing the simulation area. The system can obtain the user's real-time location information through GPS positioning, user input, and the built-in positioning system of the simulation environment.

[0032] Different simulation tasks have different requirements for the simulation area. For example, a tactical exercise might focus on battlefield layout and troop deployment in a specific area, while a logistics simulation might focus on optimizing transportation routes and warehouse management. Therefore, the system needs to analyze the key areas involved based on the type of simulation task.

[0033] User attention areas can be identified through various methods such as user historical behavior, interaction records, gaze direction, operating habits, etc. For example, the system can record areas that users frequently view, points of interest that users actively mark, and areas where users spend a long time looking at, as references for user attention areas.

[0034] Taking into account the user's location, simulation task type, and user's area of ​​interest, the system uses spatial partitioning algorithms (such as quadtree, grid partitioning, and KD tree) to divide the entire simulation space into several sub-areas. Areas that are close to the user's location, closely related to the simulation task, and highly user-interested are marked as "needing simulation areas" and serve as the focus of subsequent data processing and push.

[0035] S2. Identify user needs based on user behavior patterns and determine a list of entities that need to be pushed in the simulation area according to the user needs; After dividing the area that needs to be simulated, the next step is to identify user needs and determine the list of entities that need to be pushed.

[0036] Specifically, identifying user behavior patterns is key to understanding user needs. The system can analyze historical user behavior data, interaction records, and operational habits through machine learning algorithms (such as cluster analysis, decision trees, and neural networks) or rule-matching methods to identify user preferences, interests, and focus areas.

[0037] Based on the results of user behavior pattern recognition, the system can infer the user's specific needs in the current simulation task. For example, if a user frequently checks the battlefield situation in a certain area, the system can determine that the user has a high demand for battlefield information in that area.

[0038] Based on user needs, the system traverses all entities within the simulated area, filters out entities that are highly relevant to the user's focus, and forms a list of entities to be pushed. This screening process can take into account multiple factors, such as entity type, attributes, status, and location. For example, in a battlefield simulation, a user might be interested in information such as the position, speed, and weapon configuration of enemy tanks. In this case, the system would include these tank entities in the push list.

[0039] S3. Assign a corresponding push priority and push frequency to each entity in the entity list based on the entity's importance, complexity, and relevance to the user; For each entity in the entity list, the system needs to assign it a push priority and push frequency to ensure that key information can be conveyed to users in a timely and accurate manner.

[0040] Specifically, the importance of entities is a key factor in assigning push priorities. The system can assess the importance of entities within the simulation environment based on factors such as their type, role, and influence. For example, key nodes (such as command centers and transportation hubs) and event triggers (such as enemy main forces and important targets) are generally considered highly important.

[0041] The complexity of an entity determines the difficulty of processing and transmitting its data. The system assesses the complexity of an entity based on factors such as the entity's model sophistication, computing resource consumption, and data update frequency. More complex entities may require more computing resources and network bandwidth for transmission and processing.

[0042] User relevance is an important indicator of the closeness of the relationship between an entity and a user. The system can assess this relevance based on factors such as the distance between the entity and the user, interaction history, and user attention. Entities with higher relevance typically attract more user attention and therefore require a higher push frequency.

[0043] The system uses a multi-metric evaluation method (such as weighted average and fuzzy comprehensive evaluation) to assign a unique push priority and frequency to each entity, taking into account its importance, complexity, and relevance to users. Generally, high-priority entities are assigned a higher push frequency to ensure timely delivery of critical information; low-priority entities are assigned a lower push frequency to reduce unnecessary network load and computing resource consumption.

[0044] S4. Compress and encode the entity data to be pushed; Before pushing entity data, the system needs to compress and encode the data to reduce the amount of data transmission and improve transmission efficiency.

[0045] Specifically, the choice of data compression method requires a careful balance between the characteristics of the data and the network environment. For data with high real-time requirements (such as battlefield situation information), lossless compression methods (such as Huffman coding and LZW coding) can be used to ensure data integrity and accuracy. For data with lower real-time requirements (such as background environmental information), lossy compression methods (such as JPEG and MP3) can be used to further reduce data transmission volume. Furthermore, the system can incorporate predictive coding and differential coding techniques to further improve compression efficiency.

[0046] In addition to compressing data, the system also needs to encode it. The purpose of encoding is to convert the raw data into a format that is easier to transmit and process. The system can use standard encoding protocols (such as TCP / IP and UDP) or custom encoding methods, depending on actual needs. During the encoding process, the system must ensure data integrity and readability to avoid data loss or decoding errors.

[0047] S5. Push the compressed and encoded entity data of each entity in the entity list according to the corresponding push priority and push frequency.

[0048] Finally, the system pushes the compressed and encoded entity data to the user end in an orderly manner according to the push priority and push frequency assigned to each entity. This is the final step in achieving on-demand push of entity data.

[0049] During the push process, the system can use a variety of transmission protocols and communication technologies, such as TCP / IP, UDP, and WebSocket, depending on actual needs. The TCP / IP protocol is suitable for scenarios requiring reliable transmission and large data volumes; the UDP protocol is suitable for scenarios with high real-time requirements but a certain amount of data loss can be tolerated; and the WebSocket protocol is suitable for scenarios requiring two-way communication and real-time interaction.

[0050] The system can also introduce mechanisms such as data caching, retransmission, and flow control to further improve the reliability and efficiency of data transmission. For example, when network latency is high or data loss is high, the system can cache data locally or on intermediate nodes, waiting for network conditions to improve before transmitting again. Alternatively, it can employ retransmission mechanisms to resend lost data. Alternatively, it can implement flow control mechanisms to limit the data transmission rate to avoid network congestion and data loss.

[0051] Specifically, the above method can be implemented using MySQL database language and web page PHP code programming.

[0052] Furthermore, the compression and encoding of entity data adopts a dynamic data compression method.

[0053] Specifically, the dynamic data compression method includes: when it is monitored that the network bandwidth is lower than a preset threshold, increasing the compression rate of the physical data to reduce the data transmission volume.

[0054] This embodiment employs a dynamic data compression method, dynamically adjusting the compression ratio based on real-time monitoring of network bandwidth. When network bandwidth is sufficient, a lower compression ratio is used to maintain data quality; when network bandwidth is limited, the compression ratio is increased to reduce data transmission volume and ensure smooth data transmission. Dynamic data compression can be implemented by adjusting compression algorithm parameters and selecting an appropriate compression level.

[0055] The specific implementation of dynamic data compression methods can be improved and optimized based on existing compression algorithms. For example, the system can use Huffman coding, LZ77 / LZ78 algorithms, or more advanced compression algorithms such as JPEG and MPEG, selecting the appropriate compression method based on the type and characteristics of the entity data. Furthermore, the system can incorporate predictive coding, differential coding, and other technologies to further improve compression efficiency.

[0056] Furthermore, during the entity data push process, the push strategy is adaptively adjusted based on the network topology and network bandwidth status.

[0057] Specifically, adaptively adjusting the push strategy based on the network topology and network bandwidth status includes: when it is monitored that the network topology is a preset network topology and / or the network bandwidth is lower than a preset threshold, reducing the push frequency of entity data, or choosing to push only part of the entity data.

[0058] In this embodiment, during the entity data push process, the system needs to continuously monitor the network topology and network bandwidth status and adaptively adjust the push strategy accordingly. This is to cope with the dynamic changes in the network environment and ensure the stability and efficiency of data transmission.

[0059] Specifically, the system can monitor changes in network topology in real time, such as the addition of nodes, link interruptions, and increased network latency. When these changes are detected, the system should automatically adjust its push strategy based on pre-set rules or algorithms. For example, when the network topology becomes complex or unstable, the system can reduce the push frequency of entity data to reduce network burden and transmission delays; or it can choose to push only key entity data to ensure timely delivery of the most important information.

[0060] At the same time, the system also needs to monitor network bandwidth status in real time. When the network bandwidth falls below a preset threshold, it indicates that the network transmission capacity is limited. In this case, the system should increase the data compression rate to reduce the data transmission volume; reduce the push frequency to reduce the number of data transmissions; or prioritize the push of high-priority entity data to ensure the transmission of critical information.

[0061] Adaptive push strategy adjustments can be implemented based on existing network monitoring technologies and algorithms. The system can incorporate network traffic monitoring tools and bandwidth measurement algorithms to monitor network status and capture relevant data in real time. Based on this data and analysis, the system can then automatically adjust push strategies to achieve optimal data delivery.

[0062] Furthermore, when assigning a push priority and a push frequency to each entity in the entity list, a high push frequency is assigned to a high-priority entity, and a low push frequency is assigned to a low-priority entity.

[0063] In this embodiment, for each entity in the entity list, the system needs to assign a corresponding push priority and push frequency to it, which is one of the key steps to achieve on-demand push of entity data.

[0064] Push priority and frequency should be assigned based on the entity's importance, complexity, and relevance to the user. Specifically, the system can use a multi-metric comprehensive evaluation method to calculate a comprehensive score for each entity. This score can reflect the entity's importance in the simulation system (such as whether it is a key node or whether it participates in important events), its complexity (such as model sophistication and computing resource consumption), and its relevance to the user (such as distance, interaction history, and user preferences).

[0065] Based on the comprehensive score, the system can classify entities into different priority categories, such as high priority, medium priority, and low priority. For high-priority entities, the system should assign a higher push frequency to ensure that users can obtain the latest status and information of these entities in a timely manner; for low-priority entities, a lower push frequency can be used to reduce unnecessary network burden and data processing costs.

[0066] It is not difficult to see from the above embodiments that the present invention adopts an on-demand push mechanism to avoid the transmission of redundant data, reduce the pressure on network bandwidth, and improve data transmission efficiency; at the same time, by dynamically adjusting the push frequency and compression rate, it reduces unnecessary data calculation and storage burdens and improves the utilization rate of computing resources; and adjusts the push content and frequency according to user needs, so that the system can accurately meet the user's simulation needs and improve the real-time response capability of the simulation system; in addition, it can flexibly adjust the push strategy according to different network environments and user needs to adapt to various changing simulation scenarios. In general, it can effectively solve the problems of insufficient bandwidth, high computing pressure, and information redundancy in traditional simulation systems, and optimize the performance and resource utilization of the simulation system. This method is applicable to various large-scale simulation scenarios and has broad application prospects.

[0067] Based on the same inventive concept, the present invention also provides an entity on-demand push device for large-scale LVC simulation, which can be a personal computer, a server, or other devices that implement the aforementioned entity on-demand push method for large-scale LVC simulation.

[0068] See Figure 2 As shown, the entity on-demand push device for large-scale LVC simulation provided by this embodiment includes: The area division module is used to divide the area to be simulated according to the user's location, simulation task type and user's focus area; The demand perception module is used to identify user needs based on user behavior patterns and determine the list of entities that need to be pushed in the simulation area according to user needs; Priority scheduling module, which is used to assign corresponding push priority and push frequency to each entity in the entity list based on the importance, complexity and relevance of the entity to the user; A data compression module is used to compress and encode the entity data that needs to be pushed; The entity push module is used to push the compressed and encoded entity data of each entity in the entity list according to the corresponding push priority and push frequency.

[0069] All relevant contents of each step involved in the embodiment of the entity on-demand push method for large-scale LVC simulation can be referred to the functional description of the functional module corresponding to the entity on-demand push device in the embodiment of the present application, and will not be repeated here.

[0070] The division of modules in the embodiments of the present application is illustrative and is merely a logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional modules in the various embodiments of the present invention may be integrated into a single processor, or may exist physically separately, or two or more modules may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or software functional modules.

[0071] In the drawings of the system embodiment provided by the present invention, the connection relationship between modules indicates that there is a communication connection between them, which can be specifically implemented as one or more communication buses or signal lines.

[0072] The present invention also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to cause the at least one processor to perform the above-mentioned entity on-demand push method for large-scale LVC simulation. The electronic device can be any terminal device including a mobile phone, a laptop computer, a desktop computer, a tablet computer, a PDA (Personal Digital Assistant), a POS (Point of Sales), an in-vehicle computer, or the like.

[0073] The present invention also provides a storage medium storing a computer program, which, when executed by a processor, implements the above-mentioned entity on-demand push method for large-scale LVC simulation.

[0074] Through the description of the above embodiments, those skilled in the art can clearly understand that the present invention can be implemented by means of software plus necessary general hardware, and of course can also be implemented by dedicated hardware including application-specific integrated circuits, dedicated CPUs, dedicated memories, dedicated components, etc. In general, all functions performed by computer programs can be easily implemented by corresponding hardware, and the specific hardware structures used to implement the same function can also be diverse, such as analog circuits, digital circuits or dedicated circuits, etc. However, for the present invention, software program implementation is a better implementation method in most cases. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk, etc., including a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) to execute the methods described in each embodiment of the present invention.

[0075] QoS, short for Quality of Service, is a core concept crucial in computer networking and communications. It refers to a set of technologies and mechanisms used to guarantee the performance, reliability, and priority of different types of data transmitted over a network.

[0076] Simply put, the core problem that QoS solves is: how to ensure that critical applications or data flows obtain the necessary transmission quality under limited network resources (such as bandwidth), especially when the network is congested or fluctuating.

[0077] Example 1: Successful push based on QoS feedback and fault-tolerant degradation (in an unstable network environment) A large-scale smart city traffic management platform performs real-time LVC traffic flow simulation, simulating tens of thousands of connected vehicles, traffic lights, pedestrians, and other entities. User A is an "emergency responder" at the traffic control center, their screen focused on a main arterial road in the city's west district (the site of a sudden multi-vehicle rear-end collision). User B is a "regional traffic optimizer," responsible for monitoring regular traffic flows in the north district. User A accesses the network via a dedicated mobile emergency network (network quality is easily affected by weather and location), while User B accesses the network via a stable metropolitan area network.

[0078] Execution process: 1. Area division: The system determines the core area (accident hotspot in the west district) that needs to be simulated based on user A's role (accident response), current task (handling accidents in the west district), and manually set areas of interest (1 km around the accident site). 2. Demand identification: Based on user A's recent frequent calls for accident site monitoring, operating traffic lights to red, and inquiring about the location of nearby ambulances, the system identifies the core vehicles involved in the accident, rescue vehicles, and traffic lights at key congestion nodes that he is currently paying close attention to. 3. Priority allocation: Vehicles involved in the core of the accident (especially those that may involve dangerous goods transport vehicles): highest priority (highest safety risk, highest correlation), assigned the highest push frequency (such as 10Hz status updates: location, speed, damage status).

[0079] Among them, ambulances and fire trucks rushing to the scene have high priority and are assigned a high push frequency (5Hz). Traffic lights at key intersections near the accident site have high priority (directly impacting traffic flow) and are assigned a high push frequency (2Hz, updated upon any status or change). Ordinary vehicles within 1 km of the accident site have medium priority and are assigned a medium push frequency (1Hz). Vehicles / traffic lights in more distant areas have low priority and are assigned a low push frequency (0.2Hz, or updated only upon significant changes in location).

[0080] 4. Data Compression: Dynamic compression (e.g., differential encoding or lossy position accuracy compression) is applied to all entity status data (location, speed, direction, type, and status) to be pushed. Key new mechanisms take effect (when the network is unstable): QoS Feedback Adaptation: User A's terminal (possibly located in a mobile command vehicle) detects signal fluctuations on the emergency network due to sudden heavy rain, causing packet loss to rise to 12% and average latency to increase to 150ms (exceeding the 100ms threshold required for real-time monitoring in the simulation). The terminal sends this QoS feedback back to the simulation server. The server dynamically adjusts user A's entity stream: Reduce push frequency: Reduce the push frequency of medium-priority entities (ordinary vehicles near the accident site) targeted by user A from 1Hz to 0.5Hz. Increase compression: Apply higher compression to the location data of medium-priority entities (e.g., reduce accuracy from 1 meter to 5 meters). Ensure high priority and adjust retransmissions: Maintain high push frequencies (10Hz, 5Hz, and 2Hz) for vehicles at the center of the accident, rescue vehicles, and key traffic lights. At the same time, redundant transmission or faster retransmission mechanisms are enabled for these high-priority entities. User B's entity flow is not affected.

[0081] Among them, the fault-tolerant degradation mechanism: The server detected that due to User A's persistently poor network conditions, the push failure rate (confirmation timeout) for priority entities (surrounding ordinary vehicles) reached 10% (exceeding the preset threshold of 7%). The system automatically triggered a degradation strategy: suspending the push of full, high-frequency status data for these ordinary vehicles to User A. Instead, a simplified status summary was pushed: containing only core information (such as vehicle ID, road section / block, average speed (range), and basic status (driving / stopped)). The summary data volume was only 10% of the full, high-frequency status. Pushing of the highest / highest priority entities (accident vehicles, rescue vehicles, and key traffic lights) was not affected by this degradation and continued to attempt full pushes with guaranteed retransmissions.

[0082] Results: Despite network fluctuations caused by heavy rain, user A was still able to stably and in real time monitor the dynamics of the core vehicle involved in the accident, the location of rescue vehicles, and the status of key traffic lights, effectively directing on-site disposal and traffic diversion. Although the situation of ordinary vehicles in the surrounding area was downgraded to the average speed and status of the block level, it was sufficient to grasp the overall congestion evolution trend without affecting core decision-making. The significant reduction in the transmission of non-critical data significantly alleviated the pressure on user A's mobile link and avoided the delay or loss of critical information due to network congestion. User B's monitoring of regular traffic flow in the north area was completely unaffected. The simulation platform maintained the availability of key functions and the effectiveness of decision support under adverse network conditions.

[0083] Comparative Example 1: Failure Case with No QoS Feedback and Fault Tolerance Degradation (Same Unstable Network Environment) The smart city traffic simulation, user roles, emergencies, and initial network conditions are the same as those in the previous example (user A experiences 12% packet loss and 150ms delay on their mobile private network during heavy rain).

[0084] Execution process: 1. The steps of area division, demand identification, initial priority allocation, and data compression encoding are exactly the same as those in the embodiment.

[0085] 2. Push: The server pushes compressed, encoded physical data to all users strictly according to the initially assigned priority and frequency. There is no mechanism for receiving or processing user-side QoS feedback. There is no mechanism for monitoring push failure rates or triggering downgrades.

[0086] Problem: User A's mobile network bandwidth, under heavy rain, could not support all the data streams pushed at the initial frequency (especially the 1Hz updates from a large number of medium-priority surrounding vehicles). Data flooding and congestion: The server continuously sent complete data streams to User A (10Hz for the accident vehicle, 5Hz for the rescue vehicle, 2Hz for traffic lights, and 1Hz for surrounding vehicles). User A's link was severely overloaded, with actual packet loss rates soaring to over 25% and latency exceeding 400ms. Critical information was lost: Due to the lack of dynamic adjustment and protection mechanisms, critical status updates from User A's core vehicle (such as the unusual movement of a hazardous materials vehicle) and position updates from rescue vehicles approaching the accident site were lost under high packet loss rates. User A's surveillance footage experienced significant lag, with vehicle locations jumping or disappearing. Rigidity: The server detected a transmission failure and could only perform standard retransmissions. These retransmissions, combined with the high-frequency new data, further exacerbated network congestion, creating a vicious cycle. Without a downgrade strategy, unimportant surrounding vehicle data continued to be pushed and retransmitted at a high frequency.

[0087] Consequences: User A's dispatch instructions were delayed due to a lack of timely critical updates regarding the abnormal status of the hazardous materials vehicle and the fire truck's precise location. Traffic lights at the intersection were not effectively coordinated to provide the optimal green signal for the fire truck, resulting in a delay in the fire truck's arrival at the scene and exacerbating the accident consequences in the virtual simulation (simulating fire spread). User A's decision-making was inefficient and lacked critical information.

[0088] Result: User A's core, high-priority entity information (accident vehicles, rescue vehicles) was lost, leading to misjudgments in emergency response decisions. Severe network congestion could indirectly impact other users and system performance. Valuable network bandwidth was consumed by a large amount of low- and medium-priority entity data and ineffective retransmissions. A lack of a degradation mechanism prevented the maintenance of critical situational awareness during network degradation.

[0089] Key comparisons and effects between Example 1 and Comparative Example 1: 1. QoS feedback adaptation: Example 1: Utilizing QoS information reported by user A (12% packet loss, 150ms delay), the data flow was fine-tuned (reducing non-critical frequency / accuracy while maintaining critical and enhanced transmission), ensuring real-time and reliable transmission of incident core and rescue force information.

[0090] Comparative Example 1: No such mechanism. The server is unaware of User A's actual network difficulties and continues to flood data, causing critical information to be lost and impacting emergency response.

[0091] 2. Fault-tolerant degradation mechanism: Example 1: Detecting a 10% push failure rate for medium-priority entities (>7% threshold), intelligent downgrade was implemented (stopping sending details and instead sending summaries with 10% of the data volume), freeing up bandwidth to ensure core security and maintaining overall situational awareness in the incident area.

[0092] Comparative Example 1: No such mechanism exists. Failures are simply retransmitted indiscriminately, exacerbating the problem. There are no downgrade options. When details cannot be reliably transmitted, failures persist (including loss of critical information) or the system freezes, paralyzing decision-making.

[0093] in conclusion: Under the same complex and unstable network environment (urban emergency mobile network fluctuations due to heavy rain), the QoS feedback adaptation and fault-tolerant degradation mechanism of the present invention is significantly effective in smart city traffic simulation: Guaranteed core emergency information flow: ensuring that the status of key entities such as the accident core and rescue forces are accessible in real time.

[0094] Optimizes limited network resources: Dynamically downgrades non-critical information based on actual reception conditions to avoid congestion.

[0095] Improved system robustness and availability: When the network is severely degraded, basic situational awareness is maintained through summary information, supporting continuous decision-making and preventing the collapse of critical functions.

[0096] Comparative Example 1 clearly demonstrates the serious consequences (loss of critical information, delayed emergency response, and poor decision-making) that can result from network instability when these mechanisms are absent. This demonstrates the universality, necessity, and significant technical effectiveness of the newly added technical features in addressing the pain points of complex and unstable networks in large-scale civilian LVC simulations. All data (packet loss rate, latency, frequency, threshold, and summary data volume ratio) complies with technical specifications for smart cities, connected vehicles, and mobile communications.

[0097] Example 2: Dynamic Threshold and Sliding Window Fault Tolerance (Network Fluctuation Scenario) Smart city rainstorm and flood emergency simulation, users (command center) need to monitor: High Priority Entity: Rescue Helicopter (10Hz push frequency, base threshold = 3%) Medium priority entity: Pump truck (push frequency 5Hz, basic threshold = 5%) Low-priority entity: normal traffic flow (push frequency 1Hz, basic threshold = 8%) Users access through a 4G / 5G hybrid link, and heavy rain causes base station fluctuations Effective process: 1. Dynamic threshold calculation A 40% increase in the variance of historical user network latency (poor stability) was detected, causing all entity thresholds to increase by 25%. Rescue helicopter threshold: increased from 3% to 3.75% (rounded to 4%) Pump truck threshold: increased from 5% to 6.25% (rounded to 6%) Normal traffic flow threshold: increased from 8% to 10% Due to the current critical phase of disaster response, the thresholds for high / medium priority entities are lowered by another 30%: Rescue helicopter: 4% × 0.7 = 2.8% Pump truck: 6% × 0.7 = 4.2% 2. Sliding window monitoring (window = 10 seconds), as shown in Table 1.

[0098] Table 1 shows the sliding window monitoring time Rescue helicopter failure rate Pump truck failure rate action 1-3 seconds 3.1% (>2.8%) 4.0% (<4.2%) The sampling point exceeding the threshold in the window = 30% < 50% (not triggered) 4-7 seconds 3.5% (>2.8%) 5.0% (>4.2%) Exceeding the threshold for 4 consecutive seconds, cumulative sampling points = 70% > 50% (triggering downgrade) 3. Downgrade execution Rescue helicopters (continuously exceeding thresholds): Maintain a 10Hz push frequency (no frequency reduction for critical entities); position accuracy reduced from 0.5 meters to 5 meters (compression rate increased, data volume reduced by 60%). Pump trucks (first time exceeding thresholds): Suspend full status push (such as hydraulic pressure and fuel consumption) and switch to summary information: including only location (10-meter accuracy), operating status (running / stopped), and fault codes (if any). Data volume reduced to 15% of the original. Results: The critical position of the rescue helicopter was continuously updated (with sufficient accuracy for rescue navigation) without data interruption. The core status of the pump truck (location + operating status) was known, and detailed data was suspended to avoid congestion. The failure rate of ordinary traffic flow was 9% < 10%, and no degradation was triggered, saving system processing resources. The network load decreased by 35%, and the user-side latency dropped to below 120ms. Comparative Example 2: Fault Tolerance Failure of Static Threshold and Instantaneous Monitoring (Same Scenario) Scenario: Same as the example, but using a static threshold (fixed at 5%) + instantaneous failure rate monitoring Problem exposure: 1. Static threshold mismatch priority: Rescue helicopter failure rate = 3.1% (actual protection required) < 5%, resulting in no downgrade. Pump truck failure rate = 4.0% < 5%, resulting in no downgrade. Consequences: Key entity data continues to be lost, helicopter position jumps, resulting in virtual collision alarms. 2. Momentary monitoring false trigger: At the eighth second, the failure rate for normal traffic flow suddenly spiked to 12% (due to a sudden increase in background traffic), triggering an immediate system downgrade: all traffic flow data was suspended. Consequence: The road network situation was lost, and commanders were unable to determine congestion on evacuation routes. Two seconds later, the failure rate dropped back to 6%, but the downgrade was not automatically lifted, ultimately resulting in a three-minute interruption in traffic flow data. 3. Key entity missed protection + non-key entity mistakenly killed: as shown in Table 2.

[0099] Table 2 shows the key entity missed protection + non-key entity mistakenly killed. entity Actual needs System Action result rescue helicopter Need to enhance protection No downgrade (3.1% < 5%) Positioning deviation leads to rescue delays Water pump truck Partial downgrade required No downgrade (4.0% < 5%) Increased data congestion Normal traffic flow Tolerable loss Excessive degradation (instantaneous 12%) Road network monitoring paralyzed

[0100] Conclusion: The dynamic threshold calculation of the present invention solves the adaptability problem of priority / network / task scenarios; sliding window monitoring overcomes the misjudgment caused by instantaneous jitter. In the case of network fluctuations during heavy rain: 1. Example 2: A dynamic threshold reduces the rescue helicopter trigger line from 5% to 2.8%, and a sliding window filters short-term fluctuations, achieving precise protection of high-priority entities and saving resources on non-critical entities. 2. Comparative Example 2: The static threshold (5%) causes the helicopter to miss protection, and instantaneous monitoring causes traffic flow to be mistakenly degraded, causing critical mission risks. Technical value: This invention upgrades the fault-tolerant trigger mechanism from "simple and crude" to "intelligent and precise", enabling the degradation strategy to play its maximum effectiveness in complex network environments, and is fully implemented by priority allocation and QoS feedback.

[0101] Example 3: In urban traffic simulation, the command center (user A) monitors the core road sections, and the traffic controller (user B) monitors the secondary road sections.

[0102] Network topology: User A's path hop count = 3 (high complexity), User B's path hop count = 1 (low complexity).

[0103] Bandwidth status: Total bandwidth is 100 Mbps, and burst traffic causes bandwidth utilization to reach 85% (first threshold = 80%).

[0104] Hierarchical decision-making takes effect: State Quantization: Topological complexity score: User A = 0.8 (> the second threshold 0.7), User B = 0.3 (< the fourth threshold 0.5).

[0105] Bandwidth utilization = 85% (> the first threshold of 80%).

[0106] Strategy matching: If the bandwidth utilization is > 80% and the topology complexity of user A is > 0.7, reduce the overall push frequency for user A (for example, from 10 Hz to 5 Hz).

[0107] If the topological complexity of user B is less than 0.5, the original frequency is maintained.

[0108] Bandwidth recovery: When the utilization rate drops back to 70% (< the fifth threshold of 75%), user A's original frequency is restored.

[0109] Results: User A (high topology complexity + high bandwidth load) is precisely downgraded to avoid network congestion. User B (low topology complexity) remains unaffected, ensuring the continuity of secondary tasks. Once bandwidth is restored, the restrictions are automatically lifted without manual intervention.

[0110] According to another embodiment of the present invention, in a smart city traffic simulation application, the command center needs to monitor high-priority emergency vehicles (initial push frequency 20Hz) and low-priority social vehicles (initial frequency 1Hz) simultaneously. When a sudden traffic accident causes users to proactively increase the attention level of social vehicles in the accident area, and their status update delay exceeds 800ms (exceeding the 500ms tolerance threshold), the system triggers a rebalancing mechanism: first, the emergency vehicle frequency is reduced from 20Hz to 15Hz to free up bandwidth, and then a temporary 5Hz high-frequency channel is allocated to social vehicles in the accident area. After the adjustment, the delay of social vehicles is reduced to 150ms (meeting the timeliness requirement), while the emergency vehicles still maintain efficient updates. The entire process requires no human intervention and is completed automatically in milliseconds.

[0111] Traditional static priority schemes have significant flaws: high-priority entities (such as ambulances) monopolize high bandwidth resources (70%) for extended periods. Even low-priority entities with urgent critical needs (such as private vehicles involved in a traffic accident) are still constrained to a fixed low frequency (1Hz), resulting in status update delays of up to 800ms. Another common solution is global frequency reduction—when the network is overloaded, the frequency of all entities is uniformly reduced (e.g., 15Hz for ambulances and 0.5Hz for private vehicles). While this crude strategy alleviates congestion, it sacrifices the quality of high-priority entities and still fails to meet the sudden timeliness needs of low-priority entities (further exacerbating delays for private vehicles).

[0112] In contrast, the proposed rebalancing mechanism achieves refined resource scheduling: by proportionally reducing the frequency of non-emergency, high-priority entities (ambulances are reduced by only 25% rather than a global reduction), the released bandwidth is precisely targeted to improve the services of critical, low-priority entities (the frequency of public vehicles is increased by 400%). This not only resolves the problem of low-priority entity timeouts in emergency scenarios (delay is reduced from 800ms to 150ms), but also avoids excessive detriment to high-priority entities. This dynamic strategy overcomes the bottlenecks of rigid resource allocation and delayed response in traditional solutions, significantly improving adaptability in complex simulation environments.

[0113] Although the embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the description and implementation methods. They can be fully applied to various fields suitable for the present invention. For those familiar with the art, additional modifications can be easily implemented. Therefore, without departing from the general concept defined by the claims and the scope of equivalents, the present invention is not limited to the specific details and illustrations shown and described herein.

Claims

1. A method for entity on-demand push for large-scale LVC simulation, characterized in that: include: Divide the simulation area according to the user's location, simulation task type and user's focus area; Identify user needs based on user behavior patterns and determine the list of entities that need to be pushed in the simulation area based on user needs; Assign corresponding push priority and push frequency to each entity in the entity list based on the entity's importance, complexity, and relevance to the user; Compress and encode the entity data to be pushed; Push the compressed and encoded entity data of each entity in the entity list according to the corresponding push priority and push frequency; Among them, during the push process: Receive QoS feedback information about the quality of entity data reception from the user end, and dynamically adjust the push frequency, compression rate or retransmission strategy of the entity data of the corresponding entity or user as a whole according to the QoS feedback information; Real-time monitoring of push failure or timeout events. When the push failure rate for a specific entity or user exceeds a preset threshold, a downgrade strategy is automatically triggered. The downgrade strategy includes: temporarily increasing the compression rate of the entity data, reducing the push frequency of the entity, or pausing the push of the entity and attempting to push its simplified status summary information.

2. The entity on-demand push method for large-scale LVC simulation according to claim 1, characterized in that: The compression and encoding of entity data adopts dynamic data compression method; The compression and encoding of entity data adopts dynamic data compression method. When the network bandwidth is detected to be lower than the preset threshold, the compression rate of entity data is increased. The preset threshold for push failure rate is a dynamic value, calculated in real time based on at least one of the following factors: The push priority of the entity. The higher the priority, the lower the threshold; User-side historical network stability indicator. The worse the stability, the higher the threshold. The criticality level of the current simulation task. The higher the criticality, the lower the threshold. A sliding time window mechanism is used to monitor the push failure rate. The window length is configurable, and the degradation strategy is triggered only when the number of consecutive sampling points exceeding the threshold in the window exceeds 50%.

3. The entity on-demand push method for large-scale LVC simulation according to claim 1, characterized in that: The dynamic data compression method includes: when it is monitored that the network bandwidth is lower than a preset threshold, increasing the compression rate of the physical data to reduce the data transmission volume.

4. The entity on-demand push method for large-scale LVC simulation according to claim 1, characterized in that: During the entity data push process, the push strategy is adaptively adjusted based on the network topology and network bandwidth status; These include: establishing a quantitative model for network status, converting the network topology into a topology complexity score based on node connectivity, path hop count, and link redundancy, and converting the network bandwidth status into bandwidth utilization: current bandwidth used / total available bandwidth; Based on the topology complexity score and bandwidth utilization, the push policy adjustment plan and its effective range are determined according to the preset hierarchical decision rules, where: When the bandwidth utilization is higher than a first threshold and the topology complexity score is higher than a second threshold, the overall push frequency of the user is reduced; When the bandwidth utilization is higher than the third threshold and the topology complexity score is lower than the fourth threshold, only the push frequency of non-critical path users is reduced; When the bandwidth utilization is lower than the fifth threshold, the original push strategy is restored.

5. The entity on-demand push method for large-scale LVC simulation according to claim 1, characterized in that: Adaptively adjusting the push strategy based on the network topology and network bandwidth status includes: when it is monitored that the network topology is a preset network topology and / or the network bandwidth is lower than a preset threshold, reducing the push frequency of entity data, or choosing to push only part of the entity data.

6. The entity on-demand push method for large-scale LVC simulation according to claim 1, characterized in that: When assigning a push priority and a push frequency to each entity in the entity list, a high push frequency is assigned to a high-priority entity, and a low push frequency is assigned to a low-priority entity.

7. The entity on-demand push method for large-scale LVC simulation according to claim 6, characterized in that: The system dynamically monitors changes in network load and user demand, and triggers a push frequency rebalancing mechanism when any of the following conditions are met: The total bandwidth usage of the high-priority entity group exceeds the preset threshold; Users proactively increase the attention level of specific low-priority entities; The status update delay of a low-priority entity exceeds its maximum tolerable delay; The rebalancing mechanism includes: Proportionally reduce the push frequency for high-priority entity groups; or assigning temporary high-frequency channels to critical low-priority entities; At the same time, it ensures that the update delay of all entities does not exceed the maximum tolerable delay threshold corresponding to their priority level.

8. An entity on-demand push device for large-scale LVC simulation, characterized in that: include: The area division module is used to divide the area to be simulated according to the user's location, simulation task type and user's focus area; The demand perception module is used to identify user needs based on user behavior patterns and determine the list of entities that need to be pushed in the simulation area according to user needs; Priority scheduling module, which is used to assign corresponding push priority and push frequency to each entity in the entity list based on the importance, complexity and relevance of the entity to the user; A data compression module is used to compress and encode the entity data that needs to be pushed; The entity push module is used to push the compressed and encoded entity data of each entity in the entity list according to the corresponding push priority and push frequency.

9. An electronic device, characterized in that: include: At least one processor, and a memory communicatively connected to the at least one processor, wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to cause the at least one processor to perform the method according to any one of claims 1 to 6.

10. A storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images