Control Method and System for Internet of Things Gateway Based on AI Computing Power

Abstract

The present invention relates to the technical field of network management, specifically a control method and system for an Internet of Things gateway based on AI computing power, including the following steps: obtaining the real-time signal strength, noise level and occupancy ratio of the channel, monitoring the protocol type and transmission situation, analyzing the relationship between the number of retransmissions and interference, deducing the protocol combination interference and throughput, configuring an optimal scheduling scheme, evaluating the resource consumption and load status, encapsulating and requesting permission delegation, and determining the permission information by combining the interaction record and the access control list. In the present invention, by simulating and deducing different protocol allocation combinations, the data throughput of the entire network is further estimated and optimized, and potential protocol conflicts are reduced, effectively improving the utilization efficiency and overall performance of network resources. Considering the consumption of local computing units and network bandwidth, the encapsulation process of request information is optimized, significantly improving the real-time response ability and manageability of the network status.

Description

Technical Field

[0001] The present invention relates to the technical field of network management, and particularly to a control method and system for an Internet of Things gateway based on AI computing power. Background Art

[0002] The technical field of network management includes various methods and systems for managing and monitoring network devices and their communications. The core content of this field covers multiple aspects such as device connection, data transmission, network security, system monitoring, and performance optimization. Network management technology continues to develop to adapt to the increasingly complex network environment and improve data processing capabilities. It includes everything from simple network device monitoring to complex data analysis and management strategies to ensure the effective allocation and use of network resources.

[0003] Among them, the control method for an Internet of Things gateway based on AI computing power refers to a technical solution that uses artificial intelligence technology to perform operations such as data collection, device management, and task scheduling on the Internet of Things gateway. This patent theme involves the reception, parsing, and storage of data, as well as the real-time monitoring and management of the status of the Internet of Things gateway. By analyzing and processing data of different communication protocols, such as Modbus, MQTT, CoAP, as well as Zigbee and LoRa, the Internet of Things gateway can be effectively configured and controlled. This solution also includes the management of task priorities and the optimization of computing resources, using neural network models and decision tree models to analyze data to achieve efficient management and control of the Internet of Things gateway.

[0004] In the prior art, when dealing with a complex network environment, especially in Internet of Things applications, due to the lack of real-time monitoring and dynamic analysis capabilities for interference between different communication protocols, the network management efficiency is not high and the communication quality is unstable. Existing network management methods rely on static device configurations and monitoring, and it is difficult to adapt to rapidly changing network states and diverse device requirements. For example, the lack of effective interference mapping and real-time scheduling strategies leads to frequent data retransmissions and connection failures, increasing network load and reducing the overall communication efficiency. Traditional network management methods lack sufficient flexibility and scalability when dealing with a large number of Internet of Things devices, and it is difficult to achieve efficient data processing and security control, affecting the reliability of the system and the user experience. Summary of the Invention

[0005] To address the technical problems existing in the prior art, such as the lack of real-time monitoring and dynamic analysis capabilities for interference between different communication protocols, resulting in low network management efficiency and unstable communication quality. Existing network management methods rely on static device configurations and monitoring, making it difficult to adapt to rapidly changing network states and diverse device requirements. For example, the lack of effective interference mapping and real-time scheduling strategies leads to frequent data retransmissions and connection failures, increasing network load and reducing overall communication efficiency. Traditional network management methods lack sufficient flexibility and scalability when dealing with a large number of Internet of Things (IoT) devices, making it difficult to achieve efficient data processing and security control, thus affecting the reliability of the system and the user experience. Embodiments of the present invention provide a control method and system for an IoT gateway based on AI computing power. The technical solutions are as follows:

[0006] On the one hand, a control method for an IoT gateway based on AI computing power is provided, and the method includes:

[0007] S1: Obtain the real-time signal strength, noise floor level, and channel occupancy time ratio data of the protocol channels within the working frequency band of the IoT gateway, perform correlation analysis, analyze the corresponding changes in the number of retransmissions of devices on neighboring frequencies for the target protocol, and obtain a cross-protocol interference impact map;

[0008] S2: Invoke the cross-protocol interference impact map, perform simulation deduction on the protocol allocation combination for the IoT gateway device access request and communication quality adjustment requirements, analyze the interference degree between IoT gateways in the network under the protocol allocation combination, and obtain an optimal protocol scheduling configuration;

[0009] S3: Adopt the optimal protocol scheduling configuration, evaluate the consumption of local computing units and network bandwidth according to the operation type and target device category identifier that the IoT gateway needs to invoke, combine the local network load status and the CPU occupancy rate range of the requesting gateway, encapsulate the request information, and obtain an encapsulated permission delegation request;

[0010] S4: According to the encapsulated permission delegation request, initiate federated interaction, design a computing task probe based on AI computing power and send it to the requesting party. The requesting party invokes the local sensor ID, operation parameters, and security status to execute the probe, perform joint inference, and generate a joint inference risk score.

[0011] As a further solution of the present invention, the cross-protocol interference impact map includes interference sensitivity, frequency band overlap rate, and interference intensity change trend. The optimal protocol scheduling configuration includes protocol conflict probability, spectrum utilization efficiency, and expected network stability. The encapsulated permission delegation request includes resource demand assessment results, network bandwidth demand assessment information, local network load threshold, and gateway CPU threshold range. The joint inference risk score includes sensor operation risk, network interface overload risk, and joint inference credibility.

[0012] As a further solution of the present invention, the step of obtaining the cross - protocol interference impact mapping is specifically as follows:

[0013] S101: Obtain the real - time signal strength, noise floor level, and channel occupancy time ratio data of the protocol channels within the working frequency band of the IoT gateway, monitor the protocol types, connection request time points, cumulative number of successful data transmissions, and cumulative number of data retransmissions of the devices managed by the gateway, and generate a real - time channel and device status data set;

[0014] S102: Invoke the real - time channel and device status data set, screen the data records of the target protocol and the activity data of the devices on adjacent frequencies, calculate the correlation coefficient between the data transmission activity time series of the target - protocol devices and the data retransmission times time series of the adjacent - frequency devices, and obtain the adjacent - frequency retransmission correlation metric;

[0015] S103: Based on the adjacent - frequency retransmission correlation metric, extract the channel occupancy time ratio value and the signal strength value, determine the interference impact degree of the differentiated protocol combinations under the conditions of channel occupancy and signal strength, evaluate the interference relationship and impact degree among multiple protocols, and establish a cross - protocol interference impact mapping.

[0016] As a further solution of the present invention, the step of obtaining the preferred protocol scheduling configuration is specifically as follows:

[0017] S201: Invoke the cross - protocol interference impact mapping, combine the IoT gateway device access request type and the communication quality adjustment target, perform multiple protocol allocation combinations, conduct simulation deductions for the protocol allocation combinations, and obtain the simulated protocol allocation results;

[0018] S202: Based on the simulated protocol allocation results, summarize the interference values among the IoT gateways in the network under multiple scenarios, calculate the overall network interference level, and estimate the expected total network throughput value and the expected number of conflict occurrences corresponding to the protocol allocation combination according to the simulated communication interaction process and interference level, and establish a protocol combination performance metric set;

[0019] S203: According to the protocol combination performance metric set, compare the network interference levels, expected total network throughput values, and expected number of conflict occurrences of the differentiated protocol allocation combinations, and obtain the preferred protocol scheduling configuration according to the preset optimization target weights.

[0020] As a further solution of the present invention, the step of obtaining the encapsulated permission delegation request is specifically as follows:

[0021] S301: Invoke the preferred protocol scheduling configuration, calculate the estimated consumption of local computing units and the estimated consumption of network bandwidth required for the operation according to the operation type to be performed by the IoT gateway and the target device category identifier, and obtain a resource consumption evaluation value;

[0022] S302: Use the resource consumption evaluation value to read the CPU occupancy rate range of the requesting gateway, invoke the resource consumption evaluation value, compare and calculate the resource requirements with the real-time IoT gateway status, and generate a request execution condition set;

