Monitoring equipment data transmission encryption method and system based on smart city

Abstract

The invention relates to the technical field of smart city communication security, and discloses a smart city-based monitoring equipment data transmission encryption method and system, and the method comprises the steps: obtaining an equipment classification initial set; performing security grouping based on the initial set to obtain a security grouping list; collecting communication requirements according to the list, executing priority scheduling, and generating a packet transmission scheduling scheme; generating an encryption key set based on the scheme; executing dynamic authorization and authority adjustment according to the key set to obtain an authorization result list; performing consistency verification and synchronous updating in combination with the authorization result and the key set to obtain a final state table; executing symmetric encryption according to the state table to generate an encrypted data packet; executing path monitoring and dynamic optimization based on the encrypted data packet to obtain an optimized transmission path; and performing integrity verification and data retransmission according to the path to obtain a final transmission result. The method can solve the problem that the secret key and the authority cannot be synchronously updated under the dynamic equipment change.

Description

Technical Field

[0001] The present invention relates to the field of smart city communication security technology, and in particular to a smart city-based monitoring equipment data transmission encryption method and system. Background Art

[0002] In the context of smart cities, the deployment of distributed devices is rapidly developing, and the demand for data communications has surged. This is especially true in scenarios involving high-frequency data interaction between a large number of edge terminals, such as monitoring devices and sensor nodes. Ensuring the security and integrity of data during transmission has become a critical issue in the field of network information security. Traditional centralized communication models struggle to adapt to complex environments characterized by high device heterogeneity and frequent state changes. Systems often experience slow response times and information leakage when faced with dynamic node changes, ensuring real-time performance, and managing data encryption and decryption. Therefore, developing a secure communication method with real-time monitoring capabilities, dynamic key management mechanisms, and encryption path adaptation strategies has become a research focus in the field of smart city data networks.

[0003] In the existing technology, the data encryption configuration of the smart city monitoring network is managed by static grouping and matching with preset rules. Specifically, the devices are initially grouped according to device type or function, and fixed encryption keys and communication permissions are configured for each group. Then, the communication behavior is verified and authorized through rule matching. Key generation and permission configuration rely on periodic updates or manual adjustments, making it difficult to respond to dynamic changes in real time. In scenarios where devices in the network frequently increase or decrease or their status changes, this mechanism lacks flexibility and cannot adjust the grouping or quickly update the key according to the real-time situation. This can easily lead to encryption configuration lags and inconsistent communication permissions, which can cause communication interruptions, data transmission failures and other problems, limiting the system's security and continuity assurance capabilities in large-scale, highly dynamic environments.

[0004] In summary, the existing technology has the problem that keys and permissions cannot be updated synchronously under dynamic device changes. Summary of the Invention

[0005] The present invention provides a method and system for encrypting data transmission of monitoring equipment based on smart cities to solve the problem that keys and permissions cannot be updated synchronously under dynamic device changes. In the first aspect, in order to solve the above technical problems, the present invention provides a method and system for encrypting data transmission of monitoring equipment based on smart cities, comprising: Get the initial set of device categories; Perform security grouping based on the initial set of device classifications to obtain a security grouping list; According to the security group list, communication demand collection and priority scheduling are performed to obtain a packet transmission scheduling plan; Generating encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set; Perform dynamic authorization and permission adjustment based on the encryption key set to obtain a list of authorization results; Perform consistency check and synchronization update based on the authorization result list and the encryption key set to obtain a final status table; Performing encryption processing according to the final state table to obtain an encrypted data packet; Performing path monitoring and dynamic optimization according to the encrypted data packet to obtain an optimized transmission path; According to the optimized transmission path, integrity check and retransmission are performed to obtain the final transmission result.

[0006] Preferably, security grouping is performed based on the initial set of device classifications to obtain a security grouping list, including: Perform identity feature verification based on the initial set of device classifications to obtain a set of trusted devices; Performing status monitoring and feature extraction based on the trusted device set to obtain a communication status feature vector set; According to the communication state feature vector set, group admission and authority configuration are performed to obtain a safe group list.

[0007] Preferably, communication demand collection and priority scheduling are performed according to the security group list to obtain a packet transmission scheduling scheme, including: Collecting communication load according to the security group list to obtain a communication demand data table; Performing traffic analysis and performance evaluation based on the communication demand data table to obtain a packet communication performance report; Priority determination and scheduling configuration are performed based on the packet communication performance report to obtain a packet transmission scheduling solution.

[0008] Preferably, performing encryption key generation according to the packet transmission scheduling scheme to obtain an encryption key set includes: Get the key update template; Based on the hash algorithm, a hash key is generated for the packet transmission scheduling scheme to obtain an initial encryption key set; Recording device changes based on the initial encryption key set to obtain a device change data set; Key update and synchronization are performed according to the device change data set and the key update template to obtain an encryption key set.

[0009] Preferably, dynamic authorization and permission adjustment are performed based on the encryption key set to obtain an authorization result list, including: Obtain communication request data and key update timestamps of each group device of the encryption key set; Extracting request features from the communication request data based on a hash algorithm to obtain a request feature set; Performing permission determination and instruction generation based on the request feature set to obtain a permission control set; Dynamic authorization and structure generation are performed according to the permission control set and the key update timestamp to obtain an authorization result list.

[0010] Preferably, based on the authorization result list and the encryption key set, state extraction and consistency update are performed to obtain a final state table, including: Based on a hash algorithm, extract state features from the authorization result list and the encryption key set to obtain a state feature set; Perform matching verification and instruction generation according to the state feature set to obtain an update instruction set; According to the update instruction set, synchronization adjustment and state generation are performed to obtain a final state table.

[0011] Preferably, performing encryption processing according to the final state table to obtain an encrypted data packet includes: Performing state extraction and symmetric encryption according to the final state table to obtain an encrypted data packet set; Performing integrity check on the encrypted data packet set to obtain a valid encrypted data packet; Path planning and data transmission are performed according to the valid encrypted data packet to obtain an encrypted data packet.

[0012] Preferably, performing path monitoring and dynamic optimization according to the encrypted data packet to obtain an optimized transmission path includes: Get the alternate path library; Performing path monitoring and performance collection based on the encrypted data packets to obtain a path status report; Performing performance comparison and switching instruction generation based on the path status report to obtain a path switching instruction set; Dynamic optimization is performed according to the path switching instruction set and the backup path library to obtain an optimized transmission path.

[0013] Preferably, performing integrity check and retransmission according to the optimized transmission path to obtain a final transmission result includes: Performing reception status collection according to the optimized transmission path to obtain a first reception report; Performing an integrity check based on the first reception report to obtain a data packet identifier set; According to the data packet identifier set, the data packet is retransmitted and confirmed to obtain the final transmission result.

