Multi-protocol IoT sensing method and system based on remote management

Abstract

This invention provides a multi-protocol IoT sensing method and system based on remote management. First, a multi-protocol adaptation and association system is established to associate the communication protocol types supported by the remote management platform and each IoT sensing terminal. Then, the multi-protocol sensing datasets are acquired, merged, and processed for protocol interaction analysis to obtain protocol interaction feature information. Next, a pre-trained protocol scheduling AI model is invoked to evaluate the feature information and generate multi-protocol scheduling instructions to adjust protocol communication parameters. Then, the sensing parameters are dynamically optimized according to the multi-protocol scheduling instructions to obtain an optimized configuration set. Finally, the optimized configuration set is fed back to the remote management platform to execute remote sensing control operations. This enables efficient, stable, and intelligent remote management of multi-protocol IoT sensing terminals in ecological environment monitoring.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and more specifically, to a multi-protocol IoT sensing method and system based on remote management. Background Technology

[0002] In the field of ecological and environmental monitoring, with the continuous expansion of the monitoring scope and the increasing complexity of monitoring needs, a large number of IoT sensing terminals need to be deployed to collect various environmental data, such as air quality, water quality, and soil moisture. These sensing terminals are distributed in different geographical areas, covering various environments such as cities, rural areas, mountains, and water bodies, and support a wide variety of communication protocols. For example, some older monitoring equipment may use traditional wired communication protocols, such as RS-232 and RS-485, while newer intelligent sensing terminals use more wireless communication protocols. For instance, ZigBee is suitable for short-range, low-power monitoring scenarios, LoRa is suitable for long-range, low-speed wide-area monitoring, and 5G can meet the needs of high-speed, high-capacity data transmission.

[0003] Existing remote management methods for ecological and environmental monitoring suffer from numerous problems when dealing with multi-protocol IoT sensing terminals. On the one hand, the data transmission formats of different protocols vary significantly, making it difficult for remote management platforms to directly and uniformly parse and process sensing data from multiple protocols. This results in low data integration efficiency, hindering the timely and accurate acquisition of comprehensive environmental information and impacting accurate assessments and decision-making regarding the ecological and environmental situation. On the other hand, the ecological and environmental monitoring environment is complex and variable, with frequent occurrences of unstable network signals and equipment failures. Existing methods cannot dynamically adjust the protocol communication parameters of sensing terminals according to actual conditions, significantly compromising communication stability and reliability. This often leads to data loss and transmission delays, severely affecting the continuity and accuracy of ecological and environmental monitoring and failing to meet the urgent needs of modern ecological and environmental monitoring for efficient, stable, and intelligent remote management. Summary of the Invention

[0004] In view of the aforementioned problems, and in conjunction with the first aspect of the present invention, embodiments of the present invention provide a multi-protocol IoT sensing method based on remote management, the method comprising:

[0005] A multi-protocol adaptation and association system is established, which is used to associate the communication protocol types supported by the remote management platform and each IoT sensing terminal. The communication protocol types include protocol categories corresponding to different data transmission formats.

[0006] Acquire a multi-protocol sensing data set from IoT sensing terminals, and perform protocol interaction analysis processing on the multi-protocol sensing data set based on the multi-protocol adaptation and association system to obtain protocol interaction feature information;

[0007] A pre-trained protocol scheduling AI model is invoked to perform protocol adaptability evaluation on the protocol interaction feature information, and multi-protocol scheduling instructions are generated. These multi-protocol scheduling instructions are used to adjust the protocol communication parameters of each IoT sensing terminal.

[0008] The sensing parameters of the IoT sensing terminal are dynamically optimized according to the multi-protocol scheduling instructions to obtain an optimized set of sensing parameter configurations.

[0009] The optimized set of sensing parameters is fed back to the remote management platform, which then performs remote sensing control operations on the IoT sensing terminal based on the optimized set of sensing parameters.

[0010] In another aspect, embodiments of the present invention also provide a multi-protocol IoT sensing system based on remote management, including a processor and a machine-readable storage medium connected to the processor. The machine-readable storage medium is used to store programs, instructions, or code, and the processor is used to execute the programs, instructions, or code in the machine-readable storage medium to implement the above-described method.

[0011] Based on the above, by establishing a multi-protocol adaptation and association system, the multi-protocol sensing datasets of IoT sensing terminals are acquired and merged for protocol interaction analysis. This allows for in-depth mining of the interaction characteristics between different protocols, which helps to more accurately grasp the performance of different protocols in ecological environment monitoring scenarios. A pre-trained protocol scheduling AI model is invoked to evaluate and process the protocol interaction characteristics. Leveraging the powerful learning and analysis capabilities of artificial intelligence, multi-protocol scheduling instructions are generated, enabling intelligent adjustment of protocol communication parameters. This effectively improves the adaptability and stability of communication, ensuring stable data transmission even in complex ecological environment monitoring environments and reducing data loss and transmission delays. The sensing parameters of IoT sensing terminals are dynamically optimized according to the multi-protocol scheduling instructions, allowing the terminals to adjust their parameters in real time based on the actual network environment and monitoring task requirements. The optimized sensing parameter configuration set is then fed back to the remote management platform for remote sensing control operations, effectively improving the efficiency and stability of remote management of multi-protocol IoT sensing terminals. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the execution flow of the multi-protocol IoT sensing method based on remote management provided in an embodiment of the present invention.

[0013] Figure 2 This is a schematic diagram of exemplary hardware and software components of a multi-protocol IoT sensing system based on remote management, provided in an embodiment of the present invention. Detailed Implementation

[0014] The present invention will now be described in detail with reference to the accompanying drawings. Figure 1 This is a flowchart illustrating a multi-protocol IoT sensing method based on remote management, provided in one embodiment of the present invention. The following is a detailed description of this multi-protocol IoT sensing method based on remote management.

[0015] Step S110: Establish a multi-protocol adaptation association system. The multi-protocol adaptation association system is used to associate the communication protocol types supported by the remote management platform and each IoT sensing terminal. The communication protocol types include protocol categories corresponding to different data transmission formats.

[0016] This embodiment uses a forest ecological environment monitoring system as an application scenario. This system aims to comprehensively monitor the climate, soil, vegetation, and wildlife activity in forest areas. A remote management platform is located at the regional ecological monitoring center, responsible for integrating data from IoT sensing terminals at different monitoring points. These terminals include temperature and humidity sensors distributed in the canopy, soil moisture sensors in the deeper soil layers, growth monitoring terminals on tree trunks, and positioning terminals for tracking wildlife. Different terminals use different communication protocols due to their installation environment and functional requirements. For example, temperature and humidity sensors use the low-power LoRa protocol, soil moisture sensors use the ZigBee protocol, growth monitoring terminals use the NB-IoT protocol, and positioning terminals support the HTTP protocol. Establishing a multi-protocol adaptation and association system enables seamless communication between the remote management platform and various terminals, ensuring efficient transmission and centralized management of monitoring data.

[0017] Step S111: Collect the protocol compatibility list supported by the remote management platform. The protocol compatibility list includes communication protocol identifiers that the remote management platform can recognize and the corresponding protocol parsing rules.

[0018] The remote management platform's protocol management module stores a pre-defined protocol compatibility list, which is exported through the platform's configuration file. Each record in the list corresponds to a communication protocol identifier and its corresponding parsing rules. For the LoRa protocol, the identifier is a specific string, and the parsing rules cover the physical layer's spreading factor range, the data link layer's frame structure (including preamble, synchronization word, frame length field, payload area, and checksum field), and the parsing order and method for each part. For the ZigBee protocol, the identifier is another specific string, and the parsing rules include the network layer's address format, the application layer's frame control field definition, and the data encryption / decryption process and key management method. For the NB-IoT protocol, the parsing rules involve the physical layer's frequency band allocation, the MAC layer's access mechanism, and data transmission time slot allocation. For the HTTP protocol, the parsing rules include the identification of request methods (such as GET and POST), the extraction method of header fields, and the format conversion of the message body (such as the conversion between JSON and strings). The above parsing rules are described in detail in text form, clarifying the specific operation steps and judgment conditions when parsing data from different protocols.

[0019] Step S112: Collect terminal protocol support information reported by each IoT sensing terminal. The terminal protocol support information includes the communication protocol types that the IoT sensing terminal can run and the corresponding transmission capability descriptions for each communication protocol type.

[0020] After installation and startup, IoT sensing terminals in the forest can automatically send terminal protocol support information to the remote management platform. The information reported by the temperature and humidity sensor explicitly states LoRa as the protocol type, and the transmission capability description includes the terminal's maximum data transmission unit size, supported transmission rate range, signal coverage radius, and power consumption level at different transmission rates under the LoRa protocol. The soil moisture sensor reports the ZigBee protocol type, and the transmission capability description covers the network node capacity, data retransmission mechanism (such as the maximum number of retransmissions and retransmission interval), and sleep / wake-up cycle settings under this protocol. The growth monitoring terminal reports the NB-IoT protocol type, and the transmission capability description includes the maximum number of connections supported by this protocol, the data transmission reliability level (such as the packet loss rate range), and the transmission strategy in weak signal environments. The positioning terminal reports the HTTP protocol type, and the transmission capability description includes the maximum number of concurrent requests, data transmission timeout settings, and supported data compression formats. This information is sent through the terminal's built-in communication module, forwarded to the remote management platform via the gateway, and stored in the corresponding table in the terminal information database.

[0021] Step S113: Perform protocol association mapping processing on the protocol compatibility list and the terminal protocol support information to determine the set of communication protocol types that can be interoperated between the remote management platform and each IoT sensing terminal.