[0023] The formula for comparing and calculating the resource requirements with the real-time IoT gateway status is as follows:

[0024] ;

[0025] Where, represents the gateway load index, represents the number of gateway status indicators for real-time monitoring, represents the index of the gateway status indicator, represents the th weight of the gateway status indicator, represents the th real-time value of the gateway status indicator, represents the gateway processing capacity benchmark value, represents the resource requirement evaluation value of the real-time request, represents the real-time available resource evaluation value of the gateway, represents the priority factor of the real-time request, represents the load fluctuation influence coefficient, represents the standard deviation of multiple load indicators within the gateway time period;

[0026] S303: Based on the request execution condition set, select the parameters that meet the conditions, combine with the scheduling instructions in the preferred protocol scheduling configuration, organize the information in a predetermined format, and combine the operation type, target identifier, resource requirements and scheduling request to obtain an encapsulated permission delegation request.

[0027] As a further solution of the present invention, the specific steps for obtaining the combined inference risk score are as follows:

[0028] S401: According to the operation type and target device information included in the encapsulated permission delegation request, start the federated interaction process, analyze the demand quantification index of the request for AI computing power resources, design a computing task probe including target operation instructions and data interaction specifications based on the quantification index, and send the probe data packet to the requesting IoT gateway to obtain computing task probe data;

[0029] S402: Use the computed task probe data to call the local sensor ID list, the corresponding operation parameter set, and the real-time security status identifier, execute the operation instruction sequence included in the probe, monitor the real-time input / output load value of the gateway network interface during the execution, and obtain the local probe execution and load data set;

[0030] S403: Based on the local probe execution and load data set, aggregate the probe execution result parameters and the network interface load value, perform joint inference operation processing, quantitatively evaluate the abnormality and conflict probability of the requested operation in the real-time environment, and obtain the joint inference risk score.

[0031] As a further solution of the present invention, the formula for monitoring the real-time input / output load value of the gateway network interface during the execution is as follows:

[0032] ;

[0033] Wherein, represents the load fluctuation index, represents the adjustment factor, represents the total number of sampling points during the monitoring period, represents the sampling time point index, represents the weight coefficient of the gateway network interface input load, represents at the sampling time point the real-time input load value, represents the average value of the input load values during the monitoring period, represents the weight coefficient of the gateway network interface output load, represents at the sampling time point the real-time output load value, represents the average value of the output load values during the monitoring period, represents the absolute change amount of the corresponding value of the real-time security status identifier during the monitoring period.

[0034] As a further solution of the present invention, the method further includes step S5:

[0035] S5: According to the joint inference risk score, refer to the requester gateway interaction record maintained by the service provider IoT gateway call, extract the interaction identifier, timestamp, request type, and response time of the remote control instruction and data sharing request, identify the successful completion, response event, and failure and negative event impacts in the interaction record, and obtain the permission decision information with reference to the recency of the interaction occurrence time;

[0036] The permission decision information includes the interaction trust level, the interaction timeliness evaluation result, and the negative interaction weight.

[0037] As a further solution of the present invention, the step of obtaining the permission decision information is specifically as follows:

[0038] S501: Using the combined inference risk score, call the interactive record data maintained by the service provider's IoT gateway for the requester gateway, extract the entries matching the remote control instruction type and data sharing request type, obtain the interactive identifier, occurrence timestamp, request type and response time of the entries, and generate an interactive record set;

[0039] S502: For multiple records in the interactive record set, according to the response time and the status identification information of the records, distinguish the types of successfully completed events, response events, failure events and negative impact events, integrate the record classification information and the recency quantification index, and obtain the permission decision information.

[0040] On the other hand, the control system of the IoT gateway based on AI computing power is used to execute the above-mentioned control method of the IoT gateway based on AI computing power. The system includes:

[0041] The protocol monitoring module obtains the protocol channel signal strength value, noise floor level value and channel occupancy time ratio value within the working frequency band of the IoT gateway, divides the channel into multiple adjacent frequency intervals according to the frequency band division principle, and combines the frequency band to which the protocol belongs and the noise floor level value for comparison and analysis to obtain the cross-protocol interference impact mapping;

[0042] The interference mapping module calls the cross-protocol interference impact mapping, selects the access request protocol identifier initiated by the real-time gateway and the alternative protocol set, evaluates the corresponding adjacent frequency interference mapping relationship, and obtains the preferred protocol scheduling configuration;

[0043] The strategy deduction module reorganizes the allocation of the candidate protocol combinations in the network topology according to the preferred protocol scheduling configuration, performs cumulative calculation based on the channel interference impact and transmission density coefficient corresponding to each combination, screens the combinations that meet the conditions, and obtains the encapsulated permission delegation request;

[0044] The task evaluation module calls the encapsulated permission delegation request, obtains the operation type identifier and target device category identifier that the IoT gateway needs to execute in real time, matches the protocol occupied resources in the combination, and generates a combined inference risk score;

[0045] The permission determination module compares and judges according to the combined inference risk score based on the request completion time tolerance interval and response time threshold interval set in the access control list, determines whether the interaction meets the authorization conditions, and performs combined classification on the above judgment results to obtain the permission decision information.

[0046] The beneficial effects brought by the technical solution provided by the embodiment of the present invention at least include:

[0047] By real-time monitoring of signal strength, noise floor level, and the proportion of channel occupancy time, and correlating management information of the IoT gateway device such as connection request time and the number of successful data transmissions, the understanding and mapping of cross-protocol interference are significantly enhanced. This in-depth data correlation analysis helps accurately map the interference effects between different devices, improving network stability and communication quality. By simulating different protocol allocation combinations, the data throughput of the entire network is further estimated and optimized, and potential protocol conflicts are reduced, effectively improving the utilization efficiency of network resources and overall performance. Considering the consumption of local computing units and network bandwidth comprehensively, the encapsulation processing of request information is optimized, and risk assessment and authorization decisions are made through federated learning methods, enhancing network adaptability and security. Through comprehensive analysis and dynamic configuration, the real-time response ability and manageability of the network state are significantly improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] Figure 1 is a schematic diagram of the working process of the present invention;

[0049] Figure 2 is a system flowchart of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0050] The technical solutions in the present invention will be described below with reference to the accompanying drawings.

[0051] In the embodiments of the present invention, words such as "exemplarily" and "for example" are used to represent examples, illustrations, or explanations. Any embodiment or design solution described as an "example" in the present invention should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of the word "example" is intended to present concepts in a specific manner. In addition, in the embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one of the two.

[0052] To make the technical problems, technical solutions, and advantages to be solved by the present invention clearer, the following will be described in detail with reference to the accompanying drawings and specific embodiments.

[0053] Please refer to Figure 1 , the embodiments of the present invention provide a control method for an IoT gateway based on AI computing power. The processing flow of this method may include the following steps:

[0054] S1: Obtain real-time signal strength, noise floor level, and the proportion of channel occupancy time data of protocol channels within the working frequency band of the IoT gateway, monitor the protocol type, connection request time, number of successful data transmissions, and number of data retransmissions of the IoT gateway management device, perform correlation analysis, analyze the corresponding changes in the number of retransmissions of devices on adjacent frequencies for the target protocol, and obtain a cross-protocol interference impact map;

[0055] S2: Invoke cross - protocol interference impact mapping. For the access requests of IoT gateway devices and the requirements for communication quality adjustment, simulate and deduce the protocol allocation combinations, analyze the interference degree among IoT gateways in the network under the protocol allocation combinations, estimate the expected total throughput and the expected number of conflict occurrences in the overall network, and obtain the optimal protocol scheduling configuration;

[0056] S3: Adopt the optimal protocol scheduling configuration. According to the operation types that the IoT gateway needs to invoke and the target device category identifiers, evaluate the consumption of local computing units and network bandwidth, combine the local network load status and the CPU occupancy rate range of the requesting gateway, and combine the network load and health status to encapsulate the request information and obtain the encapsulated permission delegation request;