[0014] In a second aspect, the present invention provides a monitoring equipment data transmission encryption system based on a smart city, comprising: A data acquisition module is used to obtain an initial set of device classifications; A security grouping module, configured to perform security grouping based on the initial set of device classifications and obtain a security grouping list; A transmission scheduling module, configured to collect communication requirements and schedule priorities based on the security group list to obtain a packet transmission scheduling solution; An encryption key module, configured to generate an encryption key according to the packet transmission scheduling scheme to obtain an encryption key set; The authorization result module is used to perform dynamic authorization and permission adjustment based on the encryption key set to obtain the authorization result list; A final state module, configured to perform consistency verification and synchronous update based on the authorization result list and the encryption key set to obtain a final state table; An encryption module, configured to perform encryption processing according to the final state table to obtain an encrypted data packet; An optimization module, configured to perform path monitoring and dynamic optimization based on the encrypted data packets to obtain an optimized transmission path; The transmission result module is used to perform integrity check and retransmission according to the optimized transmission path to obtain the final transmission result.

[0015] In a third aspect, the present invention also provides an electronic device comprising a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein when the processor executes the computer program, the method for encrypting data transmission of monitoring equipment based on a smart city as described above is implemented.

[0016] In a fourth aspect, the present invention also provides a computer-readable storage medium, which includes a stored computer program, wherein when the computer program is running, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned smart city-based monitoring equipment data transmission encryption methods.

[0017] Compared with the prior art, the present invention has the following beneficial effects: (1) By performing identity feature verification and status monitoring operations on the initial set of device classifications, the present invention can effectively screen out trusted devices and extract their communication status features, thereby achieving group access based on actual operating status, improving the pertinence and accuracy of security group configuration, and avoiding the risk of misconfiguration caused by static grouping.

[0018] (2) The present invention extracts the transmission parameters of each group and generates a unique initial encryption key based on a hash algorithm. It then determines whether to trigger a key replacement operation by combining the device change record with a preset update template, thereby achieving dynamic update and synchronous management of the key set. This can effectively cope with scenarios where group devices frequently change, and avoid communication interruptions caused by key expiration or unsynchronized permissions.

[0019] (3) The present invention extracts the group identifier and communication protocol content from the scheduling plan, executes the hash algorithm to generate the encryption key, and updates the key according to the timestamp and type difference when the device addition or removal is detected, ensuring that the key generation process is synchronized with the device status in real time, thereby enhancing the continuity and effectiveness of the encryption configuration.

[0020] (4) The present invention monitors the delay and bandwidth data of the current transmission path. If the delay and bandwidth exceed the preset threshold, a path switching instruction is generated, and a path is selected from the preset backup path library for replacement. This ensures that encrypted data still has good transmission stability and timeliness under complex network conditions, reducing the probability of data blocking and congestion. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 This is a flowchart of a method for encrypting data transmission of monitoring equipment based on a smart city, provided by the first embodiment of the present invention; Figure 2 This is a structural diagram of the data transmission encryption system for monitoring equipment based on smart cities provided by the second embodiment of the present invention. DETAILED DESCRIPTION

[0022] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. All other embodiments obtained by ordinary technicians in this field based on the embodiments of the present invention without making any creative efforts shall fall within the scope of protection of the present invention.

[0023] Reference Figure 1 The first embodiment of the present invention provides a method for encrypting data transmission of monitoring equipment based on a smart city, comprising the following steps: S11, obtaining an initial set of device categories; S12, performing security grouping according to the initial set of device classifications to obtain a security group list; S13, performing communication demand collection and priority scheduling based on the security group list to obtain a packet transmission scheduling plan; S14, generating encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set; S15, performing dynamic authorization and permission adjustment based on the encryption key set to obtain an authorization result list; S16, performing consistency check and synchronization update based on the authorization result list and the encryption key set to obtain a final status table; S17, performing encryption processing according to the final state table to obtain an encrypted data packet; S18, performing path monitoring and dynamic optimization according to the encrypted data packet to obtain an optimized transmission path; S19, performing integrity check and retransmission according to the optimized transmission path to obtain a final transmission result.

[0024] In step S11, an initial set of device categories is obtained.

[0025] It's worth noting that in step S11, the process of obtaining the initial device classification set includes collecting device identification information, determining communication status, establishing a basic data structure, and performing classification operations based on feature information. The goal of this step is to form a set of devices classified by functional attributes, which serves as the basic input for subsequent encryption and scheduling operations, ensuring that the encryption strategy matches the communication structure.

[0026] First, a scanning tool deployed in a distributed network environment performs a comprehensive one-time detection of all node devices in the local area network, extracting each device's MAC address and IP address. This operation uses the ARP scanning principle, sending address requests to all addresses in the network segment in sequence and recording the device's unique hardware address and current network address in the returned message. For example, using the Nmap tool to scan subnet 192.168.10.0 / 24, the MAC address of device A is identified as 00-1C-B3-09-85-15, corresponding to the IP address 192.168.10.15, forming a unique device identification pair.

[0027] Next, based on the acquired IP address list, the SNMP communication protocol is used to send status probe commands to each device and read the sysUpTime field. SNMP communication requests are set with a fixed timeout, such as 5 seconds. If a device returns a valid response within the time limit, it is considered online; if it does not, it is marked as offline. For example, if device A responds in 1.2 seconds, it returns normally and is online; if device B does not respond, it is offline. This process avoids manual judgment errors by setting consistency standards, ensuring the uniformity and accuracy of device communication status information.

[0028] Next, the acquired MAC address, IP address, and communication status are organized into structured data fields and written to the database in a unified table. Using MySQL as an example, the fields created include mac_address, ip_address, and status. The database records are as follows: "00-1C-B3-09-85-15," "192.168.10.15," and "online," ensuring that each device's information is traceable, searchable, and updatable.

[0029] To meet the differentiated scheduling requirements of subsequent tasks, devices must be initially classified based on their type and communication response characteristics. The K-means algorithm is used to automatically classify devices during clustering. Specifically, each device is represented as a two-dimensional feature vector, with the dimensions being the device type code and the communication response delay. The K-means algorithm iteratively calculates the Euclidean distance between devices and cluster centers, assigning similar devices to the same cluster and continuously updating the cluster centers until the intra-cluster error converges. To control the algorithm's convergence conditions and ensure clustering accuracy, the system sets an intra-cluster error threshold of 0.05 seconds². This threshold is based on statistical results of the response fluctuation range of high-performance devices (such as servers) in actual sampling. This effectively prevents mixed classification based on device performance, thereby improving the accuracy and stability of subsequent scheduling and encrypted grouping.

[0030] Finally, the clustering results are output as an initial set of device classifications, which contains the unique identification information of each device, including fields such as MAC address, IP address, device type, and response time.

[0031] In step S12, security grouping is performed based on the initial set of device classifications to obtain a security grouping list, including: Perform identity feature verification based on the initial set of device classifications to obtain a set of trusted devices; Performing status monitoring and feature extraction based on the trusted device set to obtain a communication status feature vector set; According to the communication state feature vector set, group admission and authority configuration are performed to obtain a safe group list.