[0022] The protocol mapping module of the remote management platform can compare the protocol compatibility list and terminal protocol support information. Specifically, for each protocol type reported by an IoT sensing terminal, it checks whether it exists in the protocol compatibility list of the remote management platform. If the LoRa protocol reported by the temperature and humidity sensor has a corresponding identifier in the protocol compatibility list, the LoRa protocol is included in the set of interoperable communication protocol types between the terminal and the platform; if the ZigBee protocol reported by the soil moisture sensor exists in the protocol compatibility list, the ZigBee protocol is included in its interoperability set; similarly, if the NB-IoT protocol of the growth monitoring terminal and the HTTP protocol of the positioning terminal both have corresponding entries in the protocol compatibility list, they are included in their respective interoperability sets. For some terminals that support multiple protocols, such as some growth monitoring terminals that support both NB-IoT and LoRa protocols, each protocol is compared separately, and all protocols existing in the protocol compatibility list are included in the interoperability set of that terminal. The final set of interoperable communication protocol types is stored according to terminal categories, such as "Temperature and humidity sensor - interoperable protocol: LoRa protocol" and "Soil moisture sensor - interoperable protocol: ZigBee protocol".

[0023] Step S114: For each communication protocol type in the set of interoperable communication protocol types, extract the data transmission format features of that communication protocol type. The data transmission format features include data frame structure, field definitions, and verification methods.

[0024] Taking the LoRa protocol in the interoperable set as an example, the process of extracting its data transmission format characteristics is as follows. Regarding the data frame structure, it is clear that the LoRa protocol data frame consists of a preamble, a synchronization word, a frame length field, a frame control field, a payload field, and a check field. The preamble is used to wake up the receiver and achieve synchronization; the synchronization word is used to confirm the start of the frame; the frame length field indicates the number of bytes in the payload field; the frame control field contains information such as transmission direction and encryption status; the payload field stores the actual monitoring data; and the check field is used for data integrity checks. Regarding field definitions, the meaning of each bit in the frame control field is explained in detail, such as which bits indicate the transmission direction (terminal to platform or platform to terminal), and which bits indicate whether the data has been encrypted. The storage location and data type of each monitoring parameter in the payload field are also clarified, such as the starting offset of temperature and humidity data in the payload field; temperature data is a 16-bit signed integer, and humidity data is an 8-bit unsigned integer. Regarding the check method, the LoRa protocol uses cyclic redundancy check (CRC). The scope of the check (from the frame length field to the payload field) and the specific implementation method of the check algorithm (such as the selection of the generator polynomial) are clearly defined.

[0025] For the ZigBee protocol, the extraction of data transmission format characteristics includes: the data frame structure is divided into physical layer frames, MAC layer frames, and application layer frames. The physical layer frame contains a synchronization header and physical layer data units; the MAC layer frame contains frame control, sequence number, destination address, source address, and MAC payload; and the application layer frame contains command frame identifier and command data. In terms of field definitions, the specific meanings of the network layer control bits and application layer control bits in the frame control field, the length and format of the address field (such as a 16-bit short address or a 64-bit extended address), and the CRC checksum method, specifying the length and calculation range of the checksum field.

[0026] The data transmission format characteristics of other protocols, such as NB-IoT and HTTP, are extracted in a similar manner to ensure that the frame structure, field meanings, and verification methods of each protocol are clearly defined.

[0027] Step S115: Based on the set of interoperable communication protocol types and the corresponding data transmission format features, construct a multi-protocol adaptation association system. Each association entry in the multi-protocol adaptation association system includes a remote management platform protocol identifier, an IoT sensing terminal identifier, an interoperable communication protocol type, and the corresponding data transmission format features.

[0028] The multi-protocol adaptation and association system is built using a relational database, containing a master table and multiple association tables. Each record in the master table is an association entry, containing a remote management platform protocol identifier (such as a specific string used to identify the LoRa protocol), an IoT sensing terminal identifier (such as a unique device number for a temperature and humidity sensor), an interoperable communication protocol type (such as the LoRa protocol), and a foreign key pointing to the data transmission format characteristics. The data transmission format characteristics are stored in the association tables, with each association table corresponding to a protocol and containing detailed information such as the protocol's data frame structure, field definitions, and verification methods.

[0029] For example, in a related entry, the remote management platform protocol is identified as "LoRa-001," the IoT sensing terminal is identified as "TH-001" (representing the temperature and humidity sensor numbered 001), the interoperable communication protocol type is "LoRa protocol," and the foreign key points to the corresponding record in the related table storing the LoRa protocol data transmission format characteristics. Through this structure, when it is necessary to query the communication protocol and format characteristics between a terminal and the platform, the corresponding related entry can be quickly found in the main table through the terminal identifier, and then the detailed data transmission format characteristics can be obtained through the foreign key. Simultaneously, indexes are established in the system to improve query efficiency based on fields such as terminal identifier and protocol type, ensuring rapid response to query requests even when a large number of terminals are connected.

[0030] Step S120: Obtain the multi-protocol sensing data set of the IoT sensing terminal, and perform protocol interaction analysis processing on the multi-protocol sensing data set based on the multi-protocol adaptation association system to obtain protocol interaction feature information.

[0031] During the operation of the forest ecological environment monitoring system, each IoT sensing terminal sends monitoring data to the remote management platform according to a set cycle. This data collectively constitutes a multi-protocol sensing data set. Temperature and humidity sensors periodically send temperature and humidity data within the forest via the LoRa protocol; soil moisture sensors send soil moisture content and conductivity data via the ZigBee protocol; growth monitoring terminals send tree growth and growth rate data via the NB-IoT protocol; and positioning terminals send location information and activity trajectory data of wild animals via the HTTP protocol. After receiving this data, the remote management platform parses the data using a multi-protocol adaptation and association system, and analyzes the interactions between different terminals and between the terminals and the platform based on various protocols, thereby extracting characteristic information that reflects the operational status of the protocols.

[0032] Step S121: Receive sensing data sent by each IoT sensing terminal through the sensing data receiving module of the remote management platform. The sensing data includes raw sensing data units transmitted by each IoT sensing terminal based on its own supported communication protocol type.

[0033] The remote management platform's sensing data receiving module is deployed on the monitoring center's server. This module is equipped with multiple different types of communication interfaces to receive data from terminals using different protocols. Specifically, the LoRa gateway interface receives raw sensing data units sent by temperature and humidity sensors via the LoRa protocol. These data units are spread-spectrum modulated binary data streams containing information such as sensor identification, acquisition time, temperature value, and humidity value. The ZigBee coordinator interface receives raw data units sent by soil moisture sensors. These data units follow the ZigBee protocol's frame structure and contain node addresses and soil parameter data. The NB-IoT base station interface receives raw data units sent by growth monitoring terminals. These data units are encapsulated in NB-IoT protocol data packets and contain terminal number and growth data. The Ethernet interface receives raw data units sent by positioning terminals via the HTTP protocol. These data units are HTTP request messages containing device identification, location coordinates, and timestamps.

[0034] After receiving these raw sensing data units, the receiving module can add a receiving timestamp and receiving interface identifier to each data unit, perform preliminary classification according to terminal type, and then store them in the raw data buffer. The buffer adopts a circular overwrite mechanism; when storage space is insufficient, it automatically overwrites the oldest received data unit to ensure continuous reception of new data.

[0035] Step S122: Perform protocol identifier extraction processing on the raw sensing data units to determine the communication protocol type identifier corresponding to each raw sensing data unit.

[0036] Protocol identifier extraction for raw sensing data units is achieved by analyzing the characteristic fields of the data units. For raw data units received from the LoRa gateway interface, their preamble and synchronization word features are extracted and compared with the frame structure features of the LoRa protocol in the multi-protocol adaptation association system. If a match is found, the communication protocol type identifier corresponding to the data unit is determined to be a specific identifier string of the LoRa protocol. For data units received from the ZigBee coordinator interface, the protocol identifier bit in its frame control field is parsed, and the value of this bit determines that it is a ZigBee protocol, and the corresponding protocol type identifier is marked. For data units received from the NB-IoT base station interface, the synchronization signal and reference signal features of its physical layer are analyzed. After matching the features of the NB-IoT protocol, the corresponding protocol type identifier is marked. For HTTP request messages received from the Ethernet interface, the HTTP protocol is determined by identifying the request method field such as "GET" or "POST" at the beginning of the message, and the corresponding protocol type identifier is marked.

[0037] The extracted protocol type identifier is associated with the original sensing data unit through a unique identifier and stored in the data identifier table so that the subsequent processing can quickly query the protocol type corresponding to each data unit.

[0038] Step S123: Query the multi-protocol adaptation association system to obtain the protocol parsing rules and data transmission format characteristics corresponding to the communication protocol type identifier.

[0039] Based on the communication protocol type identifier determined in step S122, a search is performed through the query interface of the multi-protocol adaptation association system. For example, when the protocol type identifier is a specific string of the LoRa protocol, the query interface will find the corresponding related entry in the multi-protocol adaptation association system, and then obtain the parsing rules and data transmission format characteristics of the protocol. The parsing rules include the parsing order of each part of the LoRa protocol data frame, the field extraction method, etc.; the data transmission format characteristics include the length and meaning of each field in the frame structure, as well as the verification method, etc.

[0040] For the ZigBee protocol type identifier, the parsing rules obtained after querying include the network layer address parsing method, application layer data extraction steps, etc., and the data transmission format characteristics include the detailed definition of the frame control field and the format of the address field. Similarly, for NB-IoT and HTTP protocols, their respective parsing rules and data transmission format characteristics can also be obtained through the corresponding protocol type identifier. The information obtained above is temporarily stored in the parsing rule buffer.

[0041] Step S124: Based on the protocol parsing rules and data transmission format characteristics, the original sensing data unit is parsed and processed to extract the sensing content and transmission status parameters in the original sensing data unit.

[0042] Taking the raw sensing data unit of the LoRa protocol as an example, the parsing process follows the obtained protocol parsing rules and data transmission format characteristics. First, the preamble and synchronization word are located based on the frame structure characteristics and removed. Next, the frame length field is extracted to determine the number of bytes in the payload field. Then, the frame control field is parsed to obtain information such as transmission direction and encryption status. Following the definition of the payload field, sensing content such as sensor identifier, acquisition time, temperature value, and humidity value are extracted and converted from binary data into corresponding physical quantities (e.g., temperature value converted to degrees Celsius, humidity value converted to percentage). Finally, the data is verified according to the verification method. If the verification passes, the parsed sensing content is retained; if the verification fails, the data unit is marked as invalid, and error information is recorded.