[0057] S4: According to the encapsulated permission delegation request, initiate federated interaction. Design a computing task probe based on the AI computing power and send it to the requester. The requester invokes the local sensor ID, operation parameters, and security status to execute the probe, and combines the network interface load information of the IoT gateway to perform joint inference and generate a joint inference risk score;

[0058] S5: According to the joint inference risk score, refer to the interaction records of the requesting gateway maintained by the service - side IoT gateway call, extract the interaction identifiers, timestamps, request types, and response times of remote control instructions and data sharing requests, identify the successful completion, response events, and the impacts of failures and negative events in the interaction records, and obtain the permission decision information with reference to the recency of the interaction occurrence time;

[0059] The cross - protocol interference impact mapping includes interference sensitivity, frequency band overlap rate, and interference intensity change trend. The optimal protocol scheduling configuration includes protocol conflict probability, spectrum utilization efficiency, and expected network stability. The encapsulated permission delegation request includes resource demand assessment results, network bandwidth demand assessment information, local network load threshold, and gateway CPU threshold range. The joint inference risk score includes sensor operation risk, network interface overload risk, and joint inference credibility. The permission decision information includes interaction trust level, interaction timeliness assessment results, and negative interaction weight.

[0060] The specific steps for obtaining the cross - protocol interference impact mapping are as follows:

[0061] S101: Obtain the real - time signal strength, noise floor level, and channel occupancy time ratio data of the protocol channels within the working frequency band of the IoT gateway, monitor the protocol types of the devices managed by the gateway, the connection request time points, the cumulative number of successful data transmissions, and the cumulative number of data retransmissions, and generate a real - time channel and device status data set;

[0062] Obtain the real-time signal strength, noise floor level, and channel occupancy time ratio data of the protocol channels within the working frequency band of the IoT gateway. This process involves the wireless transceiver module of the gateway. Set up a gateway deployed with the LoRaWAN protocol stack, which contains the Semtech SX1301 chip inside. Set the gateway to work in the commonly used CN470 frequency band (470 - 510 MHz) in China. The specific operation is to command the wireless module to periodically perform Received Signal Strength Indication (RSSI) measurements on the target channel, such as 486.3 MHz, by accessing the interface provided by the hardware driver. The hardware will return a value, set to -75 dBm, which represents the signal power level of the channel at the current moment. At the same time, during the gap without expected signal transmission, perform noise floor measurement to obtain the background noise level of the channel itself, set to -110 dBm, which reflects the static noise environment of the channel. For the channel occupancy time ratio, a statistical period needs to be set, such as set to 60 seconds. During this period, the gateway continuously monitors the channel activity. It can be based on an energy detection threshold, such as set to -90 dBm, and any signal exceeding this energy is considered the channel is occupied, or by attempting to decode the physical layer preamble that conforms to a specific protocol (such as LoRaWAN) to judge. Record the start and end time points of each detected occupancy, accumulate the occupancy duration. Set that within the 60-second window, a total of 6.5 seconds of occupancy is detected, and calculate the occupancy ratio as (6.5 / 60) multiplied by 100%, getting 10.83%. In addition, it is also necessary to monitor the activities of the devices under the jurisdiction of the gateway. By parsing the received data frames, identify the device unique identifier (such as DevEUI0xAABBCCDDEEFF0011 in LoRaWAN) and the protocol it uses (LoRaWAN), record the exact timestamp (such as 2025-04-02 11:15:30.500 UTC) when the device attempts to join the network (JoinRequest), and maintain the status for each connected device, including the cumulative number of successful data transmissions and the cumulative number of data retransmissions. When the gateway successfully receives, validates, and passes a data frame (set to be new data verified by the frame counter and the MIC check is correct), the success count counter of the device is incremented by one. If a duplicate frame is received (judged based on the frame counter) or the device retransmits the uplink data to obtain a downlink confirmation, the retransmission count counter is incremented by one. Associate the real-time collected channel information (such as signal strength -75 dBm, noise floor -110 dBm, occupancy rate 10.83%) and device information (protocol type LoRaWAN, connection timestamp, success count such as 210 times, retransmission count such as 35 times) with the corresponding timestamps and identifiers, and store them structurally to form a real-time channel and device status data set.

[0063] S102: Invoke the real-time channel and device status data set, filter the data records of the target protocol and the activity data of devices on adjacent frequencies, calculate the correlation coefficient between the data transmission activity time series of the target protocol devices and the data retransmission times time series of adjacent frequency devices, and obtain the adjacent frequency retransmission correlation metric;

[0064] Use a programming interface or database query tool to access the data stored in step S101, perform a data query operation, specify that a specific target protocol needs to be extracted, for example, set to the Zigbee protocol and operating on channel 20 (center frequency 2.450 GHz), and limit the time range to the data records in the past hour. At the same time, filter out the device data that is active on adjacent frequencies. The definition of adjacent frequencies is based on a preset frequency range threshold, set to 8 MHz. Then, it is necessary to find the activity records of protocol devices with operating frequencies between 2.442 GHz and 2.458 GHz (but not including 2.450 GHz itself). Assume that Bluetooth devices (such as BLE broadcast channel 39, center frequency 2.480 GHz, although outside the 8 MHz range, but in practical applications, its proximity is considered according to the spectrum template) and WiFi devices (operating on channel 9, center frequency 2.452 GHz) are identified as active within this range. Filter out the records of non-target protocol devices, especially the data retransmission times records. Calculate the correlation between the data transmission activity time series of the target protocol (ZigbeeCh20) devices and the data retransmission times time series of adjacent frequency devices (WiFiCh9, BLECh39). For this purpose, the selected time range (the past hour) needs to be divided into consecutive equal-length time windows, set to one minute per window, a total of 60 windows. In each window, calculate the increment of the total number of successful data transmissions of the target protocol ZigbeeCh20, forming a time series containing 60 values, representing the change in its activity intensity. Set the series to [5, 7, 6, 8,...]. At the same time, in each of the same windows, calculate the increment of the sum of the data retransmission times of all adjacent frequency devices (WiFiCh9 and BLECh39), forming another time series containing 60 values, representing the interference activity or channel contention situation of adjacent devices. Set the series to [1, 2, 1, 3,...]. Evaluate the degree of linear association between these two time series, using the Pearson correlation coefficient to achieve. This calculation process examines the trend intensity of the synchronous increase and decrease of the values in the two series. There is no need to show the specific mathematical formula, just understand that its calculation logic is based on the sum of the products of the deviations of the values at each time point in the two series from their respective averages, and then perform a normalization process. Finally, a value between -1 and +1 is obtained. Set the calculation result to 0.55 to obtain the adjacent frequency retransmission correlation metric.

[0065] S103: Based on the adjacent frequency retransmission correlation metric, extract the channel occupancy time proportion value and the signal strength value, determine the interference impact degree of the differentiated protocol combination under the conditions of channel occupancy and signal strength, evaluate the interference relationship and impact degree among multiple protocols, and establish a cross-protocol interference impact mapping;