[0032] It is worth noting that the system compares the MAC address of each device with the locally registered whitelist to determine whether it is a device authorized to access the system. If the device MAC address is not in the whitelist, it will be directly removed. Secondly, the system reads the IP address of each device and matches it with the assigned IP segment in the registration table to confirm the legitimacy of its network affiliation. If the IP address is in an illegal segment range, such as a public IP or an unknown address range, it is marked as an untrusted device. Furthermore, the system also verifies the registration time and device number of the device. For example, if the registration time of a device exceeds the set upper limit from the current system time, such as 365 days, and the information is not updated synchronously, it is regarded as an identity invalid device and is not included in the trusted set. After completing the above comparison, the system will include the devices that have passed all verifications into the trusted device set. The set contains fields such as device number, MAC address, IP address and identity verification status. Each record corresponds to a device with an authenticated identity.

[0033] Status monitoring is initiated for each device. By periodically sending SNMP get requests, communication status fields such as device response time, packet processing rate, and CPU utilization are read. For example, device A has a response time of 0.15 seconds, a packet processing rate of 300 packets per second, and a CPU utilization of 25%. This raw monitoring data is then used as input parameters for feature extraction.

[0034] During feature extraction, parameters such as response time, rate, and occupancy are first normalized and converted to percentages. For example, a response time of 0.15 seconds is normalized to 30 points, a packet rate to 60 points, and a CPU occupancy to 50 points. These three features are then combined into a three-dimensional feature vector representing the device's communication status. Ultimately, the vector set for all trusted devices is stored uniformly and is called the communication status feature vector set. Each record in this set uniquely corresponds to a device and contains three field values, which are used in subsequent group access decisions and permission configuration operations.

[0035] The communication status feature vector set is composed of numerical values for each trusted device along three dimensions: communication response time, packet processing rate, and CPU utilization. For example, a device's vector is 〈30, 60, 50〉, representing the normalized response delay, rate, and resource utilization, respectively. Based on this set, group admission is first performed. This involves comparing each device's vector value against a preset admission range to determine whether it meets the basic requirements for secure communication. For example, devices with a response time below 50, a rate above 40, and a CPU utilization below 70 are placed in the high-priority group. If a device's vector is 〈45, 65, 60〉, it meets the requirements and is marked as admitted.

[0036] Next, permissions are configured, assigning different levels of communication permissions based on the device's group. Devices in high-priority groups receive greater bandwidth and lower latency for core data exchange. Devices in low-priority groups are restricted to communication during non-critical hours to avoid resource conflicts. The permissions table records each device's MAC address, group number, and corresponding permission level. For example, a MAC address of 00:1A:2B:3C:4D:5E, group number 1, and permission level high.

[0037] Finally, the system generates a security grouping list, which includes the grouping results and permission identification of each device, and saves it in a structured form to provide a basis for subsequent scheduling and key management.

[0038] In step S13, communication demand collection and priority scheduling are performed according to the security group list to obtain a packet transmission scheduling solution, including: Collecting communication load according to the security group list to obtain a communication demand data table; Performing traffic analysis and performance evaluation based on the communication demand data table to obtain a packet communication performance report; Priority determination and scheduling configuration are performed based on the packet communication performance report to obtain a packet transmission scheduling solution.

[0039] It's worth noting that, based on the established security group list, the communication load of devices within each group is collected in real time or periodically, and a communication demand data table is output in a standardized structure. First, the device identification information for each group, including the device's MAC address and IP address, is extracted from the security group list. This list clearly defines each device's group affiliation and communication permission scope, thus serving as a starting point for device communication status monitoring.

[0040] During the data collection process, the system uses network traffic monitoring tools (such as NetFlow or sFlow) to monitor the network interfaces of devices within the group, recording parameters such as the total number of packets per unit time, average packet length, bandwidth utilization, and number of connected sessions. The data collection cycle can be set to 5 minutes to balance real-time performance with resource usage. If a device's network interface generates 5,000 packets totaling 300MB within a period, the system will record its average transmission rate as 10 Mbps and bandwidth utilization as 20%.

[0041] After data collection is complete, the system organizes the data into a communication demand table for each group. This table includes fields such as group ID, device IP address, bandwidth utilization, packet frequency, peak traffic, and number of active connections. The values for each field are derived from statistical processing of the aforementioned monitoring data. For example, a record shows: group ID SG01, device IP 192.168.1.100, average bandwidth utilization 18%, average number of packets sent per second 1200, and number of connections 8.

[0042] Based on the communication demand data table collected and generated in the previous phase, the system performs traffic analysis and performance evaluation on the communication status within each security group, quantifying the network load level and communication stability of each group, and ultimately generating a structured group communication performance report. The communication demand data table contains multiple fields, including group ID, device IP address, average bandwidth utilization, packet transmission frequency, peak traffic flow, packet loss rate, number of connection interruptions, and average latency. This data is aggregated by the network detection tool after monitoring the device ports over a set period.

[0043] During traffic analysis, the system first traverses all traffic records for devices within each group and calculates the group's average bandwidth utilization and peak bandwidth. For example, for group SG01, the bandwidth utilization rates of its three devices are 20%, 30%, and 25%, respectively, and one device has a peak bandwidth of 50 Mbps. The system uses a weighted average method to determine the group's average bandwidth. The weights used in the weighted calculation of utilization are determined based on the device's contribution to the total traffic. If the data transmission volumes of the three devices are 200 MB, 400 MB, and 300 MB, respectively, the corresponding weights are 2:4:3. According to the weighted average formula, the group's average bandwidth utilization is (20 × 2 + 30 × 4 + 25 × 3) / (2 + 4 + 3) = 26.67%. The peak bandwidth is simply the maximum value for each device during the observation period. The system then evaluates packet transmission frequency and packet loss rate, counting the total number of successfully transmitted packets and the number of failed responses per unit time to calculate the packet loss ratio. If the packet loss rate exceeds 5% or there are frequent connection interruptions, communication is considered unstable.

[0044] In the event of a connection interruption, the system counts the number of session interruptions and uses the average latency to determine network fluctuations. All data is standardized and scored on a percentage scale. The performance evaluation section converts the results of each indicator into a scoring dimension. For example, a bandwidth utilization exceeding 80% is scored as 90, a latency less than 50 milliseconds is scored as 95, and a packet loss rate below 2% is scored as 92. The system calculates the final performance score within the group based on the weight of each indicator and assigns a grading classification. For example, a score of 90 or above is excellent, 70 to 90 is good, and below 70 is questionable. The resulting packet communication performance report tabulates each group's performance score, a description of communication bottlenecks, any abnormal indicators, and warning indicators. For example, SG01's report lists an average bandwidth utilization of 26.67%, a packet loss rate of 1.2%, and an overall score of 91, giving it an excellent rating and no adjustments are required at this time.

[0045] The system prioritizes and schedules each security group based on its score, bandwidth utilization, packet loss rate, and connection stability, as reported in the packet communication performance report. First, the system ranks each group by score, from high to low. For example, groups with scores above 90 are assigned high priority, those between 70 and 90 are assigned medium priority, and those below 70 are assigned low priority. The system then prioritizes tasks based on their importance, such as assigning high priority to video surveillance, medium priority to environmental awareness, and low priority to periodic data collection.