[0043] During the parsing process, transmission status parameters, such as received signal strength, signal-to-noise ratio, and transmission delay, are extracted simultaneously. These parameters reflect the quality of data transmission. For raw data units of the ZigBee protocol, soil moisture sensing content (such as water content and conductivity) and transmission status parameters (such as node signal strength and retransmission count) are parsed out. For data units of the NB-IoT and HTTP protocols, the corresponding sensing content and transmission status parameters are parsed out in a similar manner. The parsed sensing content and transmission status parameters are stored according to terminal identifier and time order to form a structured monitoring dataset.

[0044] Step S125: Perform correlation analysis on the sensing content and corresponding transmission status parameters of different IoT sensing terminals, identify the interaction patterns between IoT sensing terminals based on different communication protocol types, and generate protocol interaction feature information including interaction frequency, interaction duration and interaction data volume.

[0045] The correlation analysis process first groups the parsed sensed content and transmission status parameters according to the communication protocol type. For temperature and humidity sensors using the LoRa protocol, the number of interactions between this type of terminal and the remote management platform within a set time range (e.g., one day) is counted, i.e., the interaction frequency; the time interval from when the terminal sends data to when the platform receives and acknowledges it for each interaction is calculated, i.e., the interaction duration, and the distribution of these durations is statistically analyzed (e.g., average duration, longest duration, shortest duration); the total number of bytes of data transmitted in all interactions within this time period is accumulated, i.e., the interaction data volume, and the volume of uplink data (terminal to platform) and downlink data (platform to terminal) is distinguished.

[0046] For soil moisture sensors using the ZigBee protocol, since they may relay data through other nodes, it is also necessary to analyze the interactions between terminals, such as the number and frequency of data relays from one sensor to another, as well as the duration and amount of data exchanged. Similarly, for terminals using NB-IoT and HTTP protocols, their respective interaction frequency, duration, and data volume should be statistically analyzed, and the trends of these parameters over time should be examined (e.g., increased interaction frequency and data volume in certain time periods).

[0047] The above analysis identifies the interaction patterns of terminals with different protocol types. For example, LoRa protocol terminals have a lower interaction frequency but a stable amount of data per interaction due to power consumption limitations; ZigBee protocol terminals exhibit more inter-terminal interactions due to network structure characteristics. The final generated protocol interaction feature information is a multi-dimensional dataset, with each dimension corresponding to the interaction frequency, interaction duration, and interaction data volume characteristics of a specific protocol type. This information will be used for subsequent protocol compatibility evaluation.

[0048] Step S130: Call the pre-trained protocol scheduling AI model to perform protocol adaptability evaluation processing on the protocol interaction feature information, and generate multi-protocol scheduling instructions, which are used to adjust the protocol communication parameters of each IoT sensing terminal.

[0049] The remote management platform invokes the protocol scheduling AI model deployed on the AI ​​server, inputting the protocol interaction feature information generated in step S125 into the protocol scheduling AI model. This protocol scheduling AI model analyzes this feature information to evaluate the protocols currently used by each terminal from multiple dimensions, including protocol communication efficiency, compatibility, and resource consumption, determining their suitability. Based on the evaluation results, the model generates corresponding multi-protocol scheduling instructions. These instructions can adjust the terminal's transmission rate, change the data frame length, switch communication protocol types, etc., to optimize the communication performance between the terminal and the platform and ensure stable transmission of monitoring data.

[0050] Step S131: Input the protocol interaction feature information into the feature preprocessing layer of the protocol scheduling AI model, perform feature standardization processing on the interaction frequency, interaction duration and interaction data volume in the protocol interaction feature information, and generate a standardized protocol interaction feature vector.

[0051] Protocol interaction feature information first enters the feature preprocessing layer of the protocol scheduling AI model. For the interaction frequency feature, which represents the number of interactions per unit time, the preprocessing layer obtains a standardized value between 0 and 1 by dividing the interaction frequency of each protocol type by the theoretical maximum interaction frequency of that protocol. This standardized value eliminates the influence of differences in maximum interaction frequency between different protocols.

[0052] For the interaction duration feature, the preprocessing layer calculates the difference between each interaction duration and the historical average interaction duration of the protocol, and then divides the difference by the standard deviation of the historical interaction duration of the protocol to obtain the standardized interaction duration value, so that the feature has a distribution characteristic with a mean of 0 and a standard deviation of 1, which facilitates the comparison between different protocols.

[0053] For the characteristics of interactive data volume, the preprocessing layer first takes the logarithm of the data volume (to reduce the impact of differences in data volume), and then divides the logarithmic value by the logarithm of the maximum supported data volume of the protocol to obtain a standardized interactive data volume value, which is also between 0 and 1.

[0054] After the above processing, the three features of interaction frequency, interaction duration, and interaction data volume are converted into dimensionless standardized values. These standardized values ​​are arranged in the order of protocol type and terminal identifier, and concatenated to form a multi-dimensional standardized protocol interaction feature vector. This standardized protocol interaction feature vector will be used as the input to the next layer of the model.

[0055] Step S132: The standardized protocol interaction feature vector is evaluated in multiple dimensions through the protocol adaptation evaluation layer of the protocol scheduling AI model. The multi-dimensional evaluation includes protocol communication efficiency evaluation, protocol compatibility evaluation, and protocol resource consumption evaluation.

[0056] The protocol adaptation evaluation layer comprises three parallel sub-modules: a communication efficiency evaluation sub-module, a compatibility evaluation sub-module, and a resource consumption evaluation sub-module. Standardized protocol interaction feature vectors are simultaneously distributed to these three sub-modules. Each sub-module independently processes the feature vectors based on preset evaluation logic, outputs the corresponding evaluation results, and finally, the comprehensive evaluation module aggregates and processes the results.

[0057] Step S1321: Input the standardized protocol interaction feature vector into the communication efficiency evaluation submodule of the protocol adaptation evaluation layer, and extract the feature components related to the interaction frequency and interaction duration from the standardized protocol interaction feature vector.

[0058] After receiving the standardized protocol interaction feature vector, the communication efficiency evaluation submodule uses a feature filter to locate the feature dimensions related to interaction frequency and duration within the vector. These feature dimensions are arranged in a fixed order within the vector, with the first half representing interaction frequency features for different time periods and the second half representing interaction duration features for the corresponding time periods. The feature filter then separates these feature dimensions from the vector using a pre-defined dimension index table, forming independent sets of feature components. For example, from a standardized vector containing 20 dimensions, dimensions 1-5 correspond to the interaction frequency in the morning, dimensions 6-10 to the interaction frequency in the afternoon, dimensions 11-15 to the interaction duration in the morning, and dimensions 16-20 to the interaction duration in the afternoon, forming a set containing 10 feature components.

[0059] Step S1322: Construct a protocol communication response rate description model based on the feature components. Use this protocol communication response rate description model to generate a description of the number of data interactions completed by each communication protocol type per unit time and a description of the average interaction time, which serve as the protocol communication response rate index.

[0060] The communication efficiency evaluation submodule inputs the extracted feature components into the protocol communication response rate description model. This model includes a frequency aggregation unit and a duration calculation unit. The frequency aggregation unit performs a weighted summation of the interaction frequency feature components of the same communication protocol type across different time periods. The weights are set according to the importance of each time period, generating a description of the number of interactions per unit time. The duration calculation unit performs an arithmetic average of the interaction duration feature components of the same communication protocol type, generating a description of the average interaction time. For example, the interaction frequency feature components in the morning and afternoon are assigned weights of 0.4 and 0.6 respectively, and the weighted summation yields the number of interactions per unit time throughout the day; the average interaction duration feature components in the morning and afternoon are then averaged to obtain the average interaction time for the entire day. These two descriptions together constitute the protocol communication response rate index.

[0061] Step S1323: Compare the protocol communication response rate index with multiple preset communication response rate evaluation standards in the multi-protocol adaptation association system, and determine the protocol communication efficiency level based on the comparison results. The protocol communication efficiency level corresponds to different evaluation intervals, and each evaluation interval corresponds to a unique efficiency rating.

[0062] The communication efficiency evaluation submodule retrieves a preset communication response rate evaluation standard from the multi-protocol adaptation association system. This standard includes multiple range intervals, each interval corresponding to the minimum and maximum number of interactions per unit time, as well as the minimum and maximum average interaction time. The number of interactions and average time in the generated protocol communication response rate index are compared with the range intervals in the standard. If the number of interactions and the average time fall within the range of a certain interval, the protocol receives an efficiency rating for that interval. For example, the "Excellent" rating corresponds to an interval where the number of interactions is ≥ a certain value and the average time is ≤ a certain value, while the "Good" rating corresponds to an interval where the number of interactions and the average time are both within a certain intermediate range. The protocol communication efficiency level is determined through this comparison.

[0063] Step S1324: Input the standardized protocol interaction feature vector into the compatibility evaluation submodule of the protocol adaptation evaluation layer, and extract the feature components related to the amount of interaction data in the standardized protocol interaction feature vector.

[0064] After receiving the standardized protocol interaction feature vector, the compatibility assessment submodule uses a feature extractor to identify feature dimensions related to the amount of interactive data in the vector. These feature dimensions record the changes in data volume for different data types during transmission, including features such as single-frame data volume, daily average total data volume, and peak data volume. Based on a feature label table, the feature extractor extracts these dimensions from the vector to form a set of interactive data volume feature components. For example, it extracts the standardized values ​​of dimensions 3-7 (corresponding to single-frame data volume), dimensions 8-12 (corresponding to daily average total data volume), and dimensions 13-17 (corresponding to peak data volume) from the standardized vector to form independent sets of feature components.

[0065] Step S1325: Query the data transmission format characteristics corresponding to each communication protocol type in the multi-protocol adaptation association system, analyze the matching relationship between the structure of the interactive data volume and the data transmission format characteristics, and generate a matching degree description.

[0066] The compatibility assessment submodule retrieves data transmission format characteristics for the corresponding communication protocol type from the multi-protocol adaptation association system using protocol identifiers. These characteristics include maximum single-frame length, data field structure, and field length limits. The extracted interactive data volume feature components are then compared item by item with these format characteristics: whether the actual data volume corresponding to the single-frame data volume feature component exceeds the maximum single-frame length, whether the order of data fields matches the field definitions in the format characteristics, and whether the actual length of each field meets the field length limits. Based on the comparison results, a matching degree description is generated, such as "single-frame data volume does not exceed the limit and field structure matches perfectly," "single-frame data volume exceeds the limit but field structure matches," and "field structure has mismatched items."