[0066] Based on the adjacent frequency retransmission correlation metric, that is, the correlation coefficient value calculated in S102, which is set to 0.55, extract the channel occupancy time proportion value and the signal strength value corresponding to the correlation calculation period (set to the past hour) and the target protocol (such as ZigbeeCh20) from the real-time channel and device status dataset generated in S101. The specific operation is to filter out all the channel status records of ZigbeeCh20 within this hour, calculate the average value of the ChannelOccupancy field, and set the average occupancy rate to 18.2%, and calculate the average value of the RSSI field, and set the average signal strength to -82dBm. Determine the interference impact degree of the differentiated protocol combination (such as the combination of ZigbeeCh20 and the adjacent WiFiCh9, BLECh39) under the currently observed channel occupancy (18.2%) and signal strength (-82dBm). This determination process requires preset discrimination criteria. Define the correlation coefficient threshold. A value greater than 0.6 is regarded as "high" correlation, a value between 0.4 and 0.6 is regarded as "medium" correlation, and a value less than 0.4 is regarded as "low" correlation. Define the channel occupancy rate threshold. A value greater than 25% is regarded as "high" occupancy, a value between 10% and 25% is regarded as "medium" occupancy, and a value less than 10% is regarded as "low" occupancy. Define the signal strength threshold. A value lower than -85dBm is regarded as "low" signal strength (or "poor" signal quality), a value between -75dBm and -85dBm is regarded as "medium" signal strength, and a value higher than -75dBm is regarded as "high" signal strength. Evaluate according to the currently obtained value combination: the correlation coefficient of 0.55 belongs to "medium" correlation, the occupancy rate of 18.2% belongs to "medium" occupancy, and the signal strength of -82dBm belongs to "medium" signal strength. Considering comprehensive factors, it can be determined that under the current conditions, the adjacent WiFi and BLE activities cause a medium degree of interference impact on ZigbeeCh20. This impact is reflected in the increase in the retransmission times and the change in the successful transmission times of Zigbee showing a certain synchrony, and it occurs in an environment where both the channel occupancy and the signal strength are at a medium level. Record this evaluation result to form a part of the cross-protocol interference impact mapping. This mapping will include different protocol pairs (such as ZigbeeCh20 vs WiFiCh9 / BLECh39), the observed correlation metric (0.55), the corresponding channel conditions (occupancy rate 18.2%, signal strength -82dBm), and the evaluated interference impact level (medium), and establish a cross-protocol interference impact mapping.

[0067] The specific steps for obtaining the preferred protocol scheduling configuration are as follows:

[0068] S201: calling cross-protocol interference impact mapping, combining the IoT gateway device access request type and the communication quality adjustment target, performing multiple protocol allocation combinations, performing simulation deduction on the protocol allocation combinations, and obtaining simulation protocol allocation results;

[0069] Call the cross-protocol interference impact mapping, which contains the interference relationship and degree evaluation results (such as "high", "medium" and "low" interference) of different protocols under specific channel conditions (such as occupancy rate, signal strength). Combined with the type of new device access request received by the current IoT gateway, set a request from a sensor that requires low-latency transmission (type A), and another from a camera that requires high-bandwidth transmission (type B), as well as a preset communication quality adjustment target. The setting target is to prioritize the delay of type A devices below 50 milliseconds, while maximizing the transmission rate of type B devices, and generate multiple protocol allocation combinations. The specific generation method can be based on available channel resources (such as the gateway supports several channels in the CN470 frequency band of LoRaWAN and several channels in the 2.4GHz frequency band of Zigbee) and interference mapping information (setting the mapping to show that ZigbeeCh15 has high interference with an active WiFi channel), try to allocate type A devices to LoRaWAN channels with lower interference (such as 486.5MHz), and allocate type B devices to Zigbee channels with high bandwidth (such as Ch20), generate the first combination plan (Scheme 1), and then try to allocate type A to another LoRaWAN channel (such as 486.7MHz), type B is assigned to ZigbeeCh21, generating plan 2, or both are assigned to different channels of LoRaWAN (plan 3), and so on, generating a series of candidate allocation plans, and performing simulation deduction for each generated protocol allocation combination. This deduction uses a simplified network model, which estimates the mutual influence between protocols based on the interference impact mapping. For plan 1, the model searches for the interference record of LoRaWAN486.5MHz and other signals in the current environment (from devices or gateways) in the mapping, so as to The interference records between ZigbeeCh20 and known active signals (such as WiFi) are combined with the expected communication mode of the devices (such as type A devices sending a short packet once a minute, and type B devices sending medium-sized image data every 10 seconds). The communication event flow in a short period of time is simulated, and basic indicators such as the probability of signal collision and transmission failure rate due to interference under this allocation are evaluated. There is no need for complex physical layer simulation. Instead, the effect after allocation is calculated based on the interference level provided by the mapping (such as "high" interference corresponds to an estimated 20% increase in packet loss rate) and channel occupancy data, and the channel occupancy rate data is used to obtain the simulated protocol allocation result.

[0070] S202: Based on the simulation protocol allocation results, summarize the interference values among the IoT gateways in the network under multiple scenarios, calculate the overall network interference level, and estimate the expected total network throughput value and the expected number of conflict occurrences corresponding to the protocol allocation combination according to the simulated communication interaction process and interference level, and establish a protocol combination effectiveness metric set;

[0071] Based on the simulation protocol allocation results, that is, the basic performance indicators deduced for each protocol allocation combination (such as Scenario 1, Scenario 2, Scenario 3) in S201, summarize the interference values among the IoT gateways in the network under multiple scenarios. Specifically, for each scenario, count the interference effects on all IoT device or gateway links involved in the simulation, quantify this effect, and use the interference levels in the S103 mapping (high = 3, medium = 2, low = 1, none = 0), or the additional packet loss rate estimated according to the simulation deduction (such as a 20% packet loss rate caused by high interference, then the interference value is 0.2), and accumulate or average the interference values that affect this gateway and neighboring gateways (if the simulation includes a multi-gateway scenario). Set the total interference value of Scenario 1 to be the interference value of Link A + the interference value of Link B, to obtain a value representing the cumulative effect of interference among gateways or devices under this scenario. For example, the interference value of Scenario 1 is 4.5 and that of Scenario 2 is 3.8. Calculate the overall network interference level, which can be the average of all link interference values, or the weighted average of the interference values of key links (such as low-latency device links), to obtain a single indicator reflecting the overall interference situation of the network. Set the overall interference level of Scenario 1 to be 0.15 and that of Scenario 2 to be 0.12. And according to the simulated communication interaction process (device sending frequency, data size) and the deduced interference level, estimate the expected total network throughput value corresponding to the protocol allocation combination. The calculation method can be to reduce the theoretical throughput of each device without interference according to the simulated interference level (such as a 0.15 interference level corresponding to a 15% throughput reduction) and then sum them up. Set the expected total throughput of Scenario 1 to be 85 kbps and that of Scenario 2 to be 92 kbps. At the same time, estimate the expected number of conflict occurrences. Based on the simulated channel occupancy and the probability of device sending time slot overlap, combined with the potential conflict information caused by neighboring protocol activities in the interference mapping, count the number of conflict events expected to occur during the simulation period. Set the expected number of conflicts in Scenario 1 to be 15 times per minute and that of Scenario 2 to be 10 times per minute. Combine the overall network interference level (such as 0.12), the expected total network throughput value (such as 92 kbps), and the expected number of conflict occurrences (such as 10 times per minute) calculated for each scenario to establish a protocol combination effectiveness metric set.

[0072] S203: According to the protocol combination effectiveness metric set, compare the network interference level, the expected total network throughput value, and the expected number of conflict occurrences of different protocol allocation combinations, and obtain the optimal protocol scheduling configuration according to the preset optimization target weights;

[0073] According to the protocol combination performance metric set, it includes quantitative evaluation indicators for multiple protocol allocation combinations (such as Scenario 1, Scenario 2, Scenario 3, etc.), including network interference level, expected total network throughput value, and expected number of conflicts. By comparing the performance indicators of different protocol allocation combinations, set Scenario 1 (interference 0.15, throughput 85 kbps, conflicts 15 times / minute) and Scenario 2 (interference 0.12, throughput 92 kbps, conflicts 10 times / minute) for side-by-side comparison. Evaluate according to the preset optimization target weights. The setting of the weights refers to specific application requirements and network management strategies. If the primary goal is to maximize network capacity, the weight of the expected total network throughput is the highest, such as set to 0.6. Followed by reducing conflicts, with a weight of 0.3. Finally, reducing the interference level, with a weight of 0.1, and the sum of the weights is 1.0 (0.6 + 0.3 + 0.1 = 1.0). The weight values reflect the relative importance of different performance indicators. Calculate the weighted scores for each scenario. Before calculation, it is necessary to normalize each indicator value. Set the interference and the number of conflicts to positive indicators that the smaller the better (such as using their reciprocals or subtracting the current value from the maximum value), and perform min-max normalization on the throughput. Set the indicators of Scenario 1 after normalization to (interference evaluation value 0.7, throughput evaluation value 0.8, conflict evaluation value 0.6), and the indicators of Scenario 2 to (interference evaluation value 0.8, throughput evaluation value 0.9, conflict evaluation value 0.8). Then the score of Scenario 1 is 0.1×0.7 + 0.6×0.8 + 0.3×0.6 = 0.07 + 0.48 + 0.18 = 0.73, and the score of Scenario 2 is 0.1×0.8 + 0.6×0.9 + 0.3×0.8 = 0.08 + 0.54 + 0.24 = 0.86. By comparing the scores (0.86 > 0.73), it is determined that Scenario 2 performs better under this weight configuration, and the preferred protocol scheduling configuration is obtained.