[0046] During the scheduling configuration process, the system allocates available bandwidth and scheduling cycles based on priority levels. For example, if the total available network bandwidth is 100Mbps, high-priority packets will receive over 40% of the resource, medium-priority packets 30%, and the remainder will be allocated to low-priority packets. Furthermore, the system sets different refresh intervals for scheduling intervals, for example, high-priority packets will be scheduled every 5 seconds, medium-priority packets every 15 seconds, and low-priority packets every 30 seconds. If a packet experiences bursty traffic and currently has insufficient bandwidth, the system will determine whether its priority is higher than other packets in the same area. If so, the system will dynamically adjust the scheduling table to increase its bandwidth share.

[0047] Ultimately, the system generates a packet transmission schedule, recording each packet's scheduled interval, allocated bandwidth limit, preset channel priority, and bandwidth reservation. This schedule serves as the foundational data for subsequent encryption key generation and bandwidth control strategies, ensuring the transmission quality and timeliness of high-priority tasks.

[0048] In step S14, encryption keys are generated according to the packet transmission scheduling scheme to obtain an encryption key set, including: Get the key update template; Based on the hash algorithm, a hash key is generated for the packet transmission scheduling scheme to obtain an initial encryption key set; Recording device changes based on the initial encryption key set to obtain a device change data set; Key update and synchronization are performed according to the device change data set and the key update template to obtain an encryption key set.

[0049] It's worth noting that the system accesses the locally configured key policy template library and calls the key update template corresponding to the current network security level. This template is preset by the system administrator and is in JSON or XML format. The content includes fields such as the key validity period, device change trigger threshold, and the upper limit of encryption recalculation times. For example, for a level 1 security group, the system will load a template named "key_policy_level1.json" with the "key validity period" set to 48 hours and the "device change threshold" set to 2 devices. This indicates that a key recalculation should be performed when two or more devices in a group are changed within 48 hours.

[0050] After receiving the packet transmission schedule, the system processes the identification information of each security group and the scheduling parameters as input to form a unique encryption key. The operation process includes the following three steps: First, the system extracts the unique identifier for each group (e.g., group number SG01) and the current scheduling parameter combination (e.g., bandwidth allocation ratio 70% and priority level 1) from the scheduling plan. These are concatenated into a string, such as "SG01-70-1," which serves as input data. Second, the concatenated string is fed into a hash function for digest calculation. The hash algorithm used is SHA256, which calculates a fixed-length hash value for input of any length. During the calculation process, SHA256 converts the string into binary and performs multiple rounds of logical and bitwise operations, ultimately outputting a 256-bit hash value, such as "3a7c9f...ec12"; Third, the system extracts the first 128 bits of the hash value as the initial encryption key for the group. This generated initial key is then bound to the current group ID, forming a "group ID – initial key" pair. The key entries for all groups are combined to form the initial encryption key set, which is then written to the encryption configuration file for use in subsequent communication encryption calls.

[0051] Taking group SG01 as an example, its initial key is the first 128 bits of "3a7c9f...", which will serve as the core content of symmetric encryption during actual data transmission.

[0052] Based on the initial encryption key set generated in the previous stage, the system performs a real-time comparison of the device composition within each security group to identify changes such as new devices being added or offline, thereby recording and forming a device change data set. The specific operation process is as follows: First, the system reads the "Group ID – Initial Key" entry in the encryption configuration file and establishes a mapping between the current group and the encryption key. Each group ID corresponds to the set of devices bound during the initial encryption. This information is indirectly restored by the system through historical communication scheduling records.

[0053] Next, the system calls the network status monitoring interface to poll the device status of each group, obtaining the latest device online status and identification set. Taking group SG01 as an example, if the original configuration contains devices A, B, and C, and the current polling results are A, B, and D, then device C is considered offline and device D is newly added.

[0054] The system extracts these changes into change record entries using difference calculations. These entries contain fields such as group ID, change type (new or offline), device MAC address, IP address, and change timestamp. For example, the record for device D is: SG01, New, 00:1A:2B:3C:4D:5F, 192.168.1.105, 2025-06-03 14:32:00. The system aggregates all change entries into a device change dataset, which is then used to match the key update template and determine whether to trigger the key update process.

[0055] The system matches each change event one by one based on the device change data set generated in the previous stage and the loaded key update template to determine whether the key update conditions are met, and accordingly completes the key content replacement and version synchronization to obtain the updated encryption key set. The specific operations are as follows: First, the system iterates through each change record in the device change dataset, extracting the group identifier, change type, and device identifier. For example, if a record reads "SG02, New, 00:1A:2B:3C:4D:6E," it indicates a new device has been added to the SG02 group. Based on this information, the system searches the key update template for the corresponding update rule for SG02, such as "If the number of devices in any group changes by more than one, a key update is required."

[0056] Once a match is successful, the system immediately calls the key update interface to recalculate the new encryption key for the group. This update is done by concatenating the original initial key with the current timestamp to form a new input, which is then processed through the SHA256 function to obtain a new hash digest. For example, the original key "3a7c9f..." and the time "2025-06-03 16:00:00" are concatenated to form "3a7c9f...-20250603160000". This is then input into the hash function, and the first 128 bits of the output are truncated as the new key.

[0057] The system then replaces the original key entry with the new key and marks the version number upgrade, such as "v2". Finally, all updated or unchanged group keys are written to the encryption configuration file to form a new encryption key set.

[0058] In step S15, dynamic authorization and permission adjustment are performed based on the encryption key set to obtain an authorization result list, including: Obtain communication request data and key update timestamps of each group device of the encryption key set; Extracting request features from the communication request data based on a hash algorithm to obtain a request feature set; Performing permission determination and instruction generation based on the request feature set to obtain a permission control set; Dynamic authorization and structure generation are performed according to the permission control set and the key update timestamp to obtain an authorization result list.

[0059] It's worth noting that, based on the generated encryption key set, the system sequentially reads the device identifiers contained in each group and performs communication request data collection and key update timestamp extraction for each device. Communication request data refers to the number of valid communication connections initiated by the device per unit time, the total number of requests, and the cumulative amount of data transmitted. This data is obtained by reading NetFlow or sFlow data from firewall or router logs and aggregating the request source IP addresses. The key update timestamp refers to the last time an encryption key was generated for the group to which the device belongs. This time information is stored in the encryption key generation log and automatically recorded with each key update. For example, taking the terminal device in group SG03 as an example, the system reads its MAC address and finds that the device has initiated 180 connection requests in the past five minutes, with a cumulative traffic volume of 350MB. Its last key update was at 2:30 PM on October 1, 2024.

[0060] The system performs a hash feature extraction operation on the collected communication request data to generate a stable and comparable set of request features. The process is as follows: First, the system selects three key parameters from the communication request data as input: request frequency, average data size per request, and request-response ratio. These three parameters form a raw feature string. For example, if a device initiates 120 requests within 5 minutes, with an average transfer size of 2.5MB per request and a response ratio of 95%, this feature string is assembled into the string "120-2.5-95" and used as the hash input.

[0061] The system then calls the SHA256 hash algorithm to perform a digest operation on the input string. SHA256 uses a fixed cryptographic function to map a string of arbitrary length into a 256-bit binary hash code. This process involves bit shifts, logical AND operations, and modular addition, ensuring that the output value uniquely maps to the input. The first 64 bits of the resulting hash code are truncated as the request feature fingerprint. For example, if the hash result is "ab3f...c7e1," the truncation yields "ab3f...d9b2," which is the request feature of the device. The feature fingerprints of all devices are organized into a request feature set and stored in a database, bound to the device identifier.