[0067] Step S1326: Compare the matching degree description with the preset compatibility evaluation criteria in the multi-protocol adaptation association system to determine the protocol compatibility level. The protocol compatibility level corresponds to different evaluation intervals, and each evaluation interval corresponds to a unique compatibility rating.

[0068] The compatibility assessment submodule retrieves the preset compatibility assessment standards from the multi-protocol adaptation association system. These standards divide the matching degree into multiple assessment intervals, each corresponding to a different compatibility rating. For example, "single frame data volume not exceeding the limit and field structure completely matching" corresponds to an "Excellent" rating; "single frame data volume not exceeding the limit but with some field length deviations" corresponds to a "Good" rating; and "single frame data volume exceeding the limit or field structure severely mismatched" corresponds to a "Medium" or "Poor" rating. The generated matching degree description is compared with the intervals in the assessment standards to determine the protocol compatibility level.

[0069] Step S1327: Input the standardized protocol interaction feature vector into the resource occupancy assessment submodule of the protocol adaptation assessment layer to obtain the hardware resource parameters reported by each IoT sensing terminal. The hardware resource parameters include processor occupancy rate, memory usage rate and bandwidth occupancy.

[0070] After receiving the standardized protocol interaction feature vector, the resource occupancy assessment submodule obtains hardware resource parameters from the status reports of IoT sensing terminals through the terminal interface. These parameters are reported periodically and stored in the terminal status database. The resource occupancy assessment submodule queries the database based on the terminal identifier to extract the processor utilization rate, memory utilization rate, and bandwidth utilization data for the most recent period. These data are expressed as percentages, reflecting the current resource usage status of the terminal.

[0071] Step S1328: Analyze the hardware resource parameter occupancy patterns of different communication protocol types during runtime, and generate a resource occupancy distribution description.

[0072] The resource usage assessment submodule correlates hardware resource parameters with resource-related feature components in the standardized protocol interaction feature vector to identify the patterns of processor, memory, and bandwidth usage during operation for different communication protocol types. For example, it analyzes the peak changes in processor usage during data transmission for the LoRa protocol, the continuous fluctuations in memory usage for the ZigBee protocol, and the periodic characteristics of bandwidth usage for the NB-IoT protocol. Based on the analysis results, it generates a resource usage distribution description, such as "processor usage peaks higher during transmission periods, memory usage is stable, and bandwidth usage is concentrated in fixed time periods," reflecting the resource usage characteristics of the protocols.

[0073] Step S1329: Compare the resource occupancy distribution description with the preset resource occupancy evaluation criteria in the multi-protocol adaptation association system to determine the protocol resource occupancy level. The protocol resource occupancy level corresponds to different evaluation intervals, and each evaluation interval corresponds to a unique resource occupancy rating.

[0074] The resource usage assessment submodule retrieves preset resource usage assessment standards from the multi-protocol adaptation association system. These standards set different threshold ranges for processor utilization, memory usage, and bandwidth usage, combining to form multiple assessment intervals. For example, "processor utilization ≤ 30%, memory usage ≤ 40%, bandwidth usage ≤ 20%" corresponds to an "Excellent" level; "processor utilization 30%-50%, memory usage 40%-60%, bandwidth usage 20%-40%" corresponds to a "Good" level; and values ​​exceeding these ranges correspond to "Medium" or "Poor" levels. The parameter values ​​in the resource usage distribution description are compared with the intervals of the assessment standards to determine the protocol resource usage level.

[0075] Step S133: In the process of evaluating protocol communication efficiency, a protocol communication response rate description is generated based on the interaction frequency and interaction duration in the standardized protocol interaction feature vector. Combined with the preset communication response rate evaluation standard in the multi-protocol adaptation association system, the protocol communication efficiency level is determined.

[0076] The protocol communication efficiency evaluation submodule extracts standardized values ​​corresponding to the interaction frequency and duration from the standardized protocol interaction feature vector. A higher standardized value for the interaction frequency indicates more interactions per unit time and better data transmission timeliness; a lower standardized value for the interaction duration indicates shorter interaction times and faster data transmission response speed.

[0077] Based on the combination of these two standardized values, a protocol communication response rate description is generated, such as "high frequency - short latency", "medium frequency - medium latency", "low frequency - long latency", etc. These descriptions qualitatively reflect the communication response performance of the protocol.

[0078] Subsequently, the communication response rate evaluation standard, pre-defined in the multi-protocol adaptation and association system, was referenced. This standard sets multiple evaluation intervals for each protocol type, with each interval corresponding to an efficiency level. For example, for the LoRa protocol, if the interaction frequency normalization value is in a high interval and the interaction duration normalization value is in a low interval, the corresponding efficiency level is "Excellent"; if the interaction frequency normalization value is in a medium interval and the interaction duration normalization value is in a medium interval, the efficiency level is "Good"; and if the interaction frequency normalization value is in a low interval and the interaction duration normalization value is in a high interval, the efficiency level is "Medium" or "Poor".

[0079] The generated protocol communication response rate description is compared with the interval in the evaluation criteria to determine the communication efficiency level corresponding to the protocol, and the level is converted into a corresponding quantitative score for subsequent comprehensive evaluation.

[0080] Step S134: During the protocol compatibility assessment process, analyze the matching relationship between the amount of interactive data in the standardized protocol interaction feature vector and the data transmission format features of each communication protocol type, and determine the protocol compatibility level by combining the preset compatibility assessment criteria in the multi-protocol adaptation association system.

[0081] The protocol compatibility assessment submodule extracts the standardized value of the amount of interactive data from the standardized protocol interaction feature vector and analyzes it in conjunction with the data transmission format characteristics of the corresponding protocol in the multi-protocol adaptation association system.

[0082] First, determine if the amount of interactive data is within the maximum data volume supported by the protocol. If the actual data volume corresponding to the standardized value of the interactive data volume exceeds the maximum limit of the protocol, it indicates that the data volume does not match the protocol format. Second, analyze whether the data structure conforms to the data frame structure and field definitions of the protocol, such as whether the length and order of data fields are consistent with the protocol requirements, and whether there are any redundant or missing fields.

[0083] Based on the above analysis results, a description of the matching degree between the generated data volume and the protocol format is given, such as "complete match", "partial match", "no match", etc.

[0084] Then, the system incorporates a pre-defined compatibility evaluation standard within the multi-protocol adaptation and association framework. This standard sets different matching degree ranges and corresponding compatibility levels for each protocol. For example, for the ZigBee protocol, if the matching degree is described as "complete match," the compatibility level is "excellent"; if it is "partial match" and does not affect core data transmission, the level is "good"; if it is "no match" or "partial match but affects core data," the level is "medium" or "poor."

[0085] Based on the comparison results between the matching degree description and the evaluation criteria, the compatibility level of the protocol is determined and converted into a quantitative score.

[0086] Step S135: During the protocol resource occupancy assessment process, the hardware resource occupancy patterns of different communication protocol types during operation are analyzed by combining the hardware resource parameters of each IoT sensing terminal. The protocol resource occupancy level is determined by combining the preset resource occupancy assessment standards in the multi-protocol adaptation association system.

[0087] The protocol resource usage assessment submodule first obtains the hardware resource parameters reported by each IoT sensing terminal, including processor utilization, memory usage, battery power consumption, etc.

[0088] Then, the resource usage patterns of different communication protocols during operation are analyzed to form a resource usage pattern description. For example, during data transmission, the LoRa protocol shows a pattern of brief increase followed by rapid decrease in processor utilization, relatively stable memory usage, and low battery power consumption; the NB-IoT protocol has higher processor and memory utilization during the connection establishment phase, relatively stable utilization during data transmission, and moderate overall power consumption.

[0089] Next, the system incorporates a pre-defined resource usage assessment standard within the multi-protocol adaptation and association framework. This standard sets different usage ranges for each hardware resource parameter, along with corresponding resource usage levels for different protocol types within these ranges. For example, regarding battery power consumption, if a protocol's power consumption level is in the low range, its resource usage level is "Excellent"; in the medium range, it is "Good"; and in the high range, it is "Medium" or "Poor".

[0090] By comparing the usage of various hardware resource parameters with the evaluation criteria, the resource usage level of the protocol is determined and converted into a quantitative score.

[0091] Step S136: Based on the protocol communication efficiency level, protocol compatibility level, and protocol resource consumption level, generate a protocol adaptability evaluation result, which includes the adaptability score corresponding to each communication protocol type.

[0092] The comprehensive evaluation module receives quantitative scores from three sub-modules: protocol communication efficiency evaluation, protocol compatibility evaluation, and protocol resource consumption evaluation. The scores of each sub-module are weighted according to preset weights, which are set based on the importance of each evaluation dimension in the overall adaptability (e.g., in a forest monitoring scenario, communication efficiency and resource consumption may have higher weights).

[0093] The calculation method is as follows: multiply the score corresponding to the communication efficiency level by its weight, add the score corresponding to the compatibility level by its weight, and add the score corresponding to the resource consumption level by its weight to obtain the total adaptation score of the protocol.

[0094] For example, if the communication efficiency score is A with a weight of 0.4, the compatibility score is B with a weight of 0.3, and the resource consumption score is C with a weight of 0.3, then the total adaptation score is A×0.4+B×0.3+C×0.3.

[0095] The generated protocol compatibility evaluation results include the total compatibility score of each communication protocol type on each terminal. The higher the score, the better the compatibility of the protocol on the terminal.

[0096] Step S137: Based on the adaptation score in the protocol adaptability evaluation result, determine the communication protocol type to be adjusted for each IoT sensing terminal and the corresponding adjustment direction, and generate a multi-protocol scheduling instruction that includes protocol switching instructions and transmission parameter adjustment instructions.