[0074] The specific steps for obtaining the encapsulated permission delegation request are as follows:

[0075] S301: Invoke the preferred protocol scheduling configuration. According to the operation type that the IoT gateway needs to execute and the target device category identifier, calculate the estimated consumption of local computing units and the estimated consumption of network bandwidth required to execute the operation, and obtain the resource consumption evaluation value;

[0076] Invoke the preferred protocol scheduling configuration, which is the selected best solution and includes protocol, channel, and related parameter allocation suggestions for different device types or communication requirements. According to the specific operation type that the IoT gateway needs to perform next, set whether to perform a batch data polling of all subordinate temperature and humidity sensors once (operation type A), or to perform a remote firmware upgrade on a specific smart lock (operation type B), and the target device category identifier for this operation, such as "low-power sensor group" or "specific high-security-level device". Calculate the estimated consumption of local computing units required to execute this specific operation, which includes the estimated CPU processing time and peak memory occupancy. For example, operation type A only requires relatively low CPU resources (such as an estimated 5% instantaneous increase in occupancy) and a small amount of memory (such as an estimated 1MB), while operation type B, due to firmware decompression, verification, and transmission control, requires significantly higher CPU resources (such as an estimated 40% instantaneous increase in occupancy) and a large amount of memory (such as an estimated 32MB). These estimated values can be obtained through benchmark tests or analysis based on historical operation data. At the same time, calculate the estimated consumption of network bandwidth required to execute the operation, which needs to combine the operation type and the communication protocol and parameters specified for this target device category in the preferred protocol scheduling configuration. If operation type A is scheduled to use LoRaWAN according to the configuration, each polling only needs to transmit dozens of bytes, and even if executed in batches, the total data volume is not large. The bandwidth consumption characteristic is low rate and long distance, and the estimated peak bandwidth requirement is only 0.5 kbps, but the total transmission time is relatively long. For the firmware upgrade of operation type B, even if the scheduling configuration selects a relatively high-speed Zigbee or BLE Mesh (such as the configuration recommends using Zigbee channel 25), the firmware file size (such as 512KB) determines the total data transmission volume, and the estimated peak bandwidth requirement reaches 50 kbps. Integrate the estimated consumption in these two dimensions (local computing unit consumption, such as 40% CPU and 32MB memory; network bandwidth consumption, such as peak 50 kbps and total data volume 512KB) to obtain the resource consumption evaluation value.

[0077] S302: Adopt the resource consumption evaluation value, read the CPU occupancy rate range of the requesting gateway, invoke the resource consumption evaluation value, compare and calculate the resource requirements with the real-time IoT gateway status, and generate a set of request execution conditions;

[0078] The formula for comparing and calculating the resource requirements with the real-time IoT gateway status is as follows:

[0079] ;

[0080] Among them, represents the gateway load index, represents the number of gateway status indicators monitored in real time, represents the index of the gateway status indicator, Represents the weight of the th gateway status indicator, Represents the real-time value of the th gateway status indicator, Represents the benchmark value of the gateway processing capacity, Represents the evaluation value of the resource requirements of real-time requests, Represents the evaluation value of the real-time available resources of the gateway, Represents the priority factor of real-time requests, Represents the load fluctuation impact coefficient, Represents the standard deviation of multiple load indicators within the gateway time period;

[0081] Parameter meaning and calculation process:

[0082] : The number of gateway status indicators for real-time monitoring, this value is determined according to the system monitoring configuration, set ;

[0083] : The index of the gateway status indicator, from 1 to ;

[0084] : The weight of the th gateway status indicator, this weight is set based on the importance of each indicator's impact on the overall load, and its sum can be 1 or normalized. The setting basis is the relative impact degree of the indicator on the gateway performance, and it can be adjusted according to data and operation and maintenance goals, set (CPU utilization rate), (Memory utilization rate), (Network bandwidth utilization rate);

[0085] : The real-time value of the th gateway status indicator, collected through monitoring tools;

[0086] (CPU utilization rate): Obtained by reading the performance counter of the operating device, the monitored value is 65(%);

[0087] (Memory utilization rate): Obtained by reading the performance counter of the operating device, the monitored value is 75(%);

[0088] (Network bandwidth utilization rate): Obtained by monitoring the network interface traffic, the monitored value is 200Mbps, and the maximum bandwidth of the gateway is 1000Mbps, and normalization is required;

[0089] : Gateway processing capacity benchmark value, representing the standard processing capacity of the gateway, is set based on hardware specifications (such as CPU main frequency, number of cores, memory size), and is set to a normalized exponential value of 100;

[0090] Normalization: To make indicators with different units comparable, it needs to be normalized to the same scale (0 - 100), , , ;

[0091] : Resource demand assessment value of the current request, generated by the previous resource consumption assessment step, using the same normalized exponential unit, and the demand for this request is evaluated to be 25;

[0092] : Comprehensive assessment value of the current available resources of the gateway, calculated based on the currently unused resources, and the calculation method is ;

[0093] : Priority factor of the current request, non - numerical data (such as high, medium, low) needs to be quantified;

[0094] Quantification standard: High priority = 1.5, medium priority = 1.0, low priority = 0.5, and the value is used to adjust the influence of the request in the load calculation;

[0095] The current request has a medium priority, and obtain , and this value is assigned according to the classification or source information of the request;

[0096] : Load fluctuation influence coefficient, an adjustment coefficient set according to the running and expected stability sensitivity of the gateway, set , the higher this value, the greater the influence of the fluctuation on the current index;

[0097] : Weighted standard deviation of each load index (after normalization) within the gateway time period, calculated based on the monitoring data, reflecting the recent load stability;

[0098] Calculate the standard deviation of each index in the past hour: (CPU%), (Memory%), (Normalized network%);

[0099] Calculate the weighted standard deviation: ;

[0100] Calculation derivation process:

[0101] Calculate the current weighted load: ;

[0102] Calculate the available resource evaluation value : ;

[0103] Calculate the weighted standard deviation : ;

[0104] Obtain parameter values: , , , ;

[0105] Substitute parameters for calculation :

[0106] ;

[0107] The result shows the current comprehensive load index of the gateway. This index combines the real-time resource occupancy ratio of the gateway, the ratio of the resources required by the request to the available resources, the priority of the request, and the stability of the gateway load in the near future. The index value quantifies the load pressure state of the gateway when receiving this request. This value will be used as the core basis and input into the subsequent processing link to generate a set of request execution conditions to determine whether to execute immediately, queue for waiting, or reject this request.

[0108] S303: Based on the set of request execution conditions, select the parameters that meet the conditions, combine with the scheduling instructions in the preferred protocol scheduling configuration, organize the information in a predetermined format, and combine with the operation type, target identifier, resource requirements, and scheduling request to obtain an encapsulated permission delegation request;