[0062] The system matches each feature value in the request feature set to the communication request record it originated from, identifying the corresponding device ID and group. The system then performs permission determination based on the device's request frequency and data volume metrics. The specific operation process is as follows: First, the system presets a permission threshold table. For example, the request frequency level is divided into five levels, and the data volume level is divided into four levels. It stipulates that a device is considered to be in a high load state when both the request frequency and data volume levels are higher than level three.

[0063] For devices meeting high-load conditions, the system generates permission control instructions to "limit communication" or "reduce transmission frequency." For devices in a low-load state, it generates instructions to "maintain communication" or "transmit normally." All instructions are indexed by device ID and associated with the current group ID. This structure is unified into a "device ID - permission status - control instruction" format, which collectively constitutes a complete permission control set.

[0064] The system performs dynamic authorization and generates a result structure based on the access control set obtained in the previous phase and the key update timestamp corresponding to each device. The process begins by traversing each record in the access control set using the device ID as the index, while also reading the last update time of the device in the key set. The system compares the current system time with the key update timestamp. If the time interval exceeds a preset threshold (e.g., 60 minutes), it determines that the key may have expired or there is a risk of inconsistent access status.

[0065] For devices that meet the update requirements, the system marks their permission control records as "Requires Authorization Adjustment" and recreates authorization entries in the format of "Device ID - Permission Status - Key Update Time - Authorization Status." The authorization status field indicates whether the authorization is automatically synchronized and whether it overwrites the original permissions. For devices that do not require adjustment, the original records are retained and marked as "Maintain."

[0066] After all records are consolidated, a structured authorization result list is generated. This list can be directly imported into the permission distribution program and used in the next step of communication configuration.

[0067] In step S16, state extraction and consistency update are performed based on the authorization result list and the encryption key set to obtain a final state table, including: Based on a hash algorithm, extract state features from the authorization result list and the encryption key set to obtain a state feature set; Perform matching verification and instruction generation according to the state feature set to obtain an update instruction set; According to the update instruction set, synchronization adjustment and state generation are performed to obtain a final state table.

[0068] It's worth noting that the system takes the authorization result list and encryption key set as input, performs a hash calculation on each record, and extracts its status characteristic information. The operation first performs field concatenation on each authorization entry, concatenating fields such as the device identifier, current permission level, authorization timestamp, and corresponding encryption key value into a single string in a preset order, such as "SG01-AUTH1-20250601-KeY88F3." The system then calls the SHA256 hash algorithm to perform a digest operation on the concatenated string, converting it into a 256-bit hash value. This hash value can be considered a unique characteristic expression of the current state of the authorization record, and can simultaneously reflect the joint characteristics of the permission status and encryption configuration.

[0069] During actual processing, all hash results are stored in a list structure, known as the state feature set. Each item in the state feature set is accompanied by the index number of its original record for subsequent comparison and update. For example, for the SG01 device, its authorization status is "Enabled" and its latest key value is "KeY88F3." The generated state feature value, such as "c9f0...3a71," is compared with previously stored historical state feature values during the consistency check phase to determine whether its status has changed.

[0070] Based on the state feature set extracted in the previous phase, the system compares each feature item with the feature value stored in the historical record to determine whether the device's corresponding authorization status or key configuration has changed. Specifically, the system reads the historical hash value from the current state table in the database and compares it one by one with the corresponding item in the latest state feature set. If the hash value differs, the current device's state has been updated. This comparison uses string equality comparison to ensure uniqueness and accuracy.

[0071] Once a state discrepancy is detected, the system generates a corresponding update instruction based on the type of discrepancy. If the discrepancy stems from a change in permission level, a permission adjustment instruction is generated, such as "Device SG01 permission changed from AUTH1 to AUTH2." If the discrepancy stems from an encryption key update, a key synchronization instruction is generated, such as "Device SG01 activates new key 3a7c9f." All generated instructions are written into an update instruction set. Each instruction structure includes fields such as device identification, instruction type, original state value, and target state value.

[0072] For example, for device SG01, if its status characteristic value changes from "9f3a...1e7c" to "c4b2...9a11", and the comparison result is inconsistent, the system generates an update instruction: "SG01, update key, synchronize to c4b2..."

[0073] Based on the update instruction set generated in the previous stage, the system executes the corresponding operations one by one to achieve real-time updates of the status of each device and writes the updated results to the final status table. The specific process includes two steps: synchronization adjustment and status generation.

[0074] First, the system reads each update instruction and determines its type. If it's a permission adjustment instruction, the system invokes the relevant authorization management program through the device control interface to replace the target device's permission field with the new value. If it's a key synchronization instruction, the system replaces the original encryption key in the device configuration with the newly generated encryption key through the encryption service interface. After each instruction is executed, the system records its execution time, results, and corresponding device number as an intermediate log record.

[0075] Then, during the state generation phase, the system constructs a new state table structure based on the final results of all update operations. This state table contains information such as the device identifier, current permission level, encryption key number, and synchronization status field. For example, if device SG01 originally had permissions of AUTH1 and key number K1, but was updated to AUTH2 and K3, the corresponding row in the final state table would be updated to SG01, AUTH2, K3, and Synchronized. This final state table is stored in a structured format in the database for subsequent operations such as communication encryption, permission verification, and network scheduling.

[0076] In step S17, encryption processing is performed according to the final state table to obtain an encrypted data packet, including: Performing state extraction and symmetric encryption according to the final state table to obtain an encrypted data packet set; Performing integrity check on the encrypted data packet set to obtain a valid encrypted data packet; Path planning and data transmission are performed according to the valid encrypted data packet to obtain an encrypted data packet.

[0077] It is worth noting that the system performs state extraction and symmetric encryption operations based on the device identification, current state value, and authorization key number recorded in the final state table to generate an encrypted data packet set. The specific operation process is as follows: First, the system reads each device's status field from the final status table, one by one. This field contains the device ID, key number, authorization level, and data preparation flag. The system combines these status values as parameters and calls the key management subsystem to load the encryption key corresponding to the key number. Each status record is bound to only one key, ensuring consistency in subsequent encryption operations.

[0078] The system then organizes the device's raw service data to be sent, along with its status parameters, into a standard data structure and inputs it into a symmetric encryption function for encryption. The encryption process utilizes the AES algorithm, using keys retrieved from key management to encrypt the raw data in 128-bit blocks in rounds. During each round, the system performs byte substitution, row shifts, column mixing, and round key addition operations, ultimately outputting a ciphertext block. Each encryption operation corresponds to a specific device and key combination, preventing interference caused by cross-device or repeated encryption.

[0079] For example, the key number in the status record for device ID D01 is K3. After the system extracts D01's data block to be transmitted, it performs AES encryption using key K3, generating the ciphertext "9f3d2a..." This ciphertext data is packaged into an encrypted data packet, with a group identifier and destination address added, ultimately forming an encrypted data packet set.