[0097] Based on the compatibility score in the protocol compatibility assessment results, the protocol currently used by each IoT sensing terminal is determined. If the compatibility score of the protocol currently used by a terminal is high (e.g., above a set threshold), no protocol switching is required, but fine-tuning of transmission parameters may be necessary; if the compatibility score is low, switching to a protocol with a higher compatibility score from the set of interoperable protocol types for that terminal is considered.

[0098] For situations requiring adjustment of transmission parameters, the adjustment direction is determined based on the evaluation results. For example, if the interaction frequency is low, the frequency can be appropriately increased; if the interaction time is prolonged, the data frame length can be reduced to shorten the duration; if the resource consumption is too high, the transmission rate can be reduced to reduce power consumption, and corresponding transmission parameter adjustment instructions are generated.

[0099] For cases requiring protocol switching, the target protocol type is specified, and a protocol switching instruction is generated. The instruction includes information such as the timing of the protocol switching and the data caching strategy during the switching process.

[0100] The final generated multi-protocol scheduling instruction is a collection of adjustment information for each terminal. Each instruction corresponds to a terminal and clarifies whether the terminal needs to switch protocols and the transmission parameters that need to be adjusted.

[0101] Step S140: Dynamically optimize the sensing parameters of the IoT sensing terminal according to the multi-protocol scheduling instruction to obtain an optimized set of sensing parameter configurations.

[0102] The remote management platform adjusts the sensing parameters of each IoT sensing terminal according to the multi-protocol scheduling instructions generated in step S137. This includes changing the communication protocol used by the terminal according to the protocol switching instructions, modifying the data transmission related parameters of the terminal (such as transmission rate, data frame length, etc.) according to the transmission parameter adjustment instructions, and ensuring that the adjusted parameters match each other to form an optimized sensing parameter configuration, which is finally summarized into an optimized sensing parameter configuration set.

[0103] Step S141: Parse the multi-protocol scheduling instruction, extract the protocol switching instruction and transmission parameter adjustment instruction contained therein, and determine the IoT sensing terminal identifier to be optimized, the target communication protocol type, and the transmission parameter items to be adjusted.

[0104] The parsing module analyzes the multi-protocol scheduling instructions, identifying protocol switching instructions and transmission parameter adjustment instructions. From the protocol switching instructions, it extracts the identifier of the IoT sensing terminal requiring protocol switching (e.g., "TH-001") and the target communication protocol type (e.g., switching from LoRa to NB-IoT). From the transmission parameter adjustment instructions, it extracts the identifier of the terminal to be optimized and the transmission parameters to be adjusted (e.g., data frame length, transmission rate, number of retransmissions, etc.).

[0105] Organize the extracted information into structured data, and clarify the adjustment goals and specific parameters for each terminal to be optimized.

[0106] Step S142: Query the current sensing parameter configuration information of the IoT sensing terminal to be optimized. The sensing parameter configuration information includes the current communication protocol type, the current value of the transmission parameters, and the sensing data acquisition frequency.

[0107] The terminal management module queries the current sensing parameter configuration information of the IoT sensing terminal to be optimized. For terminal "TH-001", it is found that the current communication protocol type is LoRa protocol, and the current values ​​of transmission parameters include a certain data frame length, a certain transmission rate, a certain number of retransmissions, and a sensing data collection frequency of once per hour.

[0108] This current configuration information is stored in a temporary data table and compared with the target parameters to be adjusted in order to determine the magnitude and direction of the adjustment.

[0109] Step S143: Based on the target communication protocol type, obtain the optimal transmission parameter range corresponding to the target communication protocol type from the multi-protocol adaptation association system. The optimal transmission parameter range includes the data frame length range, transmission rate range, and retransmission number range.

[0110] Based on the target communication protocol type (such as NB-IoT protocol) determined in step S141, the multi-protocol adaptation association system is queried to obtain the optimal transmission parameter range corresponding to the protocol. For the NB-IoT protocol, the optimal data frame length range is a certain interval (such as from minimum length to maximum length), which is determined based on the protocol's maximum transmission unit and the signal transmission characteristics in the forest environment; the optimal transmission rate range is a certain interval, taking into account the signal coverage and real-time requirements of data transmission; the optimal retransmission count range is a certain interval, balancing the reliability of data transmission and resource consumption.

[0111] These optimal transmission parameter ranges will serve as constraints for adjusting the transmission parameters, ensuring that the adjusted parameters remain within a reasonable range.

[0112] Step S144: Adjust the current value of the transmission parameter according to the transmission parameter adjustment instruction and the optimal transmission parameter range to generate the adjusted transmission parameter value.

[0113] For each transmission parameter item to be adjusted (such as data frame length), the adjustment is performed in conjunction with the adjustment direction and the optimal transmission parameter range in the transmission parameter adjustment instruction. If the adjustment instruction requires increasing the data frame length, and the current value is between the lower and upper limits of the optimal range and has not reached the upper limit, then the data frame length is increased according to the set step size; if the current value has reached the upper limit, then the current value is kept unchanged.

[0114] If the adjustment command requests a reduction in the transmission rate, and the current value is within the optimal range and has not reached the lower limit, then the transmission rate is reduced by a step size; if the current value has reached the lower limit, then it remains unchanged. The adjustment of the retransmission count follows a similar logic, processed according to the command direction and the optimal range.

[0115] After the adjustment is completed, the adjusted transmission parameter values ​​are generated, and these values ​​are checked to ensure that they are within the optimal transmission parameter range and meet the protocol requirements.

[0116] Step S1441: Extract the adjustment direction indication for each transmission parameter item from the transmission parameter adjustment instruction, wherein the adjustment direction indication includes increasing, decreasing or remaining unchanged.

[0117] The adjustment direction of each transmission parameter item is parsed from the transmission parameter adjustment instruction. For example, for the data frame length parameter, the adjustment direction is "increase"; for the transmission rate parameter, the adjustment direction is "decrease"; and for the retransmission count parameter, the adjustment direction is "remain unchanged".

[0118] These adjustment direction indicators clearly define the adjustment trend of each parameter and serve as a direct basis for parameter adjustments.

[0119] Step S1442: For each transmission parameter item, obtain its corresponding current value and optimal transmission parameter range. The transmission parameter item includes data frame length, transmission rate and number of retransmissions.

[0120] For the data frame length parameter, obtain its current value (e.g., a certain length value) and optimal range (e.g., minimum length to maximum length); for the transmission rate parameter, obtain its current value (e.g., a certain rate value) and optimal range (e.g., minimum rate to maximum rate); for the retransmission count parameter, obtain its current value (e.g., a certain number of times) and optimal range (e.g., minimum number of times to maximum number of times).

[0121] Step S1443: If the adjustment direction indicator is to increase, check whether the current value of the transmission parameter has reached the upper limit of the optimal transmission parameter range. If the current value of the transmission parameter has not reached the upper limit of the optimal transmission parameter range, increase the current value of the transmission parameter according to the preset adjustment step size to obtain the adjusted transmission parameter value. If the current value of the transmission parameter has reached the upper limit of the optimal transmission parameter range, keep the current value of the transmission parameter as the adjusted transmission parameter value.

[0122] Taking the data frame length parameter as an example, if the adjustment direction is "increase" and the current value is less than the upper limit value of the optimal range, the current value is increased by a preset step size (such as increasing a certain fixed length each time) to obtain the adjusted value. For example, if the current value is A, the upper limit value is B, A < B, and the step size is C, then the adjusted value is A + C (if A + C ≤ B). If the current value is already equal to or greater than the upper limit value, the adjusted value remains the current value.

[0123] Step S1444: If the adjustment direction indicates decrease, check whether the current value of the transmission parameter reaches the lower limit value of the optimal transmission parameter range. If the current value of the transmission parameter does not reach the lower limit value of the optimal transmission parameter range, decrease the current value of the transmission parameter by a preset adjustment step size to obtain the adjusted transmission parameter value. If the current value of the transmission parameter has reached the lower limit value of the optimal transmission parameter range, keep the current value of the transmission parameter as the adjusted transmission parameter value.

[0124] For the transmission rate parameter, if the adjustment direction is "decrease" and the current value is greater than the lower limit value of the optimal range, the current value is decreased by a preset step size (such as decreasing a certain fixed rate each time). For example, if the current value is D, the lower limit value is E, D > E, and the step size is F, then the adjusted value is D - F (if D - F ≥ E). If the current value is already equal to or less than the lower limit value, keep the current value unchanged.

[0125] Step S1445: If the adjustment direction indicates to remain unchanged, check whether the current value of the transmission parameter is within the optimal transmission parameter range. If it is, keep the original value. If it is not, independently for this parameter item, adjust it to a preset conservative value within its optimal transmission parameter range.

[0126] For the retransmission count parameter, if the adjustment direction is "remain unchanged", check whether its current value is within the optimal range. If it is within the range, keep the current value; if the current value is below the lower limit, adjust it to the lower limit value; if the current value is above the upper limit, adjust it to the upper limit value. The preset conservative value is usually the middle value or the lower limit value of the optimal range to ensure the stability of the parameter.

[0127] Step S1446: Perform verification processing on the adjusted transmission parameter values of each transmission parameter item to ensure that they meet the data transmission format feature requirements of the target communication protocol type. If the adjusted transmission parameter values do not meet the data transmission format feature requirements, readjust based on the optimal transmission parameter range until the adjusted transmission parameter values are both within the optimal transmission parameter range and meet the data transmission format feature requirements.

[0128] The adjusted transmission parameter values ​​are compared with the data transmission format characteristics of the target communication protocol type. For example, for the adjusted NB-IoT protocol data frame length, it is checked whether it meets the protocol's requirement of an integer multiple of the frame length or a specific field length limit. If it does not meet the requirement, a suitable value is selected again within the optimal transmission parameter range for adjustment, and steps S1443 to S1445 are repeated until the adjusted parameters simultaneously meet the optimal range and format characteristic requirements.

[0129] Step S145: Combine the adjusted transmission parameter values ​​to perform collaborative optimization processing on the sensing data acquisition frequency of the IoT sensing terminal, so that the sensing data acquisition frequency matches the adjusted transmission parameter values.