[0109] Select parameters that meet the conditions, which means checking whether all items in the condition set are "yes" or acceptable. If all key conditions are met (set CPU to meet: yes, bandwidth to meet: yes), the process continues. If there are unsatisfied conditions, it is necessary to trigger an alarm, wait or re-plan. Set the conditions to meet, combined with the specific scheduling instructions specified for this operation type and target device category in the preferred protocol scheduling configuration (from S203), set the configuration to clearly indicate "for operation type B-firmware upgrade, target category high security device, use protocol Zigbee, channel 25, high priority, and allow a maximum of 3 retransmissions", organize information according to a predetermined format, and the predetermined format is a standardized data structure. Set A JSON object is set to encapsulate all necessary information. Its fields may include an operation type identifier (such as "FW_UPGRADE"), a list of specific target device identifiers (such as ["DeviceID_Lock001", "DeviceID_Lock002"]), resource requirement estimates, and scheduling request details. It also includes the gateway ID that initiated the request, a timestamp, and a unique identifier for the request. The information fragments: operation type (firmware upgrade), target identifier (lock ID), resource requirements (CPU, memory, bandwidth estimation) and scheduling request (specific execution parameters such as protocol, channel, priority, etc.) are integrated and filled into the predefined structure to obtain an encapsulated permission delegation request.

[0110] The specific steps for obtaining the joint inference risk score are as follows:

[0111] S401: According to the operation type and target device information included in the encapsulated permission delegation request, the federation interaction process is started, the quantitative indicators of the AI ​​computing resource requirements of the request are analyzed, and a computing task probe including target operation instructions and data interaction specifications is designed based on the quantitative indicators, and the probe data packet is sent to the requesting party's IoT gateway to obtain computing task probe data;

[0112] Based on the operation type included in the encapsulation permission delegation request, it is set that the request is to execute a machine learning-based device behavior anomaly detection model (operation type C), and target device information. For example, for the entire "high-frequency vibration sensor" device group in the factory workshop, a federated interaction process is initiated. This initiation involves sending an initial handshake message containing a request summary (operation type, target device category, initiating gateway ID) to the federated learning coordinator or a designated peer gateway, and analyzing the quantification index of the request's demand for AI computing power resources. The specific analysis is to look up a predefined resource demand mapping table, which estimates the required computing power according to operation type C (execution of the anomaly detection model) and the number of target devices (50 high-frequency vibration sensors are set). The mapping table indicates that such an operation requires approximately 0.8 TFLOPS (trillions of floating-point operations per second) of peak computing power and 128 MB of model loading memory. At the same time, data processing requirements are considered, such as processing a data stream of approximately 5 MB per second from 50 sensors, constituting the quantification indexes flops_peak: 0.8, memory_model_mb: 128, data_rate_mbps: 40. According to the quantification indexes, a computing task probe including target operation instructions and data interaction specifications is designed. The design process is to generate a small, representative computing load, set it to include several matrix multiplication and convolution operations (simulating the core calculations of model inference), and specify that its input data should simulate a short-time (such as 100 milliseconds) data stream from 10 sensors. The data interaction specification defines how to simulate data sending and receiving during the execution of the probe, such as specifying a simulated data sending rate and packet size. This probe is essentially a small test program or script, and this probe data packet, that is, a data structure containing operation instructions (such as a section of WebAssembly code or a specific DSL script) and interaction specifications (such as simulated traffic parameters), is sent to the IoT gateway that initiated the permission delegation request through a secure P2P connection or via the coordinator. After the receiving gateway confirms the receipt of the probe packet, it sends a receipt, enabling the sender to obtain the status that the computing task probe data has been successfully delivered, and obtaining the computing task probe data.

[0113] S402: Adopt the computing task probe data, call the local sensor ID list, the corresponding operation parameter set, and the real-time security status identifier, execute the operation instruction sequence included in the probe, and monitor the real-time input and output load values of the gateway network interface during the execution to obtain the local probe execution and load data set;

[0114] The formula for monitoring the real-time input and output load values of the gateway network interface during the execution is as follows:

[0115] ;

[0116] Among them, represents the load fluctuation index, represents the adjustment factor, represents the total number of sampling points during the monitoring period, represents the sampling time point index, represents the weight coefficient of the input load of the gateway network interface, represents at the sampling time point the real-time input load value, represents the average value of the input load values during the monitoring period, represents the weight coefficient of the output load of the gateway network interface, represents at the sampling time point the real-time output load value, represents the average value of the output load values during the monitoring period, represents the absolute change in the corresponding value of the real-time security status flag during the monitoring period;

[0117] Parameter acquisition and setting:

[0118] : The operation parameter adjustment factor, which is set to 1.1 according to the complexity evaluation of the currently executed operation parameter set. This value changes with the resource requirements of the probe task. The higher the requirements, the larger the value. The setting basis is the comparison of the current task's computational amount with that of the benchmark task;

[0119] : The total number of sampling points during the monitoring period is set to 5, representing that 5 data points are collected within the monitoring window;

[0120] : The weight coefficient of the input load of the gateway network interface is set to 0.6. This setting is based on data analysis. The input load fluctuation has a great impact on the gateway performance. This value can be adjusted according to the role of the gateway in the network;

[0121] : The weight coefficient of the output load of the gateway network interface is set to 0.4. This setting is complementary, reflecting the importance of the output load fluctuation. This value can be adjusted according to the role of the gateway in the network;

[0122] : The real-time input load value sequence is obtained by monitoring the input traffic of the gateway network interface at 5 consecutive sampling time points ( to ). The values are 95, 110, 105, 90, 100, with the unit of Mbps;