[0080] The system performs integrity checks on each encrypted data packet generated in the previous phase to identify any data corruption that may have occurred during the encryption or caching process. The specific process includes recalculating the checksum, comparing the results, and filtering the data.

[0081] First, the system extracts the encrypted main content from each data packet and reads the original checksum field included with the packet. This field is a four-byte checksum value calculated using the CRC32 algorithm when the packet was generated, which identifies the state characteristics of the data content at the time of generation.

[0082] Next, the system re-performs a CRC32 calculation on the current contents of the packet. The core CRC32 process involves initializing a 32-bit register, performing a byte-by-byte XOR operation on the data byte sequence, and performing a right shift and table lookup correction using a preset polynomial. For example, for the data content "0x3A 0x7F 0x12," the system uses 0x3A as the starting byte, performs an XOR operation with the initial register value, and then performs a table lookup. The result is then XORed with 0x7F, and this process is repeated recursively until the last byte, 0x12, resulting in a 32-bit checksum value such as "F28D7C1A."

[0083] The system then compares the newly generated checksum bit-by-bit with the original CRC field in the packet. If the two match, the packet's content has not been altered during storage and encryption, and the system marks it as a "valid encrypted packet." If any bit difference is detected, the packet's structure or content is considered corrupted, and the system removes it and logs the anomaly. The system aggregates all packets that pass the checksum into a "valid encrypted packet set."

[0084] The system first extracts the target device ID from the data packet and then retrieves the corresponding connection relationship for the target device from the network topology information table. This connection relationship predefines the communication links between devices, including parameters such as the device pair connected by each path, link identifiers, physical bandwidth, current queue length, and connection latency.

[0085] Path planning follows the principle of "shortest reachable path first." The system generates a topology map internally, using the current sending node as the starting point and the target device as the end point. It then traverses all possible paths in the topology and prioritizes them based on bandwidth, congestion level, and transmission distance, selecting the reachable path with the best overall performance indicators as the forwarding route.

[0086] Sorting indicators can be completed by setting weights. For example, if the bandwidth weight is set to 0.4, the delay weight is set to 0.3, and the congestion weight is set to 0.3, the system will normalize the three indicators and perform a weighted sum calculation to obtain the cost value of each path. The path with the smallest cost value will be selected as the transmission path.

[0087] After a path is selected, the system delivers the packet to the next-hop device according to the order of the nodes along the path. This process is accomplished using network interface calls. For example, a TCP socket communication interface can deliver the packet via the source device port to the device port corresponding to the next-hop address. The send and receive times are recorded for each forward, facilitating subsequent latency tracing and performance analysis.

[0088] Ultimately, the encrypted data packet is transmitted from the source device to the destination device via the selected path over multiple hops. Upon completion, the system marks the data packet as "sent" and generates an encrypted transmission record containing the source device, destination device, path number, timestamp, and a transmission success indicator, facilitating subsequent tracking and anomaly analysis.

[0089] In step S18, path monitoring and dynamic optimization are performed based on the encrypted data packet to obtain an optimized transmission path, including: Get the alternate path library; Performing path monitoring and performance collection based on the encrypted data packets to obtain a path status report; Performing performance comparison and switching instruction generation based on the path status report to obtain a path switching instruction set; Dynamic optimization is performed according to the path switching instruction set and the backup path library to obtain an optimized transmission path.

[0090] It's worth noting that the backup path library refers to a set of feasible transmission paths from source nodes to destination nodes, pre-built during the system's deployment phase. This library serves as a basis for rapid switching in the event of performance degradation or interruption during actual data transmission. The library is constructed as follows: First, the system obtains the connectivity of each node based on the network topology, traverses all connected paths from each source node to the destination node, and records key parameters such as the relay node sequence, number of hops, link bandwidth, historical average latency, and packet loss rate. Second, the system screens path parameters to eliminate paths with unstable performance. For example, the system sets a minimum bandwidth threshold of 20 Mbps, based on the minimum transmission requirements for high-definition video streaming or high-frequency command interaction in real-world applications. If a path's historical average bandwidth falls below this threshold, it is deemed unsustainable and excluded from the backup path library. Paths with historical average latency exceeding 150 milliseconds are also excluded, as they are prone to causing interaction lag or control command delays. Finally, the remaining paths are stored in the database, forming a static backup path library. For example, if S1 is the source node and T1 is the destination device, the system may record path one as S1-N2-N3-T1 and path two as S1-N4-N6-T1. Each path contains fields such as bandwidth, latency, and packet loss rate, providing a data basis for runtime path selection and dynamic switching.

[0091] After the system receives the encrypted data packet, it will automatically extract the target device address information and preset path number, and perform real-time monitoring operations on each network relay node passed through. Specifically, the system deploys a data monitoring program at each relay node, which can record the timestamp when the data packet passes through the node, and measure the actual transmission delay, bandwidth utilization and number of packet losses with the next node. The delay is calculated as follows: the time the node receives the data packet minus the time the previous node sends the data packet to obtain the actual transmission time; the bandwidth utilization is obtained by detecting the ratio of the current node's sending queue to the bandwidth limit. For example, if the current rate is 20Mbps and the maximum bandwidth is 100Mbps, the bandwidth utilization is 20%; the packet loss rate is calculated as the ratio of the number of data packets that are not successfully confirmed to the total number of packets sent per unit time.

[0092] After a data packet completes a path transmission, the system aggregates the latency, bandwidth utilization, and packet loss data recorded by each relay node to generate a path status report. This report, indexed by path number, contains performance metrics for each hop, anomaly markers, and historical comparison data for subsequent path switching and optimization. For example, if the report for path number R3 records a latency of 50 milliseconds from nodes N2 to N5, bandwidth utilization of 85%, and two packet losses within the past two minutes, the system can determine that the path's current performance is experiencing abnormal fluctuations and mark it as "suboptimal," preparing for a subsequent switchover.

[0093] After receiving a path status report, the system analyzes the performance indicators of each relay node in the report item by item and compares them with preset performance thresholds. A path status report contains several key fields, such as the average transmission delay per hop, bandwidth utilization, packet loss rate per unit time, and whether there are short-term interruption records. The system compares these fields against the corresponding thresholds. Taking bandwidth utilization as an example, the system sets a threshold of 80%. If the utilization of any node on a path exceeds this threshold, the path is considered to be congested. The delay threshold is set at 50 milliseconds. If this value is exceeded, it is considered to be at risk of slow transmission. A packet loss rate exceeding 5% is considered an unstable path.

[0094] If any of these indicators exceed the threshold, the system will mark the path as "suboptimal" or "abnormal" and generate a path switching instruction accordingly. This instruction specifies the group number of the path to be switched, the original path identifier, and the preset backup path number. For example, if an encrypted packet numbered SG03 is currently using path R3, and the status report indicates a 70 millisecond delay at node N2, the system will generate a switching instruction based on this determination: "SG03 switch from R3 to R7." All generated path switching instructions will form a path switching instruction set, which will serve as input for subsequent dynamic optimization steps. This ensures that data transmission can quickly switch to a more optimal path in the event of performance anomalies, thereby improving the overall communication stability and real-time responsiveness of the system.