[0130] The data acquisition frequency needs to be matched with the adjusted transmission parameters to avoid data congestion or insufficient acquisition. For example, if the transmission rate increases and the data frame length increases, the acquisition frequency can be appropriately increased to fully utilize the transmission capacity; if the transmission rate decreases, the acquisition frequency may need to be reduced to avoid data accumulation.

[0131] During the collaborative optimization process, the appropriate acquisition frequency is determined by comprehensively considering the adjustment of transmission parameters and the hardware processing capabilities of the terminal.

[0132] Step S1451: Extract the transmission rate parameter from the adjusted transmission parameter value, and obtain the sensing data acquisition frequency constraint range corresponding to the transmission rate parameter from the multi-protocol adaptation association system.

[0133] Extract the transmission rate value from the adjusted transmission parameters and query the sensing data acquisition frequency constraint range corresponding to that transmission rate in the multi-protocol adaptation association system. For example, when the transmission rate is a certain value, its corresponding acquisition frequency constraint range is a certain interval (such as from the lowest frequency to the highest frequency), and this acquisition frequency constraint range is determined according to the amount of data that the transmission rate can carry.

[0134] Step S1452: Obtain the hardware processing capability parameters of the IoT sensing terminal. The hardware processing capability parameters include the processor data processing rate and memory data caching capability. Obtain the sensing data acquisition frequency constraint range corresponding to the hardware processing capability parameters from the multi-protocol adaptation association system.

[0135] The system obtains the terminal's processor data processing speed (e.g., the amount of data it can process per unit time) and memory data caching capacity (e.g., the maximum amount of cached data), queries the multi-protocol adaptation association system, and obtains the sensing data acquisition frequency constraint range corresponding to these hardware parameters. For example, when the processor processing speed is low, the corresponding acquisition frequency constraint range is low to avoid processor overload.

[0136] Step S1453: Determine the intersection of the sensing data acquisition frequency constraint range corresponding to the transmission rate parameter and the sensing data acquisition frequency constraint range corresponding to the hardware processing capability parameter, and use this intersection as the initial acquisition frequency selectable range.

[0137] The two frequency constraint ranges obtained in steps S1451 and S1452 are compared, and the overlapping portion is taken as the initial selectable range of the acquisition frequency. This initial selectable range of the acquisition frequency takes into account both transmission capability and hardware processing capability, ensuring that when the acquisition frequency is within this range, the terminal can transmit data in a timely manner without being unable to process it due to hardware limitations.

[0138] Step S1454: Analyze the data congestion records in the historical data transmission process of the IoT sensing terminal. If there are transmission congestion records caused by the acquisition frequency in the historical data, exclude the acquisition frequency interval corresponding to the congestion record from the initial acquisition frequency selectable range to obtain the intermediate acquisition frequency selectable range.

[0139] Query the terminal's historical data transmission records. If there are instances where data transmission congestion occurred due to excessively high collection frequency (such as long data queuing times or increased packet loss rates), record the corresponding collection frequency range. Remove this range from the initial selectable collection frequency range to obtain an intermediate selectable collection frequency range, thus preventing congestion from recurring.

[0140] Step S1455: If there are records of insufficient data collection due to the collection frequency in the historical data, the collection frequency interval corresponding to the insufficient data collection record is excluded from the initial collection frequency selection range to obtain the intermediate collection frequency selection range.

[0141] If there are instances in the historical records where insufficient data collection is caused by an excessively low collection frequency (e.g., the inability to reflect environmental changes in a timely manner), record the corresponding collection frequency range and exclude it from the initial range to obtain an intermediate range of selectable collection frequencies.

[0142] Step S1456: If there are no records of the above two types in the historical data, the initial sampling frequency selection range is used as the intermediate sampling frequency selection range.

[0143] If there are no records of data congestion or insufficient data collection in the terminal's historical data, the initial range of selectable collection frequencies will be used as the intermediate range of selectable collection frequencies.

[0144] Step S1457: Perform a stability test on the acquisition frequency in the selectable range of the intermediate acquisition frequency, simulate the sensing data transmission process under the acquisition frequency, and check whether data congestion or insufficient data acquisition occurs.

[0145] Multiple candidate frequency values ​​within the selectable range of intermediate acquisition frequencies are selected for simulation testing. During the simulation, virtual sensing data is generated according to the candidate frequencies, and transmission simulation is performed in conjunction with the adjusted transmission parameters to monitor for data congestion (such as transmission queue length exceeding the threshold) or insufficient data acquisition (such as data interval exceeding the set threshold).

[0146] Step S1458: If no data congestion or insufficient data acquisition occurs during the simulation, select any acquisition frequency from the intermediate acquisition frequency selection range as the final optimized sensing data acquisition frequency.

[0147] If a candidate frequency performs stably in the simulation test, without congestion or insufficient sampling, then that frequency or other well-performing frequencies can be selected from the middle range as the final sampling frequency.

[0148] Step S1459: If data congestion occurs during the simulation, the interval corresponding to the sampling frequency is excluded from the selectable range of intermediate sampling frequencies, and a new sampling frequency is selected for testing until a sampling frequency without data congestion is found, which is then used as the final optimized sensing data sampling frequency.

[0149] If congestion occurs during the simulation, the interval containing the candidate frequency is excluded from the middle range, and a new candidate frequency is selected from the remaining range for testing. The process of step S1457 is repeated until a suitable frequency is found.

[0150] Step S14510: If insufficient data acquisition occurs during the simulation, the interval corresponding to the acquisition frequency is excluded from the selectable range of intermediate acquisition frequencies, and the acquisition frequency is reselected for testing until an acquisition frequency without insufficient data acquisition is found, which is then used as the final optimized sensing data acquisition frequency.

[0151] If insufficient data is detected during the simulation, the corresponding frequency range is excluded, and testing continues within the remaining range until a suitable final sampling frequency is determined.

[0152] Step S146: Combine the adjusted transmission parameter values, target communication protocol type, and optimized sensing data acquisition frequency to generate sensing parameter configuration items for each IoT sensing terminal to be optimized.

[0153] For each IoT sensing terminal to be optimized, the adjusted transmission parameter values ​​obtained in step S144 (such as data frame length, transmission rate, and retransmission count), the target communication protocol type determined in step S141, and the optimized sensing data acquisition frequency obtained in step S145 are combined to form the sensing parameter configuration items for that terminal. For example, the configuration items for terminal "TH-001" are: target protocol NB-IoT, data frame length (a certain value), transmission rate (a certain value), retransmission count (a certain value), and acquisition frequency once every half hour.

[0154] Step S147: Summarize the sensing parameter configuration items of all IoT sensing terminals to be optimized to obtain the optimized sensing parameter configuration set. Each configuration item in the optimized sensing parameter configuration set is associated with the corresponding IoT sensing terminal identifier.

[0155] All terminal perception parameter configuration items are aggregated to form an optimized perception parameter configuration set. Each configuration item in the set is uniquely identified by a terminal identifier, ensuring that the remote management platform can accurately apply the configuration to the corresponding terminal. The configuration set is stored in a structured data format for easy subsequent transmission and application.

[0156] Step S150: Feed back the optimized set of sensing parameters to the remote management platform, and the remote management platform performs remote sensing control operations on the IoT sensing terminal based on the optimized set of sensing parameters.

[0157] The optimized set of sensing parameters is transmitted to the remote management platform. Based on the configuration information in this set, the platform sends control commands to each IoT sensing terminal to remotely adjust the terminal communication protocol and sensing parameters, ensuring that the terminal collects and transmits data according to the optimized parameters, thereby improving the performance of the entire monitoring system.

[0158] Step S151: Transmit the optimized sensing parameter configuration set to the parameter management module of the remote management platform, so that the parameter management module performs format verification processing on the optimized sensing parameter configuration set, stores the optimized sensing parameter configuration set that passes the format verification, and establishes an association storage structure between the sensing parameter configuration items and the IoT sensing terminal identifier.

[0159] The optimized set of perception parameter configurations is transmitted to the parameter management module of the remote management platform via an internal communication interface. The parameter management module validates the format of the configuration set, checking for format errors (such as mismatched parameter types or missing necessary fields). After successful validation, the configuration set is stored in the platform's configuration database, and an association is established between the perception parameter configuration items and the terminal identifier. The corresponding configuration item can be quickly retrieved using the terminal identifier.

[0160] Step S152: The remote management platform's control command generation module reads the optimized sensing parameter configuration set from the parameter management module, and generates a remote control command containing the target communication protocol type, adjusted transmission parameter values, and optimized sensing data acquisition frequency for each IoT sensing terminal identifier's corresponding sensing parameter configuration item.

[0161] The control command generation module reads the optimized set of sensing parameter configurations from the parameter management module and generates remote control commands for each terminal identifier's corresponding configuration item. The commands include the target communication protocol type (e.g., NB-IoT protocol), adjusted transmission parameter values ​​(data frame length, transmission rate, etc.), and optimized sensing data acquisition frequency. The command format conforms to the communication specifications between the remote management platform and the terminal.

[0162] Step S153: Based on the target communication protocol type in the remote control command, the communication module of the remote management platform queries the multi-protocol adaptation association system to obtain the corresponding protocol communication rules.

[0163] The communication module queries the multi-protocol adaptation association system based on the target communication protocol type in the remote control command to obtain the communication rules of the target communication protocol, including the data transmission baud rate, verification method, handshake process, etc. The above rules ensure that the control command can be correctly received and parsed by the terminal.

[0164] Step S154: According to the protocol communication rules, the remote control command is sent to the corresponding IoT sensing terminal, so that after receiving the remote control command, the IoT sensing terminal parses the parameter information therein, switches its own communication protocol according to the parsed target communication protocol type, configures its own transmission parameters according to the adjusted transmission parameter values, and adjusts its own sensing data acquisition rhythm according to the optimized sensing data acquisition frequency.

[0165] The communication module encodes the remote control command according to the acquired protocol communication rules and sends it to the corresponding IoT sensing terminal. Upon receiving the remote control command, the IoT sensing terminal uses its built-in command parsing module to extract information such as the target communication protocol type, transmission parameters, and data acquisition frequency. Subsequently, the terminal's protocol switching module switches to the target communication protocol, the parameter configuration module updates the transmission parameters, and the data acquisition control module adjusts the data acquisition frequency to ensure the terminal operates according to the new parameters.