[0123] : The real-time output load value sequence is obtained by monitoring the output traffic of the gateway network interface at 5 consecutive sampling time points ( to The output flow rate is obtained as 70, 85, 80, 75, 90, with the unit of Mbps;

[0124] : The absolute change in the real-time security status identifier. The security status is quantified by predefined criteria: the status "normal" is quantified as 0, the status "minor alarm" is quantified as 1, and the status "major alarm" is quantified as 2. During the monitoring period, the security status changes from "normal" to "minor alarm", and its quantified value changes from 0 to 1;

[0125] Calculation process:

[0126] Calculate the average input load during the monitoring period :

[0127] ;

[0128] Calculate the average output load during the monitoring period:

[0129] ;

[0130] Calculate the absolute change in the quantified value of the security status:

[0131] : ;

[0132] Calculate at each sampling time point the weighted load deviation squared : t = 1: ;

[0133] t = 2: ;

[0134] t = 3: ;

[0135] t = 4: ;

[0136] t = 5: ;

[0137] Calculate the sum of the weighted load deviation squared:

[0138] ;

[0139] Calculate the value inside the square root:

[0140] ;

[0141] Calculate the load fluctuation index:

[0142] ;

[0143] The results show that the value of the load fluctuation index is 7.077. This value quantifies the weighted fluctuation degree of the input and output loads of the gateway interface during the monitoring period, and combines the changes in the security status and the impact of the adjustment of operation parameters. It is a key data point in the local probe execution and the load dataset, reflecting the comprehensive operation status characteristics of the gateway during the probe execution.

[0144] S403: Based on the local probe execution and the load dataset, converge the probe execution result parameters and the network interface load values, perform a joint inference operation process, quantify and evaluate the probability of anomalies and conflicts of the request operation in the real-time environment, and obtain a joint inference risk score;

[0145] Converge the probe execution result parameters and the network interface load values, that is, integrate the scattered data points into structured information, set and calculate key indicators such as the average CPU increment (such as 8%) during the probe execution, the peak memory increment (such as 20MB), the average network input load (such as 4.8MBps), the peak network input load (such as 5.2MBps), the average network output load (such as 0.08MBps), etc., and perform a joint inference operation process. This process compares the actual resource consumption during the probe execution (such as an 8% CPU increment, a bandwidth peak of 5.2MBps) with the theoretical resource requirement quantification indicators obtained from the request analysis in S401 (such as an estimated 10% CPU increase, an estimated bandwidth peak of 6MBps, which are pre-estimated values set for a simplified example and should actually come from the analysis in S401). At the same time, combined with the gateway real-time security status identifier (such as "standard") and performance data obtained in S402, use preset rules or a lightweight risk assessment model to make a judgment, quantify and evaluate the anomaly probability and conflict probability of the request operation in the current gateway real-time environment. The quantification of the anomaly probability can be based on the deviation degree between the actual consumption and the estimated consumption. If the actual CPU consumption far exceeds the estimate (such as exceeding 150% of the estimated value), the anomaly probability is set to "high" (such as 0.7). The quantification of the conflict probability considers the network load situation. If the monitored network peak load is close to or exceeds the channel capacity (judged in combination with the data in S101), or conflicts with the high-priority task scheduling (from the configuration in S203), the conflict probability is set to "medium" (such as 0.4). Set the risk score interval, set 0 - 0.3 as "low risk", 0.3 - 0.7 as "medium risk", and 0.7 - 1.0 as "high risk". Combine the quantified anomaly probability (such as 0.7) and conflict probability (such as 0.4) through weighted average (set the weights equal, each 0.5) or a risk calculation logic (such as taking the maximum value) to obtain a joint inference risk score, such as (0.7 + 0.4) / 2 = 0.55, belonging to the "medium risk" interval, and obtain a joint inference risk score.

[0146] The specific steps for obtaining the permission decision information are as follows:

[0147] S501: Using the combined inference risk score, call the interactive record data maintained by the requester gateway in the service provider's IoT gateway, extract the entries that match the remote control instruction type and data sharing request type, obtain the interaction identifier, occurrence timestamp, request type, and response time of the entries, and generate an interactive record set;

[0148] Call the interactive record data maintained by the requester gateway from the service provider's IoT gateway. During this process, input the identifier of the requester gateway (such as the device ID "GW_001") into the retrieval request of the gateway interface to match and query all interactive record entries in its storage log. This record entry contains multiple fields, including the interaction identifier (such as in UUID format), occurrence timestamp (such as "2025-03-20 14:23:56"), request type (such as "Remote control: Shutdown" or "Data sharing: Temperature data"), and response time (in milliseconds). To extract the entries that match the remote control instruction type and data sharing request type, first define a matching keyword library (such as keyword 1: Remote control, keyword 2: Data sharing), and then match the keywords with the request type field (such as using the pandas library in Python to filter the eligible records through df[df['Request type'].str.contains('Remote control|Data sharing')]), and perform a field extraction operation on the filtered records. For example, extracting the timestamp field can be converted into a UNIX time value for unified time comparison processing (such as "2025-03-20 14:23:56" corresponds to the timestamp 1742768636), and the response time field can be used for subsequent classification processing. The system constructs the above extraction results into an interactive record set in a standard structure. For example, if the record is: interaction identifier "abc123", timestamp "1742768636", request type "Data sharing: Temperature and humidity data", response time "153ms", generate an interactive record set.

[0149] S502: For multiple records in the interactive record set, based on the response time and the status identifier information of the records, distinguish the types of successfully completed events, response events, failed events, and negative impact events, integrate the record classification information and the recency quantification index, and obtain the permission decision information;

[0150] Distinguish different types of events based on the response time and the recorded status identification information. For this purpose, a response time threshold is defined. From the statistical analysis of empirical data, the normal response time range is set to 100ms to 300ms (set based on the service response benchmark of the IoT platform). Among them, events with a response time lower than 100ms can be determined as excellent response events, and those higher than 300ms are regarded as potential failure events. Then, combined with the recorded status identification field (such as "200OK" is regarded as successful, and "408Timeout" is regarded as failed), a preliminary classification of events is carried out. The corresponding formula can be expressed as: Event type = f(response time, status identification), where the f function is implemented based on interval judgment and condition matching. The specific interval settings are as follows: If the response time ≤ 100ms and the status identification is a success type (such as "200", "202"), it is determined as a "response event"; if the response time is in the interval [100ms, 300ms] and the status is successful, it is a "successful completion event"; if the status identification is a failure type (such as "4xx" or "5xx"), it is a "failure event"; if the status identification is successful but the response time > 500ms, and subsequent event records such as user cancellation instructions and exceptions occur, it is determined as a "negative impact event". After integrating and classifying, classification labels are assigned to the event records. Further, a quantitative index of the recency of the record needs to be considered. The calculation method is the current time minus the occurrence timestamp of the record, obtaining a time difference (for example, if the current time is 1742788636 seconds, it differs from the record timestamp 1742768636 by 20000 seconds). This time difference is standardized in hours (20000s ≈ 5.56 hours), and a reciprocal model is used for quantitative scoring. The formula is: Recency score = 1 / (1 + time difference / 3600), that is, the score of this record is 1 / (1 + 5.56) ≈ 0.152. The higher the recency, the closer the score is to 1. Combine the classification of interactive record events and the recency score to provide an input basis for subsequent dynamic risk calculation and obtain permission decision information.

[0151] Please refer to Figure 2 , the control system of the IoT gateway based on AI computing power, the system includes:

[0152] The protocol monitoring module obtains the protocol channel signal strength value, noise floor level value, and channel occupancy time ratio value within the working frequency band of the IoT gateway. According to the frequency band division principle, the channel is divided into multiple adjacent frequency intervals, and a cross-protocol interference impact mapping is obtained by comparing and analyzing the frequency band to which the protocol belongs and the noise floor level value.

[0153] The interference mapping module calls the cross-protocol interference impact mapping, selects the access request protocol identifier initiated by the real-time gateway and the alternative protocol set, evaluates the corresponding adjacent frequency interference mapping relationship, and obtains the optimal protocol scheduling configuration.

[0154] Based on the optimized protocol scheduling configuration, the strategy deduction module reorganizes the allocation of candidate protocol combinations in the network topology structure, performs cumulative calculations based on the channel interference impact and transmission density coefficient corresponding to each combination, screens out the combinations that meet the conditions, and obtains the encapsulated permission delegation request;

[0155] The task evaluation module calls the encapsulated permission delegation request, obtains the operation type identifier and target device category identifier that the IoT gateway needs to execute in real time, matches the resources occupied by the protocols in the combination, and generates a combined inference risk score;

[0156] The permission determination module makes a comparison and judgment based on the combined inference risk score according to the request completion time tolerance interval and response time threshold interval set in the access control list, determines whether the interaction meets the authorization conditions, and performs a combined classification on the above judgment results to obtain the permission decision information.

[0157] As described above, it is only the specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any person skilled in the art within the technical scope disclosed by the present invention can easily think of changes or substitutions, which should all be covered by the protection scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims

1. Control method for an Internet of Things gateway based on AI computing power, characterized in that, It includes the following steps: S1: Obtain the real-time signal strength, noise floor level, and channel occupancy time ratio data of the protocol channels within the working frequency band of the IoT gateway, conduct correlation analysis, analyze the corresponding changes in the number of retransmissions of devices on adjacent frequencies for the target protocol, and obtain the cross-protocol interference impact mapping; S2: Invoke the cross-protocol interference impact mapping, conduct simulation deduction on the protocol allocation combination for the IoT gateway device access request and communication quality adjustment requirements, analyze the interference degree among IoT gateways in the network under the protocol allocation combination, and obtain the optimized protocol scheduling configuration; S3: Adopt the optimized protocol scheduling configuration, evaluate the consumption of the local computing unit and network bandwidth according to the operation type and target device category identifier that the IoT gateway needs to invoke, combine the local network load status and the CPU occupancy rate range of the requesting gateway, encapsulate the request information, and obtain the encapsulated permission delegation request; S4: According to the encapsulated permission delegation request, initiate federated interaction, design a computing task probe based on the AI computing power and send it to the requesting party. The requesting party invokes the local sensor ID, operation parameters, and security status to execute the probe, conduct joint inference, and generate a joint inference risk score.

2. The control method of the Internet of Things gateway based on AI computing power according to claim 1, characterized in that The cross-protocol interference impact mapping includes interference sensitivity, frequency band overlap rate, and interference intensity change trend. The optimized protocol scheduling configuration includes protocol conflict probability, spectrum utilization efficiency, and expected network stability. The encapsulated permission delegation request includes resource demand assessment results, network bandwidth demand assessment information, local network load threshold, and gateway CPU threshold range. The joint inference risk score includes sensor operation risk, network interface overload risk, and joint inference credibility.

3. The control method of the Internet of Things gateway based on AI computing power according to claim 1, characterized in that, The specific steps for obtaining the cross-protocol interference impact mapping are as follows: S101: Obtain the real-time signal strength, noise floor level, and channel occupancy time ratio data of the protocol channels within the working frequency band of the IoT gateway, monitor the protocol type, connection request time point, cumulative number of successful data transmissions, and cumulative number of data retransmissions of the devices managed by the gateway, and generate a real-time channel and device status data set; S102: Invoke the real-time channel and device status data set, screen the data records of the target protocol and the activity data of devices on adjacent frequencies, calculate the correlation coefficient between the data transmission activity time series of the target protocol devices and the data retransmission number time series of adjacent frequency devices, and obtain the adjacent frequency retransmission association metric; S103: Based on the adjacent frequency retransmission association metric, extract the channel occupancy time ratio value and signal strength value, determine the interference impact degree of different protocol combinations under the conditions of channel occupancy and signal strength, evaluate the interference relationship and impact degree among multiple protocols, and establish a cross-protocol interference impact mapping.

4. The control method of the Internet of Things gateway based on AI computing power according to claim 2, wherein, The specific steps for obtaining the optimized protocol scheduling configuration are as follows: S201: Invoke the cross-protocol interference impact mapping, combine the IoT gateway device access request type and communication quality adjustment target, conduct multiple protocol allocation combinations, conduct simulation deduction on the protocol allocation combination, and obtain the simulated protocol allocation result; S202: Based on the simulation protocol allocation results, summarize the interference values among IoT gateways in the network under multiple scenarios, calculate the overall network interference level, and estimate the expected total network throughput value and the expected number of conflict occurrences corresponding to the protocol allocation combination according to the simulated communication interaction process and interference level, and establish a protocol combination effectiveness metric set; S203: According to the protocol combination effectiveness metric set, compare the network interference level, the expected total network throughput value, and the expected number of conflict occurrences of different protocol allocation combinations, and obtain an optimized protocol scheduling configuration based on the preset optimization target weights.

5. The control method of the Internet of Things gateway based on AI computing power according to claim 4, wherein, The specific steps for obtaining the encapsulated permission delegation request are as follows: S301: Invoke the optimized protocol scheduling configuration, calculate the estimated consumption of local computing units and the estimated consumption of network bandwidth required for the operation according to the operation type and target device category identifier that the IoT gateway needs to execute, and obtain a resource consumption evaluation value; S302: Use the resource consumption evaluation value to read the CPU occupancy rate range of the requesting gateway, invoke the resource consumption evaluation value, compare and calculate the resource requirements with the real-time IoT gateway status, and generate a request execution condition set; The formula for comparing and calculating the resource requirements with the real-time IoT gateway status is as follows: ； Among them, represents the gateway load index, represents the number of gateway status indicators for real-time monitoring, represents the index of the gateway status indicator, represents the weight of the th gateway status indicator, represents the real-time value of the th gateway status indicator, represents the benchmark value of the gateway processing capacity, represents the evaluation value of the resource requirements of real-time requests, represents the evaluation value of the real-time available resources of the gateway, represents the priority factor of real-time requests, represents the standard deviation of multiple load indicators within the gateway time period; S303: Based on the request execution condition set, select the parameters that meet the conditions, combine the scheduling instructions in the optimized protocol scheduling configuration, organize the information in a predetermined format, and combine the operation type, target identifier, resource requirements, and scheduling request to obtain an encapsulated permission delegation request.

6. The control method of the Internet of Things gateway based on AI computing power according to claim 5, characterized in that, The specific steps for obtaining the joint inference risk score are as follows: S401: According to the operation type and target device information included in the encapsulated permission delegation request, initiate a federated interaction process, analyze the quantitative index of the request for AI computing power resources, design a computing task probe including target operation instructions and data interaction specifications based on the quantitative index, and send the probe data packet to the requesting IoT gateway to obtain computing task probe data; S402: Use the computing task probe data to invoke the local sensor ID list, the corresponding operation parameter set, and the real-time security status identifier, execute the operation instruction sequence included in the probe, and monitor the real-time input / output load value of the gateway network interface during the execution to obtain a local probe execution and load data set; S403: Based on the local probe execution and load data set, converge the probe execution result parameters and the network interface load value, perform joint inference operation processing, quantitatively evaluate the probability of anomalies and conflicts of the request operation in the real-time environment, and obtain a joint inference risk score.

7. The control method of the Internet of Things gateway based on AI computing power according to claim 6, characterized in that, The formula for monitoring the real-time input / output load value of the gateway network interface during the execution is as follows: ； Among them, represents the load fluctuation index, represents the adjustment factor, represents the total number of sampling points during the monitoring period, represents the sampling time point index, represents the weight coefficient of the input load of the gateway network interface, represents at the sampling time point the real-time input load value, represents the average value of the input load values during the monitoring period, represents the weight coefficient of the output load of the gateway network interface, represents at the sampling time point the real-time output load value, represents the average value of the output load values during the monitoring period, represents the absolute change amount of the corresponding value of the real-time security status identifier during the monitoring period.

8. The control method of the Internet of Things gateway based on AI computing power according to claim 1, characterized in that The method further includes step S5: S5: According to the joint inference risk score, refer to the interaction record of the requesting gateway maintained by the service-side IoT gateway, extract the interaction identifiers, timestamps, request types, and response times of remote control instructions and data sharing requests, identify the successful completion, response events, and failure and negative event impacts in the interaction record, and obtain permission decision information with reference to the recency of the interaction occurrence time. The permission decision information includes the interactive trust level, the evaluation result of interactive timeliness, and the negative interaction weight.

9. The control method of the Internet of Things gateway based on AI computing power according to claim 8, characterized in that, The specific steps for obtaining the permission decision information are as follows: S501: Using the combined inference risk score, call the interactive record data maintained by the service provider's Internet of Things gateway for the requester gateway, extract the entries matching the remote control instruction type and data sharing request type, obtain the interactive identifier, occurrence timestamp, request type, and response time of the entries, and generate an interactive record set; S502: For multiple records in the interactive record set, distinguish the types of successful completion events, response events, failure events, and negative impact events based on the response time and the status identification information of the records, integrate the record classification information and the recency quantification index, and obtain the permission decision information.

10. The control system of the Internet of Things gateway based on AI computing power is characterized in that, The system is used to implement the control method of the Internet of Things gateway based on AI computing power according to any one of claims 1-9. The system includes: The protocol monitoring module obtains the protocol channel signal strength value, noise floor level value, and channel occupancy time ratio value within the working frequency band of the Internet of Things gateway, divides the channel into multiple adjacent frequency intervals according to the frequency band division principle, and performs a comparison analysis by combining the frequency band to which the protocol belongs and the noise floor level value to obtain a cross-protocol interference impact mapping; The interference mapping module calls the cross-protocol interference impact mapping, selects the access request protocol identifier initiated by the real-time gateway and the alternative protocol set, evaluates the corresponding adjacent frequency interference mapping relationship, and obtains the preferred protocol scheduling configuration; The strategy deduction module reorganizes the allocation of candidate protocol combinations in the network topology structure according to the preferred protocol scheduling configuration, performs cumulative calculations based on the channel interference impact and transmission density coefficient corresponding to each combination, screens the combinations that meet the conditions, and obtains the encapsulated permission delegation request; The task evaluation module calls the encapsulated permission delegation request, obtains the operation type identifier and target device category identifier that the Internet of Things gateway needs to execute in real time, matches the protocol occupied resources in the combination, and generates a combined inference risk score; The permission determination module makes a comparison judgment according to the combined inference risk score based on the request completion time tolerance interval and response time threshold interval set in the access control list, determines whether the interaction meets the authorization conditions, and performs a combined classification on the above judgment results to obtain the permission decision information.

Images