[0095] Upon receiving the path switching instruction set and the backup path library, the system immediately performs dynamic optimization. The path switching instruction set contains the group ID of each path to be replaced, the ID of the currently used path, and the ID of the target replacement path. The backup path library records multiple reachable paths from each source node to the target node in the current network, along with their corresponding path attribute data, including bandwidth utilization, hop count, and historical stability rating.

[0096] The specific optimization process is divided into two steps. The first step is path matching: the system traverses the path switching instruction set, reads each path instruction that needs to be optimized in turn, and extracts the group number and the target replacement path number. The system searches the backup path library for all candidate path sets corresponding to the target path number, and selects the candidate path set that meets the minimum number of hops or the lowest bandwidth utilization. For example, if the path switching instruction is "SG04 switches to R6", the system will search the library for all reachable paths from the source end to the target end corresponding to R6. If path R6 has three candidate routes R6-1, R6-2, and R6-3, the system will calculate their historical average delay and bandwidth occupancy, and select the one with the highest score as the final transmission path.

[0097] The second step is path replacement: the system writes the selected new path into the transmission control table, marks the original path as invalid, and updates the destination route field of the corresponding encrypted data packet in the scheduling queue. For example, if the original path R3 is replaced with R6-2, R6-2 will become the optimized transmission path for SG04 packet in the next communication task.

[0098] In step S19, integrity check and retransmission are performed according to the optimized transmission path to obtain the final transmission result, including: Performing reception status collection according to the optimized transmission path to obtain a first reception report; Performing an integrity check based on the first reception report to obtain a data packet identifier set; According to the data packet identifier set, the data packet is retransmitted and confirmed to obtain the final transmission result.

[0099] It's worth noting that the system uses the optimized transmission path as a basis for real-time data collection of the receiving status of transmission terminal devices to generate the first reception report. The optimized transmission path, the result of dynamic path adjustment in the previous phase, represents a set of paths in the current network with low transmission latency, stable bandwidth, and a manageable number of hops. Based on this path, the system performs data monitoring on the target device node, using the reception status collector to capture data arrival status at the device interface within a specified time window.

[0100] During the data collection process, the system records the reception timestamp and original assigned sequence number for each transmitted data packet, and associates these with the pre-defined path destination to form a structured reception record entry. For example, when encrypted packet number D102 is sent to device T5 via path R1, the system detects that the packet was received at T5 at 10:20:05 on June 1, 2025, and the sequence number is 102. Therefore, the system generates a record entry: "Sequence number 102, timestamp 10:20:05, destination T5."

[0101] All received records are written to the receiving database in real time. The system regularly aggregates and cleans the collected results by device index, ultimately outputting a complete first reception report. This report includes information such as the number of packets received by each device, a list of sequence numbers, corresponding timestamps, and reception delays. This information is used for subsequent integrity verification analysis and retransmission determination, ensuring that each data transmission has clear reception feedback and time references.

[0102] Based on the first reception report, the system verifies the integrity of each data packet, identifying any risks of content corruption, structural anomalies, or loss and retransmission during transmission. The first reception report records fields such as the sequence number, reception timestamp, and target device identifier for each data packet, providing a basic index for subsequent verification.

[0103] The system invokes a data verification tool to perform a CRC32 check on each received data packet. This algorithm performs bit-level processing on the packet contents using a generator polynomial division algorithm. Specifically, the system first initializes the XOR operation by XORing the entire binary content of the packet with a fixed 32-bit generator polynomial (such as 0x04C11DB7). Then, the system sequentially shifts and conditionally XORs each bit in the data stream. In each operation, if the current most significant bit is 1, the current register contents are XORed with the generator polynomial; if it is 0, a left shift is performed, ultimately resulting in a 32-bit cyclic redundancy check value.

[0104] This checksum is a hash of the data content, which the system then compares with the original CRC value pre-generated and encapsulated at the end of the packet before transmission. If the two match, the system determines that the packet has not been altered during transmission. If the checksums differ, the data content is considered to have been tampered with or errored during transmission, and the packet is marked as abnormal. The system extracts and summarizes the numbers and sequence numbers of all packets that fail the checksum to form a "packet identification set."

[0105] Based on the packet identifiers generated in the previous phase, the system identifies packets that failed integrity verification and retransmits and confirms the packets corresponding to these identifiers, ultimately completing the closed-loop data transmission process. The packet identifiers contain information such as the sequence number, destination device address, and original transmission time. This information allows the system to quickly locate the source packet copy to be retransmitted in the original data buffer.

[0106] During the specific operation, the system first accesses the cache through an index, extracts the data packet to be retransmitted, re-encapsulates the message header, appends a new timestamp and sequence marker, and then sends it to the target device node using the previously selected optimized transmission path. After the data is retransmitted, the system simultaneously opens a confirmation listening channel, parses the response from the target device, and listens for the received confirmation response.

[0107] For example, if packet D102 is identified as an anomaly due to a verification failure, the system retrieves the original content of D102 from the cache, re-encrypts it, and sends it to device T5. Upon receiving an "ACK-102" response within the receive window, it confirms that the packet has been received and accepted by the target device. This type of confirmation operation can be configured with a maximum number of attempts and a timeout mechanism, with a maximum retransmission limit of three and a timeout of three seconds. Exceeding the limit or failing to receive an acknowledgment triggers an exception report.

[0108] The system ultimately marks success and failure based on the retransmission status of each identified item. It then generates a structured "Final Transmission Result" record table based on all retransmission feedback. This table contains fields such as packet number, destination node, confirmation status, number of retransmissions, and final status. This provides traceability for assessing the stability of the entire data link and subsequent network maintenance. This step ensures a closed-loop receipt for all critical data, significantly improving the system's data reliability and transmission integrity.

[0109] Reference Figure 2 The second embodiment of the present invention provides a monitoring equipment data transmission encryption system based on a smart city, comprising: A data acquisition module is used to obtain an initial set of device classifications; A security grouping module, configured to perform security grouping based on the initial set of device classifications and obtain a security grouping list; A transmission scheduling module, configured to collect communication requirements and schedule priorities based on the security group list to obtain a packet transmission scheduling solution; An encryption key module, configured to generate an encryption key according to the packet transmission scheduling scheme to obtain an encryption key set; The authorization result module is used to perform dynamic authorization and permission adjustment based on the encryption key set to obtain the authorization result list; A final state module, configured to perform consistency verification and synchronous update based on the authorization result list and the encryption key set to obtain a final state table; An encryption module, configured to perform encryption processing according to the final state table to obtain an encrypted data packet; An optimization module, configured to perform path monitoring and dynamic optimization based on the encrypted data packets to obtain an optimized transmission path; The transmission result module is used to perform integrity check and retransmission according to the optimized transmission path to obtain the final transmission result.

[0110] It should be noted that the data transmission encryption device for monitoring equipment based on smart city provided in an embodiment of the present invention is used to execute all the process steps of the data transmission encryption method for monitoring equipment based on smart city in the above embodiment. The working principles and beneficial effects of the two correspond one to one, so they will not be repeated here.