[0166] Step S155: Receive parameter configuration status information from the IoT sensing terminal in real time through the status monitoring module of the remote management platform, and determine whether the IoT sensing terminal has successfully completed parameter configuration according to the remote control command.

[0167] The status monitoring module listens in real time to the parameter configuration status information sent by the IoT sensing terminal. This information includes indicators of whether the configuration was successful and the parameter values ​​after configuration. The monitoring module compares the returned parameter values ​​with the target values ​​in the remote control commands to determine whether the terminal has successfully completed the configuration.

[0168] Step S156: If the IoT sensing terminal is detected to have successfully completed parameter configuration, record the parameter configuration completion time and the corresponding configuration parameter information, and generate a parameter configuration success log.

[0169] If the terminal reports successful configuration and the parameter values ​​match the target values, the status monitoring module records the configuration completion time, terminal identifier, and configuration parameter information, generates a success log, and stores it in the log database for subsequent querying and auditing.

[0170] Step S157: If the IoT sensing terminal is detected to have failed to complete parameter configuration, the remote control command is regenerated and sent to the IoT sensing terminal until the IoT sensing terminal successfully completes parameter configuration or the preset retransmission limit is reached. If the retransmission limit is reached and the configuration still fails, a parameter configuration failure log is generated and an alarm is triggered.

[0171] If the terminal reports a configuration failure or the parameter value does not match the target value, the status monitoring module notifies the control command generation module to regenerate the remote control command, which is then resent by the communication module. This process is repeated until the terminal is successfully configured or the preset retransmission limit (e.g., five times) is reached. If the configuration still fails after reaching the limit, a failure log is generated, recording the reason for the failure (e.g., no response from the terminal, invalid parameter settings), and an alarm is triggered (e.g., displaying alarm information on the platform interface, sending an email to administrators) to facilitate timely manual intervention.

[0172] Figure 2 The illustration shows exemplary hardware and software components of a remotely managed multi-protocol IoT sensing system 100 that can implement the ideas of this application, according to some embodiments of this application. For example, a processor 120 can be used in the remotely managed multi-protocol IoT sensing system 100 and to perform the functions in this application.

[0173] The remotely managed multi-protocol IoT sensing system 100 can be a general-purpose server or a special-purpose server, both of which can be used to implement the remotely managed multi-protocol IoT sensing method of this application. Although only one server is shown in this application, for convenience, the functions described in this application can be implemented in a distributed manner on multiple similar platforms to balance the load.

[0174] For example, a remotely managed multi-protocol IoT sensing system 100 may include a network port 110 connected to a network, one or more processors 120 for executing program instructions, a communication bus 130, and various forms of storage media 140, such as a disk, ROM, or RAM, or any combination thereof. Exemplarily, the remotely managed multi-protocol IoT sensing system 100 may also include program instructions stored in ROM, RAM, or other types of non-transitory storage media, or any combination thereof. The methods of this application can be implemented according to these program instructions. The remotely managed multi-protocol IoT sensing system 100 also includes an I / O interface 150 between the computer and other input / output devices.

[0175] For ease of explanation, only one processor is described in the remotely managed multi-protocol IoT sensing system 100. However, it should be noted that the remotely managed multi-protocol IoT sensing system 100 of this application may also include multiple processors, and therefore the steps performed by one processor as described in this application may also be performed jointly or individually by multiple processors. For example, if the processor of the remotely managed multi-protocol IoT sensing system 100 performs steps A and B, it should be understood that steps A and B may also be performed jointly by two different processors or individually by one processor. For example, the first processor performs step A, the second processor performs step B, or the first processor and the second processor jointly perform steps A and B.

[0176] Furthermore, this embodiment of the invention also provides a readable storage medium, wherein computer-executable instructions are preset in the readable storage medium, and when the processor executes the computer-executable instructions, the above-mentioned multi-protocol IoT sensing method based on remote management is implemented.

[0177] It should be noted that, in order to simplify the description of the present invention and thus help to understand one or more embodiments of the invention, multiple features may sometimes be grouped into one embodiment, drawing or description thereof in the foregoing description of the embodiments of the present invention.

Claims

1. A multi-protocol IoT sensing method based on remote management, characterized in that, The method includes: A multi-protocol adaptation and association system is established, which is used to associate the communication protocol types supported by the remote management platform and each IoT sensing terminal. The communication protocol types include protocol categories corresponding to different data transmission formats. Acquire a multi-protocol sensing data set from IoT sensing terminals, and perform protocol interaction analysis processing on the multi-protocol sensing data set based on the multi-protocol adaptation and association system to obtain protocol interaction feature information; A pre-trained protocol scheduling AI model is invoked to perform protocol adaptability evaluation on the protocol interaction feature information, and multi-protocol scheduling instructions are generated. These multi-protocol scheduling instructions are used to adjust the protocol communication parameters of each IoT sensing terminal. The sensing parameters of the IoT sensing terminal are dynamically optimized according to the multi-protocol scheduling instructions to obtain an optimized set of sensing parameter configurations. The optimized set of sensing parameters is fed back to the remote management platform, which then performs remote sensing control operations on the IoT sensing terminal based on the optimized set of sensing parameters. The process of calling a pre-trained protocol scheduling AI model to perform protocol adaptability evaluation on the protocol interaction feature information and generate multi-protocol scheduling instructions includes: The protocol interaction feature information is input into the feature preprocessing layer of the protocol scheduling AI model. The interaction frequency, interaction duration and interaction data volume in the protocol interaction feature information are standardized to generate a standardized protocol interaction feature vector. The standardized protocol interaction feature vector is evaluated in multiple dimensions by the protocol adaptation evaluation layer of the protocol scheduling AI model. The multi-dimensional evaluation includes protocol communication efficiency evaluation, protocol compatibility evaluation, and protocol resource consumption evaluation. In the process of evaluating protocol communication efficiency, a protocol communication response rate description is generated based on the interaction frequency and interaction duration in the standardized protocol interaction feature vector. Combined with the preset communication response rate evaluation standard in the multi-protocol adaptation association system, the protocol communication efficiency level is determined. During the protocol compatibility assessment process, the matching relationship between the amount of interactive data in the standardized protocol interaction feature vector and the data transmission format features of each communication protocol type is analyzed. Combined with the preset compatibility assessment criteria in the multi-protocol adaptation association system, the protocol compatibility level is determined. During the protocol resource occupancy assessment process, the hardware resource parameters of each IoT sensing terminal are combined to analyze the hardware resource occupancy patterns of different communication protocol types during operation. Combined with the preset resource occupancy assessment standards in the multi-protocol adaptation association system, the protocol resource occupancy level is determined. Based on the combined communication efficiency level, compatibility level, and resource consumption level of the protocols, a protocol adaptability evaluation result is generated, which includes the adaptability score corresponding to each communication protocol type. Based on the adaptation score in the protocol adaptability evaluation results, the communication protocol type to be adjusted for each IoT sensing terminal and the corresponding adjustment direction are determined, and a multi-protocol scheduling instruction containing protocol switching instructions and transmission parameter adjustment instructions is generated.

2. The multi-protocol IoT sensing method based on remote management according to claim 1, characterized in that, The establishment of the multi-protocol adaptation and association system includes: Collect a list of protocols that are compatible with the remote management platform. The list of protocols compatible with the platform includes communication protocol identifiers that the remote management platform can recognize and the corresponding protocol parsing rules. Collect terminal protocol support information reported by each IoT sensing terminal. The terminal protocol support information includes the types of communication protocols that the IoT sensing terminal can run and the corresponding transmission capability descriptions for each type of communication protocol. The protocol compatibility list and the terminal protocol support information are mapped to each other to determine the set of communication protocol types that can be interoperated between the remote management platform and each IoT sensing terminal. For each communication protocol type in the set of interoperable communication protocol types, the data transmission format features of that communication protocol type are extracted. The data transmission format features include data frame structure, field definitions, and verification methods. Based on the set of interoperable communication protocol types and the corresponding data transmission format features, a multi-protocol adaptation association system is constructed. Each association entry in the multi-protocol adaptation association system includes a remote management platform protocol identifier, an IoT sensing terminal identifier, an interoperable communication protocol type, and the corresponding data transmission format features.

3. The multi-protocol IoT sensing method based on remote management according to claim 1, characterized in that, The process involves acquiring a multi-protocol sensing data set from an IoT sensing terminal, and performing protocol interaction analysis on the multi-protocol sensing data set based on the multi-protocol adaptation and association system to obtain protocol interaction feature information, including: The remote management platform receives sensing data sent by each IoT sensing terminal through its sensing data receiving module. The sensing data includes raw sensing data units transmitted by each IoT sensing terminal based on its own supported communication protocol type. The original sensing data units are processed to extract protocol identifiers to determine the communication protocol type identifier corresponding to each original sensing data unit; Query the multi-protocol adaptation association system to obtain the protocol parsing rules and data transmission format characteristics corresponding to the communication protocol type identifier; Based on the protocol parsing rules and data transmission format characteristics, the original sensing data unit is parsed and processed to extract the sensing content and transmission status parameters in the original sensing data unit. Correlation analysis is performed on the sensing content and corresponding transmission status parameters of different IoT sensing terminals to identify the interaction patterns between IoT sensing terminals based on different communication protocol types, and to generate protocol interaction feature information including interaction frequency, interaction duration and interaction data volume.

4. The multi-protocol IoT sensing method based on remote management according to claim 1, characterized in that, The process of performing multi-dimensional evaluation of the standardized protocol interaction feature vector through the protocol adaptation evaluation layer of the protocol scheduling AI model includes: The standardized protocol interaction feature vector is input into the communication efficiency evaluation submodule of the protocol adaptation evaluation layer to extract the feature components related to interaction frequency and interaction duration from the standardized protocol interaction feature vector. Based on the aforementioned feature components, a protocol communication response rate description model is constructed. This model generates a description of the number of data interactions completed per unit time for each communication protocol type and an average interaction time description, which serve as an indicator of the protocol communication response rate. The protocol communication response rate index is compared with multiple sets of communication response rate evaluation standards preset in the multi-protocol adaptation association system. The protocol communication efficiency level is determined based on the comparison results. The protocol communication efficiency level corresponds to different evaluation intervals, and each evaluation interval corresponds to a unique efficiency rating. The standardized protocol interaction feature vector is input into the compatibility evaluation submodule of the protocol adaptation evaluation layer to extract the feature components related to the amount of interaction data in the standardized protocol interaction feature vector. Query the data transmission format characteristics corresponding to each communication protocol type in the multi-protocol adaptation association system, analyze the matching relationship between the structure of the interactive data volume and the data transmission format characteristics, and generate a matching degree description; The protocol compatibility level is determined by comparing the matching degree description with the preset compatibility evaluation criteria in the multi-protocol adaptation association system. The protocol compatibility level corresponds to different evaluation intervals, and each evaluation interval corresponds to a unique compatibility rating. The standardized protocol interaction feature vector is input into the resource consumption assessment submodule of the protocol adaptation assessment layer to obtain the hardware resource parameters reported by each IoT sensing terminal. The hardware resource parameters include processor utilization, memory utilization, and bandwidth consumption. Analyze the hardware resource parameter usage patterns of different communication protocol types during runtime, and generate a resource usage distribution description; The resource occupancy distribution description is compared with the preset resource occupancy evaluation criteria in the multi-protocol adaptation association system to determine the protocol resource occupancy level. The protocol resource occupancy level corresponds to different evaluation intervals, and each evaluation interval corresponds to a unique resource occupancy rating.

5. The multi-protocol IoT sensing method based on remote management according to claim 1, characterized in that, The step of dynamically optimizing the sensing parameters of the IoT sensing terminal according to the multi-protocol scheduling instructions to obtain an optimized sensing parameter configuration set includes: The multi-protocol scheduling instruction is parsed to extract the protocol switching instruction and transmission parameter adjustment instruction contained therein, and to determine the IoT sensing terminal identifier to be optimized, the target communication protocol type, and the transmission parameter items to be adjusted. Query the current sensing parameter configuration information of the IoT sensing terminal to be optimized. The sensing parameter configuration information includes the currently used communication protocol type, the current value of the transmission parameters, and the sensing data acquisition frequency. Based on the target communication protocol type, the optimal transmission parameter range corresponding to the target communication protocol type is obtained from the multi-protocol adaptation association system. The optimal transmission parameter range includes the data frame length range, transmission rate range, and retransmission number range. Based on the transmission parameter adjustment instruction and the optimal transmission parameter range, the current value of the transmission parameter is adjusted to generate the adjusted transmission parameter value. By combining the adjusted transmission parameter values, the sensing data acquisition frequency of the IoT sensing terminal is optimized in a coordinated manner to match the sensing data acquisition frequency with the adjusted transmission parameter values. The adjusted transmission parameter values, target communication protocol type, and optimized sensing data acquisition frequency are combined to generate sensing parameter configuration items for each IoT sensing terminal to be optimized. The sensing parameter configuration items of all IoT sensing terminals to be optimized are summarized to obtain the optimized sensing parameter configuration set. Each configuration item in the optimized sensing parameter configuration set is associated with the corresponding IoT sensing terminal identifier.

6. The multi-protocol IoT sensing method based on remote management according to claim 5, characterized in that, The step of adjusting the current value of the transmission parameter according to the transmission parameter adjustment instruction and the optimal transmission parameter range to generate an adjusted transmission parameter value, ensuring that the adjusted transmission parameter value is within the optimal transmission parameter range, includes: Extract the adjustment direction indication for each transmission parameter item from the transmission parameter adjustment instruction, wherein the adjustment direction indication includes increasing, decreasing, or keeping it unchanged; For each transmission parameter item, obtain its corresponding current value and optimal transmission parameter range. The transmission parameter item includes data frame length, transmission rate and number of retransmissions. If the adjustment direction indicator is to increase, check whether the current value of the transmission parameter has reached the upper limit of the optimal transmission parameter range. If the current value of the transmission parameter has not reached the upper limit of the optimal transmission parameter range, increase the current value of the transmission parameter according to the preset adjustment step size to obtain the adjusted transmission parameter value. If the current value of the transmission parameter has reached the upper limit of the optimal transmission parameter range, keep the current value of the transmission parameter as the adjusted transmission parameter value. If the adjustment direction indicator is decrease, check whether the current value of the transmission parameter has reached the lower limit of the optimal transmission parameter range. If the current value of the transmission parameter has not reached the lower limit of the optimal transmission parameter range, decrease the current value of the transmission parameter according to the preset adjustment step size to obtain the adjusted transmission parameter value. If the current value of the transmission parameter has reached the lower limit of the optimal transmission parameter range, keep the current value of the transmission parameter as the adjusted transmission parameter value. If the adjustment direction indicator remains unchanged, check whether the current value of the transmission parameter is within the optimal transmission parameter range. If it is, keep the original value. If it is not, adjust the parameter item independently to a preset conservative value within its optimal transmission parameter range. The adjusted transmission parameter values ​​for each transmission parameter item are verified to ensure that they meet the data transmission format characteristics of the target communication protocol type. If the adjusted transmission parameter values ​​do not meet the data transmission format characteristics, they are readjusted based on the optimal transmission parameter range until the adjusted transmission parameter values ​​are both within the optimal transmission parameter range and meet the data transmission format characteristics.

7. The multi-protocol IoT sensing method based on remote management according to claim 5, characterized in that, The step of combining the adjusted transmission parameter values ​​to perform collaborative optimization processing on the sensing data acquisition frequency of the IoT sensing terminal, so that the sensing data acquisition frequency matches the adjusted transmission parameter values, includes: Extract the transmission rate parameter from the adjusted transmission parameter values, and obtain the sensing data acquisition frequency constraint range corresponding to the transmission rate parameter from the multi-protocol adaptation association system; Obtain the hardware processing capability parameters of the IoT sensing terminal, which include the processor data processing rate and memory data caching capability. Obtain the sensing data acquisition frequency constraint range corresponding to the hardware processing capability parameters from the multi-protocol adaptation association system. Determine the intersection of the sensing data acquisition frequency constraint range corresponding to the transmission rate parameter and the sensing data acquisition frequency constraint range corresponding to the hardware processing capability parameter, and use this intersection as the initial selectable range of acquisition frequency; Analyze the data congestion records in the historical data transmission process of IoT sensing terminals. If there are transmission congestion records caused by the collection frequency in the historical data, exclude the collection frequency interval corresponding to the congestion record from the initial collection frequency selection range to obtain the intermediate collection frequency selection range. If there are records of insufficient data collection due to the collection frequency in the historical data, the collection frequency interval corresponding to the insufficient data collection record is excluded from the initial collection frequency selection range to obtain the intermediate collection frequency selection range; If there are no records of either of the above two types in the historical data, the initial sampling frequency range will be used as the intermediate sampling frequency range. Stability tests were performed on the sampling frequencies within the selectable range of intermediate sampling frequencies to simulate the sensing data transmission process at the sampling frequencies and check whether data congestion or insufficient data acquisition occurred. If no data congestion or insufficient data collection occurs during the simulation, any collection frequency from the intermediate collection frequency selection range is selected as the final optimized sensing data collection frequency. If data congestion occurs during the simulation, the interval corresponding to the sampling frequency will be excluded from the range of selectable sampling frequencies, and a new sampling frequency will be selected for testing until a sampling frequency without data congestion is found, which will be used as the final optimized sensing data sampling frequency. If insufficient data acquisition occurs during the simulation, the interval corresponding to that acquisition frequency will be excluded from the selectable range of intermediate acquisition frequencies, and a new acquisition frequency will be selected for testing until an acquisition frequency without insufficient data acquisition is found, which will be used as the final optimized sensing data acquisition frequency.

8. The multi-protocol IoT sensing method based on remote management according to claim 1, characterized in that, The step of feeding back the optimized sensing parameter configuration set to the remote management platform, and having the remote management platform perform remote sensing control operations on the IoT sensing terminal based on the optimized sensing parameter configuration set, includes: The optimized sensing parameter configuration set is transmitted to the parameter management module of the remote management platform, so that the parameter management module performs format verification on the optimized sensing parameter configuration set, stores the optimized sensing parameter configuration set that passes the format verification, and establishes an associated storage structure between the sensing parameter configuration items and the IoT sensing terminal identifier. The remote management platform's control command generation module reads the optimized sensing parameter configuration set from the parameter management module, and generates a remote control command containing the target communication protocol type, adjusted transmission parameter values, and optimized sensing data acquisition frequency for each IoT sensing terminal identifier's corresponding sensing parameter configuration item. The communication module of the remote management platform queries the multi-protocol adaptation association system based on the target communication protocol type in the remote control command to obtain the corresponding protocol communication rules. According to the protocol communication rules, the remote control command is sent to the corresponding IoT sensing terminal, so that after receiving the remote control command, the IoT sensing terminal can parse the parameter information therein, switch its own communication protocol according to the parsed target communication protocol type, configure its own transmission parameters according to the adjusted transmission parameter values, and adjust its own sensing data collection rhythm according to the optimized sensing data collection frequency. The remote management platform's status monitoring module receives parameter configuration status information from the IoT sensing terminal in real time, and determines whether the IoT sensing terminal has successfully completed parameter configuration according to the remote control instructions. If the IoT sensing terminal is detected to have successfully completed parameter configuration, the parameter configuration completion time and the corresponding configuration parameter information are recorded, and a parameter configuration success log is generated. If the IoT sensing terminal fails to complete parameter configuration, the remote control command will be regenerated and sent to the IoT sensing terminal until the IoT sensing terminal successfully completes parameter configuration or the preset retransmission limit is reached. If the retransmission limit is reached and the configuration still fails, a parameter configuration failure log will be generated and an alarm will be triggered.

9. A multi-protocol IoT sensing system based on remote management, characterized in that, The remote-managed multi-protocol IoT sensing system includes a processor and a memory, the memory and the processor being connected. The memory is used to store programs, instructions or code, and the processor is used to execute the programs, instructions or code in the memory to implement the remote-managed multi-protocol IoT sensing method according to any one of claims 1-8.

Images