[0111] An embodiment of the present invention further provides an electronic device. The electronic device includes: a processor, a memory, and a computer program stored in the memory and executable on the processor, such as a monitoring device data transmission encryption program based on a smart city. When the processor executes the computer program, the steps in the above-mentioned embodiments of the monitoring device data transmission encryption method based on a smart city are implemented, such as Figure 1 Alternatively, when the processor executes the computer program, the functions of the modules / units in the above-mentioned device embodiments are realized, such as the transmission result module.

[0112] Exemplarily, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to implement the present invention. The one or more modules / units may be a series of computer program instruction segments capable of implementing specific functions, and the instruction segments are used to describe the execution process of the computer program in the electronic device.

[0113] The electronic device may be a computing device such as a desktop computer, notebook, PDA, or smart tablet. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will appreciate that the aforementioned components are merely examples of electronic devices and do not constitute a limitation of the electronic device. The electronic device may include more or fewer components than those described above, or a combination of certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, and the like.

[0114] The processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. The processor is the control center of the electronic device, connecting various parts of the entire electronic device using various interfaces and lines.

[0115] The memory can be used to store the computer programs and / or modules. The processor implements various functions of the electronic device by running or executing the computer programs and / or modules stored in the memory and accessing data stored in the memory. The memory may primarily include a program storage area and a data storage area. The program storage area may store an operating system and at least one application required for a function (such as a sound playback function or an image playback function); the data storage area may store data generated based on the use of the mobile phone (such as audio data, a phone book, etc.). Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as a hard disk, internal memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0116] If the module / unit integrated into the electronic device is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the present invention can implement all or part of the process steps in the above-mentioned method embodiments by using a computer program to instruct the relevant hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium can be appropriately increased or decreased based on the requirements of legislation and patent practice in a jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0117] It should be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided by the present invention, the connection relationship between the modules indicates that there is a communication connection between them, which may be specifically implemented as one or more communication buses or signal lines. A person of ordinary skill in the art can understand and implement the present invention without inventive effort.

[0118] The specific embodiments described above further illustrate the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. In particular, it should be noted that any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included within the scope of protection of the present invention for those skilled in the art.

Claims

1. A data transmission encryption method for monitoring equipment based on smart city, characterized in that: include: Get the initial set of device categories; Perform security grouping based on the initial set of device classifications to obtain a security grouping list; According to the security group list, communication demand collection and priority scheduling are performed to obtain a packet transmission scheduling plan; Generating encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set; Perform dynamic authorization and permission adjustment based on the encryption key set to obtain an authorization result list; Perform consistency check and synchronization update based on the authorization result list and the encryption key set to obtain a final status table; Performing encryption processing according to the final state table to obtain an encrypted data packet; Performing path monitoring and dynamic optimization according to the encrypted data packet to obtain an optimized transmission path; According to the optimized transmission path, integrity check and retransmission are performed to obtain the final transmission result.

2. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1 is characterized in that: The security grouping is performed based on the initial set of device classifications to obtain a security group list, including: Perform identity feature verification based on the initial set of device classifications to obtain a set of trusted devices; Performing status monitoring and feature extraction based on the trusted device set to obtain a communication status feature vector set; According to the communication state feature vector set, group admission and authority configuration are performed to obtain a safe group list.

3. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1 is characterized in that: The communication demand collection and priority scheduling are performed according to the security group list to obtain a packet transmission scheduling scheme, including: Collecting communication load according to the security group list to obtain a communication demand data table; Performing traffic analysis and performance evaluation based on the communication demand data table to obtain a packet communication performance report; Priority determination and scheduling configuration are performed based on the packet communication performance report to obtain a packet transmission scheduling solution.

4. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1 is characterized in that: Generating encryption keys according to the packet transmission scheduling scheme to obtain an encryption key set includes: Get the key update template; Based on the hash algorithm, a hash key is generated for the packet transmission scheduling scheme to obtain an initial encryption key set; Recording device changes based on the initial encryption key set to obtain a device change data set; Key update and synchronization are performed according to the device change data set and the key update template to obtain an encryption key set.

5. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1 is characterized in that: The method of performing dynamic authorization and permission adjustment based on the encryption key set to obtain an authorization result list includes: Obtain communication request data and key update timestamps of each group device of the encryption key set; Extracting request features from the communication request data based on a hash algorithm to obtain a request feature set; Performing permission determination and instruction generation based on the request feature set to obtain a permission control set; Dynamic authorization and structure generation are performed according to the permission control set and the key update timestamp to obtain an authorization result list.

6. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1, characterized in that: The state extraction and consistency update are performed according to the authorization result list and the encryption key set to obtain a final state table, including: Based on a hash algorithm, extract state features from the authorization result list and the encryption key set to obtain a state feature set; Perform matching verification and instruction generation according to the state feature set to obtain an update instruction set; According to the update instruction set, synchronization adjustment and state generation are performed to obtain a final state table.

7. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1 is characterized in that: The step of performing encryption processing according to the final state table to obtain an encrypted data packet includes: Performing state extraction and symmetric encryption according to the final state table to obtain an encrypted data packet set; Performing integrity check on the encrypted data packet set to obtain a valid encrypted data packet; Path planning and data transmission are performed according to the valid encrypted data packet to obtain an encrypted data packet.

8. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1 is characterized in that: The step of performing path monitoring and dynamic optimization according to the encrypted data packet to obtain an optimized transmission path includes: Get the alternate path library; Performing path monitoring and performance collection based on the encrypted data packets to obtain a path status report; Performing performance comparison and switching instruction generation based on the path status report to obtain a path switching instruction set; Dynamic optimization is performed according to the path switching instruction set and the backup path library to obtain an optimized transmission path.

9. The method for encrypting data transmission of monitoring equipment based on smart city according to claim 1, characterized in that: The performing integrity check and retransmission according to the optimized transmission path to obtain a final transmission result includes: Performing reception status collection according to the optimized transmission path to obtain a first reception report; Performing an integrity check based on the first reception report to obtain a data packet identifier set; According to the data packet identifier set, the data packet is retransmitted and confirmed to obtain the final transmission result.

10. A data transmission encryption system for monitoring equipment based on smart city, characterized in that: include: A data acquisition module is used to obtain an initial set of device classifications; A security grouping module, configured to perform security grouping based on the initial set of device classifications and obtain a security grouping list; A transmission scheduling module, configured to collect communication requirements and schedule priorities based on the security group list to obtain a packet transmission scheduling solution; An encryption key module, configured to generate an encryption key according to the packet transmission scheduling scheme to obtain an encryption key set; The authorization result module is used to perform dynamic authorization and permission adjustment based on the encryption key set to obtain the authorization result list; A final state module, configured to perform consistency verification and synchronous update based on the authorization result list and the encryption key set to obtain a final state table; An encryption module, configured to perform encryption processing according to the final state table to obtain an encrypted data packet; An optimization module, configured to perform path monitoring and dynamic optimization based on the encrypted data packets to obtain an optimized transmission path; The transmission result module is used to perform integrity check and retransmission according to the optimized transmission path to obtain the final transmission result.

Images