A dynamic stable pairing method and system of sensor and gateway

Abstract

The application relates to the technical field of Internet of Things, and discloses a dynamic stable pairing method for sensors and gateways, which comprises the following steps: step 1: obtaining the relevant information of all the sensors to be paired and all the available gateways; calculating gateway evaluation data and sensor evaluation data; step 2: according to the gateway evaluation data, corresponding first weights, the sensor evaluation data and corresponding second weights, the evaluation scores of each sensor to different gateways and the evaluation scores of each gateway to different sensors are calculated through a multi-criteria decision model; step 3: constructing a preference list of each sensor and a preference list of each gateway; step 4: according to the preference list of each sensor and the preference list of each gateway, an improved delayed reception algorithm is adopted to generate a stable pairing scheme; and step 5: according to the stable pairing scheme, the sensors and the corresponding gateways establish network connection. Meanwhile, a dynamic stable pairing system for sensors and gateways is also disclosed.

Description

Technical Field

[0001] This application belongs to the field of Internet of Things (IoT) technology, and more specifically, relates to a dynamic and stable pairing method and system for sensors and gateways. Background Technology

[0002] With the widespread application of IoT technology in the elevator industry, modern large-scale smart buildings typically deploy multiple elevators, each integrating a wide variety of sensors, including vibration sensors, temperature sensors, door operator status sensors, cabin environmental parameter sensors, and high-bandwidth video analytics sensors. These sensors continuously generate massive amounts of data, which need to be aggregated and transmitted through multiple IoT gateways.

[0003] Existing elevator IoT systems face the following technical challenges in data transmission and connection management within multi-sensor and multi-gateway scenarios:

[0004] 1. Inefficient resource allocation: Existing systems mostly adopt static sensor-gateway connection strategies based on simple rules (such as proximity). This strategy cannot dynamically adapt to the addition or removal of sensors or gateways, failures, or changes in the network environment, resulting in some gateways being overloaded while other gateway resources are idle, seriously affecting the overall data transmission efficiency and stability of the system.

[0005] 2. Lack of Priority for Critical Data Transmission: Existing methods often struggle to effectively differentiate the operational priorities of data from different sensors. For example, elevator malfunction alarms or safety-related emergency data require far more real-time transmission than routine environmental monitoring data. Traditional methods cannot guarantee low-latency transmission of high-priority data, potentially delaying fault response and safety warnings.

[0006] 3. Difficulty in balancing the interests of multiple parties: In the complex IoT environment of elevators, sensors want to connect to the gateway with the best performance and lowest latency; while the gateway wants to connect to sensors that match its processing capacity and load, and prioritize processing high-value data. Existing methods struggle to achieve a balanced and stable pairing among these mutually constraining factors.

[0007] Therefore, the technical problem solved by this application is: how to achieve a balanced and stable pairing scheme between multiple sensors and multiple gateways. Summary of the Invention

[0008] The main objective of this application is to provide a dynamic and stable pairing method for sensors and gateways. This method involves calculating gateway evaluation data for the sensors and sensor evaluation data for the gateways, then obtaining evaluation scores based on a first weight and a second weight. A preference list is constructed based on these evaluation scores, and a pairing scheme is calculated using a delayed reception algorithm. This approach balances the needs of various sensors and gateways, thereby achieving a balanced and stable pairing state between multiple sensors and multiple gateways.

[0009] In addition, a dynamic and stable pairing system for sensors and gateways is also provided.

[0010] To achieve the above objectives, the technical solution adopted in this application is as follows:

[0011] A method for dynamically and stably pairing a sensor and a gateway includes the following steps:

[0012] Step 1: Obtain relevant information for all sensors to be paired and all available gateways; based on the relevant information for all sensors to be paired and all available gateways, calculate multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway.

[0013] Step 2: Assign corresponding first weights to the evaluation data of each gateway and corresponding second weights to the evaluation data of each sensor; calculate the evaluation score of each sensor for different gateways using a multi-criteria decision model based on the evaluation data of multiple gateways and the corresponding first weights; calculate the evaluation score of each gateway for different sensors using a multi-criteria decision model based on the evaluation data of multiple sensors and the corresponding second weights.

[0014] Step 3: Based on the evaluation scores of each sensor for different gateways, sort them in descending order according to the evaluation scores of different gateways to construct a preference list for each sensor; based on the evaluation scores of each gateway for different sensors, sort them in descending order according to the evaluation scores of different sensors to construct a preference list for each gateway.

[0015] Step 4: Based on the preference list of each sensor and the preference list of each gateway, use an improved delayed reception algorithm to generate relevant information of all sensors to be paired and a stable pairing scheme between all available gateways.

[0016] Step 5: According to the stable pairing scheme, send a pairing command to the sensor, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

[0017] Preferably, the relevant information of the sensor to be paired includes at least three of the following: sensor data type, communication protocol used by the sensor, RSSI value from the sensor to the gateway, data production rate, data real-time requirements, data service priority, data throughput requirements, requirements for gateway functions, and the physical location of the sensor.

[0018] The relevant information of the available gateways includes at least four of the following: CPU utilization, memory utilization, network bandwidth, current load status, currently available resources, supported communication protocols, supported data processing capabilities, physical location of the gateway, and coverage area.

[0019] Multiple gateway evaluation data include at least three of the following: sensor-to-gateway signal strength data, sensor-to-gateway communication distance data, gateway remaining load data, data on the match between the gateway's data processing capabilities and sensor requirements, and data on the gateway's support for sensor data types or communication protocols.

[0020] Multiple sensor evaluation data include at least three of the following: sensor data service priority data, sensor data throughput requirements matching the gateway's currently available resources data, sensor-to-gateway communication distance data, and the matching of the sensor's physical area with the gateway's coverage area data.

[0021] Preferably, in step 1, the signal strength data from the sensor to the gateway is calculated as follows: the RSSI value from the sensor to the gateway is the signal strength data from the sensor to the gateway.

[0022] The communication distance data between the sensor and the gateway is calculated as follows: based on the physical location of the sensor and the physical location of the gateway, the physical distance data between the sensor and the gateway is obtained.

[0023] The remaining load data of the gateway is calculated as follows: based on the current load status, the remaining load data of the gateway is calculated using the remaining load rate formula;

[0024] The method for calculating the matching degree data between the gateway's data processing capability and sensor requirements is as follows: Based on the data production rate and data real-time requirements, the sensor's processing requirement index is obtained; based on the CPU utilization and memory utilization, the gateway's processing capability index is obtained; based on the sensor's processing requirement index and the gateway's processing capability index, the matching degree formula is used to calculate the matching degree data between the gateway's data processing capability and sensor requirements.

[0025] The gateway's support for sensor data types or communication protocols is calculated as follows: based on the communication protocols used and supported by the sensor, the communication protocol support is calculated; based on the sensor data type and supported data processing capabilities, the data type support is calculated; and based on the communication protocol support and data type support, the gateway's support for sensor data types or communication protocols is calculated.

[0026] The data service priority data of the sensor is calculated as follows: based on the number of data service priority levels, the value of each level is assigned a corresponding value at intervals of 1 / number of levels, starting from 1; and then the data service priority data of the sensor is obtained according to the data service priority.

[0027] The matching degree data between the sensor's data throughput requirement and the gateway's currently available resources is calculated as follows: based on the data throughput requirement and the currently available resources, the matching degree formula is used to calculate the matching degree data between the sensor's data throughput requirement and the gateway's currently available resources.

[0028] The matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is calculated as follows: based on the physical location of the sensor and the physical location of the gateway, the spatial distance between the sensor and the gateway is calculated using the weighted Euclidean formula. Based on the spatial distance and the coverage area of ​​the gateway, the matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is calculated.

[0029] Preferably, the matching degree formula is: Where A represents the gateway's processing capacity or currently available resources, and B represents the sensor's processing requirements or data throughput requirements.

[0030] Preferably, step 2 includes the following steps:

[0031] Step A1: Assign corresponding initial first weights to multiple gateway evaluation data and assign corresponding initial second weights to multiple sensor evaluation data, wherein the sum of multiple initial first weights is 1 and the sum of multiple initial second weights is 1;

[0032] Step A2: Set the threshold values ​​for system status indicators related to gateway evaluation data and sensor evaluation data respectively, and obtain each system status indicator in real time. When any system status indicator related to gateway evaluation data or sensor evaluation data is greater than the corresponding system status indicator threshold, increase the initial first weight of the corresponding gateway evaluation data or the initial second weight of the sensor evaluation data by N. The initial first weight of the remaining gateway evaluation data or the initial second weight of the sensor evaluation data is adjusted according to the increase amount to obtain the first weight of all gateway evaluation data or the second weight of all sensor evaluation data. N ranges from 10 to 80, the sum of all first weights is 1, and the sum of all second weights is 1.

[0033] Step A3: Based on the evaluation data of multiple gateways and the corresponding first weights, calculate the evaluation score of each sensor for different gateways using a multi-criteria decision model; based on the evaluation data of multiple sensors and the corresponding second weights, calculate the evaluation score of each gateway for different sensors using a multi-criteria decision model.

[0034] Preferably, the multi-criteria decision model is as follows: Where n is the number of gateway evaluation data or sensor evaluation data selected. For normalization function, For gateway evaluation data or sensor evaluation data, For the corresponding first or second weight.

[0035] Preferably, step 4 includes the following steps:

[0036] Step B1: Allocate quotas to each gateway using the quota calculation formula and build a pre-pairing list for each gateway;

[0037] Step B2: Each sensor looks up its own preference list and sends a connection request to the gateway with the highest ranking that has not been rejected by the corresponding gateway.

[0038] Step B3: After receiving a sensor request, the gateway adds the sensor to the pre-pairing list. Then, according to the gateway's preference list, the sensors in the pre-pairing list are sorted to obtain a sensor candidate set. When the total number of sensors in the sensor candidate set is greater than the quota, the gateway rejects the sensors ranked after the quota in the sensor candidate set and removes them from the sensor candidate set.

[0039] Step B4: After receiving the rejection operation from the gateway, the sensor removes the gateway from the sensor's preference list, obtains a new sensor preference list, and replaces the old sensor preference list;

[0040] Step B5: Repeat steps B2 to B4 until the termination condition is met, generating a stable pairing scheme between all sensors to be paired and all available gateways.

[0041] Preferably, the method further includes step 6: after the sensor and gateway are paired, if one of the reconfiguration conditions is met, then steps 1 to 5 are repeated.

[0042] Reassignment conditions include:

[0043] (a) CPU utilization is greater than 85%, the RSSI value from sensor to gateway is less than -90dBm, a new gateway is added or the existing gateway is offline;

[0044] (ii) Recalculate the global preference score of the current pairing scheme at preset intervals to obtain the theoretical global preference score. When the theoretical global preference score is greater than 1.15 times the current global preference score.

[0045] In addition, a dynamic and stable pairing system for sensors and gateways is also provided to implement the aforementioned dynamic and stable pairing method for sensors and gateways, comprising the following units:

[0046] Information acquisition unit: used to acquire relevant information of all sensors to be paired and relevant information of all available gateways; based on the relevant information of all sensors to be paired and relevant information of all available gateways, calculate multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway.

[0047] The scoring calculation unit is used to assign corresponding first weights to the evaluation data of each gateway and corresponding second weights to the evaluation data of each sensor; based on the evaluation data of multiple gateways and the corresponding first weights, it calculates the evaluation score of each sensor for different gateways through a multi-criteria decision model; based on the evaluation data of multiple sensors and the corresponding second weights, it calculates the evaluation score of each gateway for different sensors through a multi-criteria decision model.

[0048] Preference list generation unit: used to construct a preference list for each sensor by sorting the evaluation scores of different gateways in descending order based on the evaluation scores of different gateways; and to construct a preference list for each gateway by sorting the evaluation scores of different sensors in descending order based on the evaluation scores of different gateways.

[0049] Pairing scheme generation unit: used to generate relevant information of all sensors to be paired and stable pairing schemes between all available gateways based on the preference list of each sensor and the preference list of each gateway, using an improved delayed reception algorithm;

[0050] Connection establishment unit: Used to send pairing commands to the sensor according to a stable pairing scheme, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

[0051] One of the above-mentioned technical solutions in this application has at least one of the following advantages or beneficial effects:

[0052] 1. Improved System Stability: By employing a stable matching algorithm, the pairing scheme meets mathematical stability requirements, reducing frequent connection changes caused by unilateral dissatisfaction. Compared to traditional static pairing methods based on simple rules, this invention reduces the "ping-pong handover" phenomenon between sensors and different gateways, lowers network signaling overhead, and improves the stability of data transmission links.

[0053] 2. Gateway Resource Utilization Efficiency Optimization: By comprehensively considering gateway load, processing capacity, and sensor requirements, and employing a multi-criteria decision-making model and dynamic weight adjustment mechanism, a balanced allocation of gateway resources can be achieved. Compared to traditional methods, this invention reduces instances of gateway overload or resource idleness, thereby improving the utilization efficiency of network and computing resources.

[0054] 3. Ensuring Real-Time Performance of Critical Data: By incorporating a business priority evaluation factor for sensor data into the gateway preference list construction, the gateway can prioritize processing high-priority data (such as emergency alarms and fault signals). Compared to traditional methods, this invention reduces the transmission latency of critical data and improves the timeliness of elevator safety warnings and fault responses.

[0055] 4. Improved Rationality and Predictability of Pairing Schemes: Compared to traditional greedy algorithms or heuristic rules, stable matching algorithms have a rigorous mathematical foundation and can better balance the needs of both the sensor and the gateway. This invention improves the overall rationality and predictability of pairing through a multi-criteria decision model and dynamic weight adjustment, making the pairing results more stable and reliable.

[0056] 5. Enhanced High-Concurrency Access Capability: By introducing a gateway capacity quota mechanism, this invention supports the orderly access of massive numbers of sensors in a multi-gateway environment. The quota mechanism dynamically calculates based on the actual processing capacity and resource constraints of the gateway, effectively avoiding signaling storms or data congestion caused by too many access devices on a single gateway. Attached Figure Description

[0057] The present application will be further described below with reference to the accompanying drawings and embodiments;

[0058] Figure 1 This is a flowchart of the dynamic and stable pairing method between the sensor and the gateway in Example 1;

[0059] Figure 2 This is a block diagram of the dynamic and stable pairing system of the sensor and gateway in Example 2. Detailed Implementation

[0060] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0061] The following disclosure provides many different implementation methods or examples for different schemes of implementing this application.

[0062] refer to Figure 1 A method for dynamically and stably pairing a sensor with a gateway includes the following steps:

[0063] Step 1: Obtain relevant information for all sensors to be paired and all available gateways; based on the relevant information for all sensors to be paired and all available gateways, calculate multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway.

[0064] In this embodiment, based on the elevator system settings, relevant sensor information and gateway information are obtained, and then gateway evaluation data and sensor evaluation data are calculated based on the relevant information.

[0065] Sensors are deployed in multiple elevators (elevator 1, elevator 2, elevator 3... elevator M) of the building, and each elevator is equipped with multiple types of sensors, including:

[0066] Vibration sensor: Real-time detection of vibration frequency and amplitude during elevator operation;

[0067] Door operator status sensor: monitors the opening and closing status of the elevator door, the opening and closing time, and the door lock status;

[0068] Video analytics sensors: provide video monitoring inside the car, supporting intelligent analysis functions such as personnel counting and abnormal behavior recognition;

[0069] Car environment sensor: monitors environmental parameters such as temperature, humidity, and air quality inside the car;

[0070] Load sensor: detects the current load on the car in real time;

[0071] Operating speed sensor: Monitors the elevator's real-time operating speed and acceleration changes.

[0072] The gateway consists of multiple IoT gateways (Gateway 1, Gateway 2, Gateway 3... Gateway N) distributed in different locations within the building. The main functions of the gateway include:

[0073] Data aggregation: Receives and aggregates data streams from multiple sensors;

[0074] Protocol conversion: Converting the communication protocols used by different sensors (such as Zigbee, LoRa, Wi-Fi, etc.) into a unified uplink protocol;

[0075] Data preprocessing: Filtering, compressing, and performing preliminary analysis on the raw sensor data;

[0076] Edge computing: Possesses certain edge computing capabilities, enabling it to complete some data processing tasks locally, thus reducing the burden on the cloud.

[0077] Preferably, the relevant information of the sensor to be paired includes at least three of the following: sensor data type, communication protocol used by the sensor, RSSI value from the sensor to the gateway, data production rate, data real-time requirements, data service priority, data throughput requirements, requirements for gateway functions, and the physical location of the sensor.

[0078] In this embodiment, the relevant information of the sensor to be paired includes the sensor data type, the communication protocol used by the sensor, the RSSI value from the sensor to the gateway, the data production rate, the data real-time requirements, the data service priority, the data throughput requirements, the requirements for gateway functions, and the physical location of the sensor. The above data is determined in the early stage of elevator system design.

[0079] It should be noted that:

[0080] Based on the security importance, real-time requirements, and business impact of data in the elevator IoT system, data service priorities are divided into five levels:

[0081] Level 1: Critical (Emergency Critical Level): 1. Elevator entrapment alarm: Entrapment caused by emergency button triggering in the car or door lock malfunction; 2. Safety protection trigger: Overspeed protection, limit switch triggering, safety brake activation; 3. Fire linkage signal: Elevator emergency landing triggered by fire protection system linkage or smoke alarm; 4. Earthquake detection signal: Emergency elevator stop triggered by earthquake sensor; 5. Real-time requirement: ≤ 100ms; 6. Data loss tolerance: 0% (absolutely no data loss allowed);

[0082] Level 2: High (High Priority): 1. Fault Warning Signals: Warnings for abnormal vibration, excessive temperature, abnormal current, etc.; 2. Door Operator Abnormal Status: Door opening / closing timeout, door lock malfunction, light curtain obstruction; 3. Overload Alarm: Car load exceeds rated value; 4. Operational Abnormality Detection: Abnormal speed, abnormal acceleration, abnormal leveling accuracy; 5. Real-time Requirement: ≤ 500ms; 6. Data Loss Tolerance: ≤ 1%;

[0083] Level 3: Medium (Medium Priority): 1. Operational Status Monitoring: Floor location, direction of travel, door open / close status; 2. Performance Parameter Collection: Number of runs, running time, energy consumption statistics; 3. Maintenance Reminders: Lubricant replacement reminders, component life warnings; 4. Passenger Flow Statistics: Number of passengers in the car, frequency of floor calls; 5. Real-time Requirements: ≤ 2 seconds; 6. Data Loss Tolerance: ≤ 5%;

[0084] Level 4: Low Priority: 1. Environmental Parameter Monitoring: Temperature, humidity, and air quality inside the car; 2. Equipment Health Assessment: Assessment of component wear and lubrication status; 3. Historical Data Statistics: Monthly operation reports and annual maintenance records; 4. Energy Saving Optimization Data: Standby power consumption and operating efficiency analysis; 5. Real-time Requirements: ≤ 10 seconds; 6. Data Loss Tolerance: ≤ 10%;

[0085] Level 5: Info (Information Level) 1. System Log Information: Device start / stop records, parameter configuration changes; 2. Debugging and Diagnostic Data: System self-test results, communication link tests; 3. Statistical Analysis Data: Long-term trend analysis, big data mining raw materials; 4. Backup and Synchronization Data: Configuration file backup, historical data archiving; 5. Real-time Requirements: ≤ 60 seconds; 6. Data Loss Tolerance: ≤ 20%.

[0086] The requirements for gateway functionality include:

[0087] Edge computing capability requirements: 1. AI inference processing: Video analysis sensors require gateways with GPUs or NPUs to support face recognition and behavior analysis; 2. Signal processing algorithms: Vibration sensors require gateways to support FFT transformation and spectrum analysis; 3. Data fusion computing: Multi-sensor data requires gateways to perform Kalman filtering and data association; 4. Real-time control logic: Safety loop sensors require gateways to support PLC-level real-time control.

[0088] Data preprocessing capabilities required: 1. Data compression: High-frequency sampling sensors require gateway support for lossless or lossy compression algorithms; 2. Data filtering: Sensors with high noise levels require gateway support for digital filtering and outlier detection; 3. Data aggregation: Multi-point temperature sensors require gateway support for statistical aggregation and trend calculation; 4. Format conversion: Heterogeneous sensors require gateway support for standardized conversion of various data formats.

[0089] Wireless communication protocol support requirements: 1. LoRa / LoRaWAN: The preferred protocol for long-range (10-15km) and low-power sensors; 2. Zigbee 3.0: The standard protocol for smart sensor networks, based on IEEE 802.15.4; 3. Wi-Fi 6 / 6E: The preferred protocol for high-bandwidth applications (such as video sensors and real-time data analysis); 4. Bluetooth 5.0 / BLE: A short-range (up to about 50 meters) and low-power device connectivity protocol; 5. NB-IoT / Cat-M1: A cellular LPWAN protocol for wide area network connectivity, with NB-IoT offering lower power consumption and Cat-M1 supporting higher bandwidth and mobility.

[0090] Wired communication protocol support requirements: 1. Modbus RTU / TCP: Standard protocol for industrial sensors; 2. CAN Bus: Dedicated protocol for elevator control systems; 3. Ethernet / IP: High-speed industrial Ethernet protocol; 4. RS485 / RS232: Traditional serial communication protocols;

[0091] Protocol conversion capability requirements: 1. Multi-protocol gateway: Supports conversion of more than 3 wireless protocols simultaneously; 2. Protocol bridging: Data bridging capability between different protocol families; 3. Protocol adaptation: Supports parsing and adaptation of custom protocols;

[0092] Local storage requirements: 1. Real-time caching: ≥ 1GB RAM, supporting real-time caching of high-frequency data; 2. Historical storage: ≥ 32GB Flash, supporting local storage of data when the network is offline; 3. Database functionality: Supports SQLite or time-series databases for easy data querying and management.

[0093] Data synchronization requirements: 1. Resume interrupted transmission: Automatically synchronize cached data after network recovery; 2. Incremental synchronization: Only transmit changed data to reduce bandwidth usage; 3. Data deduplication: Avoid storing and transmitting duplicate data.

[0094] Data security requirements: 1. Encrypted transmission: Supports encryption standards such as AES-256 and TLS 1.3; 2. Digital signature: Supports data integrity verification and tamper prevention; 3. Access control: Supports role-based access control (RBAC).

[0095] Device authentication requirements: 1. Two-way authentication: mutual authentication between the gateway and the sensor; 2. Certificate management: support for the generation, distribution and updating of X.509 certificates; 3. Secure boot: support for trusted boot and firmware integrity verification;

[0096] Remote management requirements: 1. OTA upgrade: Support remote upgrade of gateway firmware and sensor firmware; 2. Remote configuration: Support remote distribution and activation of parameter configurations; 3. Remote diagnostics: Support remote monitoring of gateway status and fault diagnosis.

[0097] Monitoring and alarm requirements: 1. Health monitoring: Real-time monitoring of the gateway's CPU, memory, temperature, and other statuses; 2. Anomaly alarms: Proactive alarms for abnormal situations such as device failures and communication interruptions; 3. Performance statistics: Statistics on performance indicators such as data throughput, latency, and packet loss rate.

[0098] The relevant information of the available gateways includes at least four of the following: CPU utilization, memory utilization, network bandwidth, current load status, currently available resources, supported communication protocols, supported data processing capabilities, physical location of the gateway, and coverage area.

[0099] In this embodiment, the available gateway information includes CPU utilization, memory utilization, network bandwidth, current load status, currently available resources, supported communication protocols, supported data processing capabilities, and the gateway's physical location and coverage area. The CPU utilization, memory utilization, network bandwidth, supported communication protocols, gateway's physical location, and coverage area can be directly obtained from the gateway's API interface or gateway model.

[0100] It should be noted that:

[0101] The gateway's current load status is a comprehensive indicator reflecting its resource usage in terms of CPU, memory, network, and the number of connected sensors. The calculation formula is:

[0102] .

[0103] in, , CPU load, For memory load, For network load, For connecting load.

[0104] CPU load can be obtained in the following ways: 1. via the / proc / stat file (Linux systems); 2. via SNMP protocol (network devices); 3. via gateway management interface;

[0105] Memory load is obtained via SNMP;

[0106] The network load is obtained by acquiring network interface statistics and then calculating the current network utilization.

[0107] The connection load is obtained by: obtaining the number of currently connected sensors, obtaining the gateway's maximum connection quota, and dividing the number of currently connected sensors by the gateway's maximum connection quota.

[0108] The gateway's currently available resources refer to the resource capacity that the gateway can still allocate to new sensors under its current load conditions, including:

[0109] CPU available resources:

[0110] def get_available_cpu_resource(gateway_id):

[0111] current_cpu_usage = get_cpu_load(gateway_id)

[0112] # Reserve 10% of CPU resources for system overhead.

[0113] max_usable_cpu = 0.90

[0114] # Calculate available CPU resources

[0115] available_cpu = max_usable_cpu - current_cpu_usage

[0116] # Convert to the number of supported sensors

[0117] avg_cpu_per_sensor = get_average_cpu_per_sensor(gateway_id)

[0118] available_sensor_count_cpu = available_cpu / avg_cpu_per_sensor

[0119] return max(available_sensor_count_cpu, 0)

[0120] Available memory resources:

[0121] def get_available_memory_resource(gateway_id):

[0122] memory_info = psutil.virtual_memory()

[0123] # Available memory (bytes)

[0124] available_memory_bytes = memory_info.available

[0125] # Reserve 512MB of memory for system operation

[0126] reserved_memory = 512 * 1024 * 1024

[0127] usable_memory = available_memory_bytes - reserved_memory

[0128] # Average memory usage per sensor

[0129] avg_memory_per_sensor = get_average_memory_per_sensor(gateway_id)

[0130] available_sensor_count_mem = usable_memory / avg_memory_per_sensor

[0131] return max(available_sensor_count_mem, 0)

[0132] Available bandwidth resources:

[0133] def get_available_bandwidth_resource(gateway_id):

[0134] # Get the maximum bandwidth of the network interface

[0135] max_bandwidth = get_interface_max_bandwidth(gateway_id)

[0136] # Get current bandwidth usage

[0137] current_usage = get_current_bandwidth_usage(gateway_id)

[0138] # Reserve 20% bandwidth for control signaling and system communication

[0139] reserved_bandwidth = max_bandwidth * 0.20

[0140] # Calculate available bandwidth

[0141] available_bandwidth = max_bandwidth - current_usage - reserved_bandwidth

[0142] # Average bandwidth required per sensor

[0143] avg_bandwidth_per_sensor = get_average_bandwidth_per_sensor(gateway_id)

[0144] available_sensor_count_bw = available_bandwidth / avg_bandwidth_per_sensor

[0145] return max(available_sensor_count_bw, 0)

[0146] Available resources for connection count:

[0147] def get_available_connection_resource(gateway_id):

[0148] # Get the gateway's maximum connection quota

[0149] max_connections = get_gateway_quota(gateway_id)

[0150] # Get the number of currently connected sensors

[0151] current_connections = len(get_connected_sensors(gateway_id))

[0152] # Calculate the number of available connections

[0153] available_connections = max_connections - current_connections

[0154] return max(available_connections, 0)

[0155] Multiple gateway evaluation data include at least three of the following: sensor-to-gateway signal strength data, sensor-to-gateway communication distance data, gateway remaining load data, data on the match between the gateway's data processing capabilities and sensor requirements, and data on the gateway's support for sensor data types or communication protocols.

[0156] The signal strength data from the sensor to the gateway is calculated as follows: the RSSI value from the sensor to the gateway is the signal strength data from the sensor to the gateway.

[0157] The communication distance data between the sensor and the gateway is calculated as follows: based on the physical location of the sensor and the physical location of the gateway, the physical distance data between the sensor and the gateway is obtained.

[0158] The spatial coordinates of the sensor and the gateway are obtained, and the communication distance between the sensor and the gateway is calculated using the weighted Euclidean algorithm. The weighted Euclidean algorithm is as follows:

[0159] .

[0160] in, , and These are the coordinates of the gateway. , and These are the coordinate data of the sensors. For the weight of the X-axis coordinate, As the weight of the Y-axis coordinate, The weight of the Z-axis coordinate. (Low resistance to horizontal propagation) (The vertical direction requires passing through the floor slab, resulting in greater signal attenuation).

[0161] The remaining load data of the gateway is calculated as follows: based on the current load status, the remaining load data of the gateway is calculated using the remaining load rate formula;

[0162] The formula for calculating the remaining load data of the gateway is: ,in Gateway The current load, with a value range of [0,1].

[0163] The method for calculating the matching degree data between the gateway's data processing capability and sensor requirements is as follows: Based on the data production rate and data real-time requirements, the sensor's processing requirement index is obtained; based on the CPU utilization and memory utilization, the gateway's processing capability index is obtained; based on the sensor's processing requirement index and the gateway's processing capability index, the matching degree formula is used to calculate the matching degree data between the gateway's data processing capability and sensor requirements.

[0164] Among them, sensor processing requirements indicators It is a quantitative indicator that comprehensively evaluates the sensor's requirements for gateway processing capabilities, mainly calculated based on data production rate and data real-time requirements:

[0165] .

[0166] in: ,and Normal settings: (Data rate weight) (Real-time weight) (Complexity weight) The normalized data production rate To meet the real-time requirements of the normalized data, This represents the processing complexity of the data after normalization.

[0167] It should be noted that:

[0168] Data production rate grading is defined as follows:

[0169] rate_levels = {

[0170] 'low': 10, # ≤ 10 KB / s, such as temperature sensors

[0171] 'medium': 100, # ≤ 100 KB / s, such as vibration sensors

[0172] 'high': 1000, # ≤ 1000 KB / s, such as audio sensors

[0173] 'ultra': 10000 #>1000 KB / s, such as a video sensor}

[0174] Data real-time requirements are defined as: latency_levels = {

[0175] 'critical': 100, # ≤ 100ms, emergency alarm type

[0176] 'high': 500, # ≤ 500ms, fault warning type

[0177] 'medium': 2000, # ≤ 2s, Status monitoring class

[0178] 'low': 10000, # ≤ 10s, Environmental monitoring category

[0179] 'info': 60000 # ≤ 60s, log statistics class}

[0180] The data processing complexity is defined as follows: 1. Simple numerical processing, complexity 0.1; 2. Numerical processing + calibration, complexity 0.15; 3. FFT transformation + spectrum analysis, complexity 0.4; 4. Audio processing + feature extraction, complexity 0.5; 5. State logic judgment, complexity 0.2; 6. Load calculation + security check, complexity 0.25; 7. Video decoding + AI inference, complexity 0.8; 8. Point cloud processing + 3D reconstruction, complexity 0.7; 9. Logical judgment + priority processing, complexity 0.3.

[0181] Gateway processing capacity indicators It is a quantitative indicator that comprehensively evaluates the gateway's processing performance, mainly based on CPU utilization, memory utilization, and hardware configuration.

[0182] .

[0183] in: ,and Normal settings: (CPU weight) (Memory weight) (Hardware configuration weight) This represents the normalized CPU utilization rate. This represents the normalized memory utilization rate. This is the hardware configuration data after normalization.

[0184] The normalized hardware configuration data is obtained as follows:

[0185] def calculate_hardware_performance(gateway):

[0186] Computing gateway hardware overall performance indicators

[0187] # Get hardware configuration information

[0188] cpu_cores = gateway.cpu_cores

[0189] cpu_frequency = gateway.cpu_frequency_mhz

[0190] has_gpu = gateway.has_gpu

[0191] has_npu = gateway.has_npu # Neural Processing Unit

[0192] storage_type = gateway.storage_type # eMMC, SSD, NVMe

[0193] network_capability = gateway.max_network_speed_mbps

[0194] # CPU core count and frequency rating

[0195] cpu_score = min((cpu_cores * cpu_frequency) / (4 * 2000), 1.0) # Based on 4 cores and 2GHz

[0196] # Dedicated processing unit bonus

[0197] accelerator_bonus = 0

[0198] if has_gpu:accelerator_bonus += 0.3 # GPU acceleration

[0199] if has_npu:accelerator_bonus += 0.2 # Accelerate AI inference

[0200] # Storage performance rating

[0201] storage_performance = {

[0202] 'eMMC': 0.3,

[0203] 'SSD': 0.7,

[0204] 'NVMe': 1.0

[0205] storage_score = storage_performance.get(storage_type, 0.5)

[0206] # Network Ability Score

[0207] network_levels = {

[0208] 'fast_ethernet': 100, # 100Mbps

[0209] 'gigabit': 1000, # 1Gbps

[0210] 'multi_gig': 10000 # 10Gbps+}

[0211] network_score = min(network_capability / network_levels['multi_gig'], 1.0)

[0212] The matching degree between the gateway's data processing capabilities and the sensor's requirements is calculated using a matching degree formula, specifically: Where A represents the gateway's processing capacity and B represents the sensor's processing requirements.

[0213] All normalization processes are MIN-MAX normalization. Since the following steps or existing technologies provide detailed explanations of MIN-MAX normalization, they will not be described in detail here.

[0214] The gateway's support for sensor data types or communication protocols is calculated as follows: based on the communication protocols used and supported by the sensor, the communication protocol support is calculated; based on the sensor data type and supported data processing capabilities, the data type support is calculated; and based on the communication protocol support and data type support, the gateway's support for sensor data types or communication protocols is calculated.

[0215] Communication protocol support calculation:

[0216] Assume the communication protocol used by the sensor is The gateway supports the following set of communication protocols: .

[0217] Communication protocol support The calculation formula is:

[0218] .

[0219] in:

[0220] Native support: The gateway hardware directly supports this protocol without any additional processing overhead.

[0221] Protocol conversion: The gateway supports the protocol but needs to perform protocol conversion, which will incur additional processing latency and resource consumption.

[0222] Software upgrade support: If the gateway hardware is compatible but the current firmware does not support it, support can be obtained through OTA upgrade.

[0223] Hardware incompatibility: The gateway hardware architecture does not support this protocol and cannot be implemented through software.

[0224] Data type support calculation:

[0225] Let the data type generated by the sensor be... (Such as vibration data, video streams, temperature data, etc.), the gateway supports the following set of data processing capabilities. .

[0226] Data type support The calculation formula is:

[0227] .

[0228] in: ,and (usually taken) ).

[0229] Type matching degree calculate:

[0230] .

[0231] Processing capacity matching degree calculate:

[0232] .

[0233] in: Gateway for data types Processing throughput (e.g., frames per second, KB per second). The data generation rate of the sensor The maximum processing latency required by the sensor. Gateway data types The actual delay;

[0234] Gateway's support for sensor data types or communication protocols is calculated as follows:

[0235] By combining communication protocol support and data type support, we can obtain the gateway's support data for sensor data types or communication protocols:

[0236] .

[0237] in The weights can be dynamically adjusted according to the application scenario: for sensors with high real-time requirements (such as emergency alarms), the weight of data type is increased. For newly deployed heterogeneous network environments, increase protocol support weights. For example: This belongs to an emergency alarm, and the data type weight is... The weight is 0.8, and the protocol supports weights. The value is 0.2; this belongs to a newly deployed heterogeneous network environment, and the data type weight is... The value is 0.2, and the protocol supports weights. It is 0.8.

[0238] In this embodiment, the signal strength data from the sensor to the gateway, the remaining load data of the gateway, and the matching degree data between the gateway's data processing capability and the sensor's requirements are used as gateway evaluation data. Other parameters can also be selected as gateway evaluation data according to actual needs.

[0239] Multiple sensor evaluation data include at least three of the following: sensor data service priority data, sensor data throughput requirements matching the gateway's currently available resources data, sensor-to-gateway communication distance data, and the matching of the sensor's physical area with the gateway's coverage area data.

[0240] The data service priority data of the sensor is calculated as follows: based on the number of data service priority levels, each level is assigned a corresponding value by decreasing from 1 at intervals of 1 / number of levels, and then the data service priority data of the sensor is obtained according to the data service priority.

[0241] In this embodiment, the priority is divided into 5 levels. Therefore, if each level is spaced at intervals of 1 / 5 of the number of levels, the numerical interval for each level is 1 / 5 = 0.2. That is, level 1 is 1, level 2 is 0.8, level 3 is 0.6, level 4 is 0.4, and level 5 is 0.2. Then, according to the priority of the corresponding sensor, the corresponding value is assigned as the sensor's data service priority data.

[0242] The matching degree data between the sensor's data throughput requirement and the gateway's currently available resources is calculated as follows: based on the data throughput requirement and the currently available resources, the matching degree formula is used to calculate the matching degree data between the sensor's data throughput requirement and the gateway's currently available resources.

[0243] The matching degree between the sensor's data throughput requirements and the gateway's currently available resources is calculated using a matching degree formula, specifically: Where A represents currently available resources and B represents data throughput requirements.

[0244] The matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is calculated as follows: based on the physical location of the sensor and the physical location of the gateway, the spatial distance between the sensor and the gateway is calculated using the weighted Euclidean formula. Then, based on the spatial distance and the coverage area of ​​the gateway, the matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is calculated.

[0245] Set sensor The physical location coordinates are Gateway The physical location coordinates are Gateway The coverage area is defined as a three-dimensional ellipsoid or polygonal region centered on the gateway location.

[0246] Based on the actual deployment environment of elevator IoT, a layered coverage model is adopted:

[0247] Hierarchical coverage area definition:

[0248] Core coverage area The area with the best gateway signal strength is typically centered on the gateway and within a radius of [missing information]. A sphere; in this embodiment, =15 meters;

[0249] Standard coverage area The area where the gateway is functioning normally, with a radius of [radius value missing]. ( In this embodiment, =30 meters;

[0250] Edge coverage area The area where the gateway signal is weak but still connectable, with a radius of [radius value missing]. ( In this embodiment, =50 meters;

[0251] Spatial distance calculation:

[0252] Considering the three-dimensional spatial characteristics of elevator IoT and the signal propagation characteristics inside buildings, weighted Euclidean distance is adopted:

[0253] .

[0254] The weighting coefficients take into account the influence of building structure. (Low resistance to horizontal propagation)

[0255] (The signal attenuation is greater when the signal passes through the floor slab vertically.)

[0256] Region matching degree calculation:

[0257] Physical region matching degree Calculation using piecewise functions:

[0258] .

[0259] Obstacle correction factor:

[0260] Considering the impact of obstacles such as elevator shafts and concrete walls on signal propagation, an obstacle correction factor is introduced. :

[0261] .

[0262] in: The number of obstacles on the path from the sensor to the gateway; For the first The influence coefficient of each obstacle (value range [0, 1]); For the first Penetration loss coefficient of an obstacle;

[0263] Common obstacle influence parameters:

[0264] Ordinary walls: , ;

[0265] Elevator shaft: , ;

[0266] Metal doors / elevator doors: , ;

[0267] Floor slab: , ;

[0268] Final matching degree calculation:

[0269] Taking into account spatial distance and the influence of obstacles, the matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is as follows:

[0270] .

[0271] in, Floor factor:

[0272] .

[0273] In this embodiment, sensor data service priority data, sensor-to-gateway communication distance data, and the matching degree data between sensor data throughput requirements and the gateway's currently available resources are used as sensor evaluation data. Other parameters can also be selected as gateway evaluation data according to actual needs.

[0274] Step 2: Assign corresponding first weights to the evaluation data of each gateway and corresponding second weights to the evaluation data of each sensor; calculate the evaluation score of each sensor for different gateways using a multi-criteria decision model based on the evaluation data of multiple gateways and the corresponding first weights; calculate the evaluation score of each gateway for different sensors using a multi-criteria decision model based on the evaluation data of multiple sensors and the corresponding second weights.

[0275] In this embodiment, by assigning different weights to each data point, the parameter weights can be adjusted according to changes in each data point, thereby enabling accurate and stable pairing based on the actual situation. The first and second weights are only used to distinguish between gateway evaluation data and sensor evaluation data; the first and second have no other meaning. Furthermore, the weights of the evaluation data are not necessarily the same and will be set according to the importance of the sensor or the importance of the data.

[0276] Preferably, step 2 includes the following steps:

[0277] Step A1: Assign corresponding initial first weights to multiple gateway evaluation data and assign corresponding initial second weights to multiple sensor evaluation data, wherein the sum of multiple initial first weights is 1 and the sum of multiple initial second weights is 1;

[0278] In this embodiment, the initial first weight of the signal strength data from the sensor to the gateway is 0.4, the initial first weight of the remaining load data of the gateway is 0.35, and the initial first weight of the matching degree data between the gateway's data processing capability and the sensor's requirements is 0.25.

[0279] The initial second weight for sensor data service priority data is 0.45, the initial second weight for sensor-to-gateway communication distance data is 0.35, and the initial second weight for the matching degree between sensor data throughput requirements and the gateway's currently available resources is 0.2.

[0280] Step A2: Set the threshold values ​​for system status indicators related to gateway evaluation data and sensor evaluation data respectively, and obtain each system status indicator in real time. When any system status indicator related to gateway evaluation data or sensor evaluation data is greater than the corresponding system status indicator threshold, increase the initial first weight of the corresponding gateway evaluation data or the initial second weight of the sensor evaluation data by N. The initial first weight of the remaining gateway evaluation data or the initial second weight of the sensor evaluation data is adjusted according to the increase amount to obtain the first weight of all gateway evaluation data or the second weight of all sensor evaluation data. N ranges from 10 to 80, the sum of all first weights is 1, and the sum of all second weights is 1.

[0281] In this embodiment, the system status index related to the signal strength data from the sensor to the gateway is the network fluctuation coefficient, and the specific formula is as follows: ,in, For the number of sensors, Let be the RSSI value of the i-th sensor. This is the average RSSI value for all sensors. Set the network variability coefficient threshold. =10dBm, when > When this happens, the initial first weight of the sensor-to-gateway signal strength data is increased by 10%, and then used as the first weight of the sensor-to-gateway signal strength data.

[0282] The system status metric related to the gateway's remaining load data is the load imbalance coefficient, calculated using the following formula: ,in, For the number of gateways, The current load of the j-th gateway. Set a load imbalance coefficient threshold for the average current load of all gateways. =0.2, when > If this happens, the initial first weight of the gateway's remaining load data is increased by 10%, and then used as the first weight of the gateway's remaining load data.

[0283] The system status indicators related to the matching degree between the gateway's data processing capabilities and the sensor's requirements are the matching quality assessment indicators, and the specific calculation formula is as follows: ,in, For sensors Matching gateway The matching score represents the degree of match between the gateway's data processing capabilities and the sensor's requirements. When the matching quality assessment index exceeds the matching quality assessment index threshold, the initial first weight of the matching score between the gateway's data processing capabilities and the sensor's requirements is increased by 10%, becoming the first weight of the matching score between the gateway's data processing capabilities and the sensor's requirements.

[0284] When all three data points are greater than the corresponding threshold or all three data points are less than the corresponding threshold, the initial weight of the gateway evaluation data remains unchanged. When two or one data point is greater than the corresponding threshold, the initial weight of the corresponding gateway evaluation data point is increased by 10%. The initial weights of the remaining gateway evaluation data points are then divided into equal parts based on this increase, and then decreased by that value to obtain the initial weights of the remaining gateway evaluation data points. For example, if the network fluctuation coefficient is greater than the corresponding threshold, the initial weight of the signal strength data from the sensor to the gateway is increased by 10% (assuming the weight is increased by 0.1). If the other two are less than the threshold, the initial weights of the other two gateway evaluation data points are decreased by 0.5 respectively, becoming the initial weights of the remaining two gateway evaluation data points.

[0285] The system status indicator related to the priority data of sensor services is the priority distribution imbalance coefficient, and the specific calculation formula is as follows: ,in, The total number of priority levels. Priority level The number of sensors, The average number of sensors for each priority level ( (The total number of sensors); when the priority distribution imbalance coefficient is greater than the priority distribution imbalance coefficient threshold, the initial second weight of the sensor's data service priority data is increased by 10%, and is used as the second weight of the sensor's data service priority data.

[0286] The system status metric related to the communication distance data from the sensor to the gateway is the distance distribution variance, which is calculated using the following formula: ,in, For sensors To the gateway The weighted Euclidean distance, This is the average of all sensor-gateway distances. The total number of sensors, The total number of gateways; when the distance distribution variance is greater than the distance distribution variance threshold, the initial second weight of the sensor-to-gateway communication distance data is increased by 10%, and used as the second weight of the sensor-to-gateway communication distance data.

[0287] The system status indicator related to the matching degree between the sensor's data throughput requirements and the gateway's currently available resources is the resource requirement matching degree variance, which is calculated using the following formula:

[0288] .

[0289] in, For sensors The best possible resource matching This represents the average best match.

[0290] .

[0291] in, Gateway The currently available resources (equivalent bandwidth, in Mbps). For sensors Data throughput requirements (in Mbps). The quality factor is calculated using the following formula:

[0292] .

[0293] When the variance of resource demand matching degree is greater than the threshold of resource demand matching degree variance, the initial second weight of the matching degree data between the sensor's data throughput demand and the gateway's currently available resources is increased by 10%, and is used as the second weight of the matching degree data between the sensor's data throughput demand and the gateway's currently available resources.

[0294] The dynamic adjustment method for the second weight of the gateway evaluation data is the same as the dynamic adjustment method for the first weight of the sensor evaluation data. Furthermore, the corresponding thresholds can be set according to the actual situation.

[0295] Step A3: Based on the evaluation data of multiple gateways and the corresponding first weights, calculate the evaluation score of each sensor for different gateways using a multi-criteria decision model; based on the evaluation data of multiple sensors and the corresponding second weights, calculate the evaluation score of each gateway for different sensors using a multi-criteria decision model.

[0296] In this embodiment, multiple gateway evaluation data and corresponding first weights are input into a multi-criteria decision model, which calculates the sensor's evaluation score for different gateways; multiple sensor evaluation data and corresponding second weights are input into the multi-criteria decision model, which calculates the evaluation score for each gateway for different sensors.

[0297] The multi-criteria decision-making model is as follows: Where n is the number of gateway evaluation data or sensor evaluation data selected. This is a normalization function, specifically MIN-MAX normalization. For gateway evaluation data or sensor evaluation data, For the corresponding first or second weight.

[0298] When the gateway evaluation data or sensor evaluation data shows that the larger the data value, the better the effect (positive change):

[0299] .

[0300] in, and These are the minimum and maximum values ​​of the data across all gateways or sensors, respectively. At that time, the normalization value was uniformly set to 0.5.

[0301] When the gateway evaluation data or sensor evaluation data shows an inverse relationship where larger data values ​​result in worse performance:

[0302] .

[0303] in, and These are the minimum and maximum values ​​of the data across all gateways or sensors, respectively. At that time, the normalization value was uniformly set to 0.5.

[0304] Step 3: Based on the evaluation scores of each sensor for different gateways, sort them in descending order according to the evaluation scores of different gateways to construct a preference list for each sensor; based on the evaluation scores of each gateway for different sensors, sort them in descending order according to the evaluation scores of different sensors to construct a preference list for each gateway.

[0305] In this embodiment, a preference list is constructed for each sensor. The sensor's preference list contains all available gateways and is arranged in descending order based on the evaluation scores between the gateway and the sensor. When two gateways have the same evaluation score, they are sorted a second time according to preset secondary features (such as the lexicographical order of the gateway's unique ID) to ensure the uniqueness and determinism of the preference list.

[0306] Similarly, each gateway constructs a preference list containing all sensors to be paired. These preference lists are arranged in descending order of evaluation scores between the sensors and the gateway. When two sensors have the same evaluation score, they are further sorted based on preset secondary characteristics (such as the lexicographical order of the sensor's unique ID) to ensure the uniqueness and determinism of the preference lists.

[0307] Step 4: Based on the preference list of each sensor and the preference list of each gateway, use an improved delayed reception algorithm to generate relevant information of all sensors to be paired and a stable pairing scheme between all available gateways.

[0308] Preferably, the specific process of the improved delayed reception algorithm is as follows:

[0309] Step B1: Allocate quotas to each gateway using the quota calculation formula and build a pre-pairing list for each gateway;

[0310] Set definition: Let the set of sensors to be paired be... The available gateway set is .

[0311] Capacity quota definition: for each gateway Allocate a quota quantity ( ,and (Integer), this value represents the gateway. The maximum number of sensors that can be accessed and processed simultaneously while ensuring Quality of Service (QoS). Quota The calculation is based on the gateway processing capacity (CPU utilization and memory utilization) and load (network bandwidth) collected in step 1.

[0312] The quota calculation formula is:

[0313] .

[0314] in, and Gateway CPU and memory utilization (values ​​range from [0,1]). Gateway The remaining available bandwidth (in Mbps). This represents the average resource requirement for all sensors in the system (in Mbps, obtained by converting CPU and memory resource requirements into equivalent bandwidth requirements using preset weights, and then adding this value to the bandwidth requirement). This formula ensures that the gateway will not be overloaded due to too many connected sensors, while taking into account resource constraints in three dimensions: CPU, memory, and bandwidth.

[0315] The calculation formula is:

[0316] .

[0317] in, For bandwidth, The equivalent bandwidth required by the CPU. In this embodiment, the weight of CPU demand is determined to be the equivalent bandwidth for memory requirements. =0.6, weight of memory requirement =0.4.

[0318] The formula for calculating the equivalent bandwidth of CPU requirements is:

[0319] .

[0320] in, CPU requirements for the sensor (in percentage). Based on empirical data and performance testing, the CPU to bandwidth conversion ratio is set as follows: 1% CPU utilization ≈ 2 Mbps equivalent bandwidth, that is: Mbps;

[0321] The formula for calculating the equivalent bandwidth conversion of memory requirements is:

[0322] .

[0323] in, The sensor's memory requirements (in MB). To determine the memory-to-bandwidth conversion ratio, based on the bandwidth requirements of memory access and data processing, the following conversion standard is set: 1 MB of memory usage ≈ 0.5 Mbps of equivalent bandwidth, that is: Mbps / MB.

[0324] For example: a temperature sensor with a bandwidth requirement of 0.1 Mbps, CPU requirement of 2%, and memory requirement of 8 MB, then the equivalent bandwidth is 0.1 + 0.6 × 4 + 0.4 × 4 = 4.7 Mbps, which is... It is 4.7 Mbps.

[0325] State Initialization: Initially, all sensors are in a "Free" state (ready to be paired), each gateway's "Tentative List" is empty, and each gateway's available quota is... The used quota is 0. Define the sensor state set. Where Free indicates that the sensor has not found a matching gateway, Tentative indicates that the sensor has sent a request to a gateway and is waiting for confirmation, and Matched indicates that the sensor has found a matching gateway.

[0326] Step B2: Each sensor looks up its own preference list and sends a connection request to the gateway with the highest ranking that has not been rejected by the corresponding gateway.

[0327] In this embodiment, for each sensor in the "Free" state, the algorithm performs the following operation: find the gateway that ranks highest in the sensor's preference list and has not been explicitly rejected by that gateway before. The sensor sends data to the gateway. A connection request is sent, containing the sensor's unique identifier and current status information. The sensor's status changes from Free to Tentative.

[0328] Step B3: After receiving a sensor request, the gateway adds the sensor to the pre-pairing list. Then, according to the gateway's preference list, the sensors in the pre-pairing list are sorted to obtain a sensor candidate set. When the total number of sensors in the sensor candidate set is greater than the quota, the gateway rejects the sensors ranked after the quota in the sensor candidate set and removes them from the sensor candidate set.

[0329] In this embodiment, the gateway After receiving connection requests from a series of sensors, the following evaluation process is executed: Gateway The gateway merges the newly received set of requested sensors with the sensors currently in the "Tentative List". The system sorts all sensors in the pre-pairing list according to its own preference list, resulting in a sorted candidate list. (in ).

[0330] Quota Inspection and Decision-Making:

[0331] If the total number of candidate sets ≦Quota Gateway Update the "pre-pairing list" to the candidate set. All sensors in the system are kept in a Tentative state.

[0332] If the total number of candidate sets > Gateway Update the "pre-pairing list" to the sorted candidate list. Top The sensor of position (i.e.) These sensors remain in a Tentative state; for those ranked in The subsequent sensor (i.e. ), gateway Perform a "Reject" operation, sending a rejection notification to these sensors. Note: If a sensor was originally in the "pre-pairing list" but its ranking drops after this round of sorting... After that, the sensor will also be rejected and removed from the "pre-pairing list".

[0333] Step B4: After receiving the rejection operation from the gateway, the sensor removes the gateway from the sensor's preference list, obtains a new sensor preference list, and replaces the old sensor preference list.

[0334] A rejected sensor performs the following state update operation: the sensor's state changes from Tentative to Free. The sensor is removed from its preference list. (Marked as rejected), a new list of sensor preferences is obtained, replacing the old list. In the next iteration, the sensor will attempt to initiate a new connection request to the highest-ranking gateway in its updated preference list. Sensors that are not rejected and remain in the sensor candidate set remain in the Tentative state, awaiting the next iteration.

[0335] Step B5: Repeat steps B2 to B4 until one of the termination conditions is met, generating a stable pairing scheme between all sensors to be paired and all available gateways.

[0336] The termination condition is:

[0337] (i) All sensors are not in the Free state (i.e., all sensors are either in the Tentative state or have been rejected and the preference list has been exhausted).

[0338] (ii) The preference lists of all unpaired sensors have been exhausted (i.e., the preference lists of all sensors in the Free state are empty), and no connectable gateway can be found.

[0339] (iii) Continuous Round iteration ( For example, a preset constant. No state changes occurred during the process (no new connection requests, no rejection operations, no state transitions), indicating that the algorithm has converged to a stable state.

[0340] When the algorithm terminates (any one of the termination conditions is met), all sensors in the Tentative state automatically switch to the Matched state, indicating that the pairing was successful.

[0341] Output and stability guarantee: After the algorithm terminates, the system generates the final stable pairing mapping function. Among them: for successfully matched sensors , Indicates sensor Matched to gateway For sensors that failed to match , This indicates that the sensor has not found a connectable gateway.

[0342] This pairing scheme satisfies the mathematical definition of stable matching, meaning there are no "blocking pairs": no sensors exist. and gateway It must simultaneously meet the following two conditions:

[0343] Condition 1: right The preference is higher than that of its current match, that is (when (time) or exist In the preference list (when hour).

[0344] Condition 2: right The preference is higher than that of the worst of its currently matched sensors, i.e., there exists ( Indicates a match with the gateway. The entire set of sensors) makes or gateway The current number of matches is less than its quota. (Right now ).

[0345] Step 5: According to the stable pairing scheme, send a pairing command to the sensor, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

[0346] In this embodiment, for each successfully matched sensor-gateway pair (in Generate pairing instructions, the instructions of which include: new gateway The gateway's unique identifier (Gateway ID), communication protocol parameters (such as communication frequency, encryption key, and data format), connection parameters (such as timeout and retries), and switching time window are all obtained from the gateway's parameters.

[0347] To prevent data loss due to pairing adjustments, when a sensor needs to be switched from an old gateway to a new gateway, perform the following steps:

[0348] Pairing command issuance: Send a new pairing command to the sensor that needs to be switched. The command includes the identifier of the new gateway, connection parameters and switching time window.

[0349] Pre-connection: While maintaining connection with the old gateway, the sensor establishes a handshake link with the new gateway according to instructions to complete identity authentication and parameter negotiation.

[0350] Status synchronization: Before the formal switchover, the old gateway forwards the sensor's cached data (including unprocessed fragmented data and status information) to the new gateway or uploads it directly to the cloud to ensure the continuity of the data flow.

[0351] Dual Transmission with Deduplication: Within the switching time window (duration) ,in As a preset multiple, it is usually taken as or , (data packet transmission period), sensor All business data are simultaneously sent to the old gateway and new gateway Send. Each data packet carries a unique identifier triple. ,in For timestamps. It serves as a unique identifier for the sensor (Sensor ID). This is the sequence number. The cloud platform uses this unique identifier for data deduplication and sorts data by sequence number. Ensure the data is in the correct order and avoid data duplication and out-of-order processing.

[0352] Resource release: System monitors new gateway Data reception status, when continuously data packets ( The preset threshold is usually set to... or If the connection is successfully received without packet loss, it is determined to be stable and reliable. The system then issues a resource release command to the sensor. Disconnect from the old gateway The connection, old gateway Release the resource quota occupied by the sensor (used quota -1, available quota +1), and remove the sensor from the list of connected devices. .

[0353] After receiving the pairing command, the sensor pairs with the new gateway according to the parameters in the command. Establish network connection, complete identity authentication and parameter negotiation. Gateway Confirm sensor Upon receiving a connection request, the system adds the device to the list of connected devices and updates the available quota (used quota +1, available quota -1). The system verifies that the newly established connection is working correctly, including data transmission testing, latency measurement, and packet loss rate detection. If connection verification fails, a reconfiguration process is triggered (returning to step 1).

[0354] Preferably, the method further includes step 6: after the sensor and gateway are paired, if one of the reconfiguration conditions is met, then steps 1 to 5 are repeated.

[0355] Reassignment conditions include:

[0356] (a) CPU utilization is greater than 85%, the RSSI value from sensor to gateway is less than -90dBm, a new gateway is added or the existing gateway is offline;

[0357] (ii) Recalculate the global preference score of the current pairing scheme at preset intervals to obtain the theoretical global preference score. When the theoretical global preference score is greater than 1.15 times the current global preference score.

[0358] This method uses a dual triggering mode of "event-driven + periodic inspection" to dynamically adjust and reconfigure when changes occur in the elevator system, and can respond to situations such as equipment coming online, faults, and changes in network quality in the system.

[0359] It should be noted that when the reconfiguration condition (I) is met, during the process of repeating steps 1 to 5, the timing in the reconfiguration condition (II) is paused. After the reconfiguration condition (I) is completed, the preset time is recalculated from zero.

[0360] Example 2

[0361] refer to Figure 2 A dynamic and stable pairing system for sensors and gateways, used to implement the aforementioned dynamic and stable pairing method for sensors and gateways, includes the following units:

[0362] Information acquisition unit: used to acquire relevant information of all sensors to be paired and relevant information of all available gateways; based on the relevant information of all sensors to be paired and relevant information of all available gateways, calculate multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway.

[0363] The scoring calculation unit is used to assign corresponding first weights to the evaluation data of each gateway and corresponding second weights to the evaluation data of each sensor; based on the evaluation data of multiple gateways and the corresponding first weights, it calculates the evaluation score of each sensor for different gateways through a multi-criteria decision model; based on the evaluation data of multiple sensors and the corresponding second weights, it calculates the evaluation score of each gateway for different sensors through a multi-criteria decision model.

[0364] Preference list generation unit: used to construct a preference list for each sensor by sorting the evaluation scores of different gateways in descending order based on the evaluation scores of different gateways; and to construct a preference list for each gateway by sorting the evaluation scores of different sensors in descending order based on the evaluation scores of different gateways.

[0365] Pairing scheme generation unit: used to generate relevant information of all sensors to be paired and stable pairing schemes between all available gateways based on the preference list of each sensor and the preference list of each gateway, using an improved delayed reception algorithm;

[0366] Connection establishment unit: Used to send pairing commands to the sensor according to a stable pairing scheme, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

[0367] In this embodiment, the specific operation process of the dynamic stable pairing system is as follows: the information acquisition unit acquires the relevant information of all sensors to be paired and the relevant information of all available gateways, calculates multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway, and then sends the multiple gateway evaluation data and multiple sensor evaluation data to the score calculation unit.

[0368] After receiving multiple gateway evaluation data and multiple sensor evaluation data, the scoring calculation unit assigns a corresponding first weight to each gateway evaluation data and a corresponding second weight to each sensor evaluation data. Then, it calculates the evaluation score of each sensor for different gateways and the evaluation score of each gateway for different sensors through a multi-criteria decision model. Finally, it sends the evaluation scores of each sensor for different gateways and the evaluation scores of each gateway for different sensors to the preference list generation unit.

[0369] The preference list generation unit constructs a preference list for each sensor, which includes all gateways. Based on the sensor's evaluation score for different gateways, the gateways are sorted in descending order of evaluation score. The unit also constructs a preference list for each gateway, which includes all sensors. Based on the gateway's evaluation score for different sensors, the sensors are sorted in descending order of evaluation score. The preference list is then sent to the pairing scheme generation unit.

[0370] The pairing scheme generation unit generates relevant information of all sensors to be paired and stable pairing schemes between all available gateways based on the preference list of each sensor and the preference list of each gateway using an improved delayed reception algorithm, and then sends the stable pairing schemes to the connection establishment unit.

[0371] The connection establishment unit sends a pairing command to the sensor according to the stable pairing scheme, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

[0372] Although embodiments of the invention have been shown and described, those skilled in the art will understand that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the claims and their equivalents.

Claims

1. A method for dynamically and stably pairing a sensor and a gateway, characterized in that, Includes the following steps: Step 1: Obtain relevant information for all sensors to be paired and relevant information for all available gateways; Based on the relevant information of all sensors to be paired and the relevant information of all available gateways, multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway are calculated respectively. Step 2: Assign the corresponding first weight to the evaluation data of each gateway, and assign the corresponding second weight to the evaluation data of each sensor; Based on multiple gateway evaluation data and their corresponding first weights, a multi-criteria decision model is used to calculate the evaluation score of each sensor for different gateways. Based on evaluation data from multiple sensors and corresponding secondary weights, a multi-criteria decision model is used to calculate the evaluation score of each gateway for different sensors. Step 3: Based on the evaluation scores of each sensor for different gateways, sort them in descending order according to the evaluation scores of different gateways to construct a preference list for each sensor; Based on the evaluation scores of each gateway for different sensors, the preferences list for each gateway is constructed by sorting the evaluation scores of different sensors in descending order. Step 4: Based on the preference list of each sensor and the preference list of each gateway, use an improved delayed reception algorithm to generate relevant information of all sensors to be paired and a stable pairing scheme between all available gateways. Step 5: According to the stable pairing scheme, send a pairing command to the sensor, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

2. The dynamic and stable pairing method between the sensor and the gateway according to claim 1, characterized in that, The relevant information of the sensor to be paired includes at least three of the following: sensor data type, communication protocol used by the sensor, RSSI value from the sensor to the gateway, data production rate, data real-time requirements, data service priority, data throughput requirements, requirements for gateway functions, and the physical location of the sensor. The relevant information of the available gateways includes at least four of the following: CPU utilization, memory utilization, network bandwidth, current load status, currently available resources, supported communication protocols, supported data processing capabilities, physical location of the gateway, and coverage area. Multiple gateway evaluation data include at least three of the following: sensor-to-gateway signal strength data, sensor-to-gateway communication distance data, gateway remaining load data, data on the match between the gateway's data processing capabilities and sensor requirements, and data on the gateway's support for sensor data types or communication protocols. Multiple sensor evaluation data include at least three of the following: sensor data service priority data, sensor data throughput requirements matching the gateway's currently available resources data, sensor-to-gateway communication distance data, and the matching of the sensor's physical area with the gateway's coverage area data.

3. The dynamic and stable pairing method between the sensor and the gateway according to claim 2, characterized in that, In step 1, the signal strength data from the sensor to the gateway is calculated as follows: the RSSI value from the sensor to the gateway is the signal strength data from the sensor to the gateway. The communication distance data between the sensor and the gateway is calculated as follows: based on the physical location of the sensor and the physical location of the gateway, the physical distance data between the sensor and the gateway is obtained. The remaining load data of the gateway is calculated as follows: based on the current load status, the remaining load data of the gateway is calculated using the remaining load rate formula; The method for calculating the matching degree data between the gateway's data processing capability and sensor requirements is as follows: Based on the data production rate and data real-time requirements, the sensor's processing requirement index is obtained; based on the CPU utilization and memory utilization, the gateway's processing capability index is obtained; based on the sensor's processing requirement index and the gateway's processing capability index, the matching degree formula is used to calculate the matching degree data between the gateway's data processing capability and sensor requirements. The gateway's support for sensor data types or communication protocols is calculated as follows: based on the communication protocols used and supported by the sensor, the communication protocol support is calculated; based on the sensor data type and supported data processing capabilities, the data type support is calculated; and based on the communication protocol support and data type support, the gateway's support for sensor data types or communication protocols is calculated. The data service priority data of the sensor is calculated as follows: based on the number of data service priority levels, the value of each level is assigned a corresponding value at intervals of 1 / number of levels, starting from 1; and then the data service priority data of the sensor is obtained according to the data service priority. The matching degree data between the sensor's data throughput requirement and the gateway's currently available resources is calculated as follows: based on the data throughput requirement and the currently available resources, the matching degree formula is used to calculate the matching degree data between the sensor's data throughput requirement and the gateway's currently available resources. The matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is calculated as follows: based on the physical location of the sensor and the physical location of the gateway, the spatial distance between the sensor and the gateway is calculated using the weighted Euclidean formula. Based on the spatial distance and the coverage area of ​​the gateway, the matching degree data between the physical area where the sensor is located and the coverage area of ​​the gateway is calculated.

4. The dynamic and stable pairing method between the sensor and the gateway according to claim 3, characterized in that, The matching degree formula is: Where A represents the gateway's processing capacity or currently available resources, and B represents the sensor's processing requirements or data throughput requirements.

5. The dynamic and stable pairing method between the sensor and the gateway according to claim 1, characterized in that, Step 2 includes the following steps: Step A1: Assign corresponding initial first weights to multiple gateway evaluation data and assign corresponding initial second weights to multiple sensor evaluation data, wherein the sum of multiple initial first weights is 1 and the sum of multiple initial second weights is 1; Step A2: Set the threshold values ​​for system status indicators related to gateway evaluation data and sensor evaluation data respectively, and obtain each system status indicator in real time. When any system status indicator related to gateway evaluation data or sensor evaluation data is greater than the corresponding system status indicator threshold, increase the initial first weight of the corresponding gateway evaluation data or the initial second weight of the sensor evaluation data by N. The initial first weight of the remaining gateway evaluation data or the initial second weight of the sensor evaluation data is adjusted according to the increase amount to obtain the first weight of all gateway evaluation data or the second weight of all sensor evaluation data. N ranges from 10 to 80, the sum of all first weights is 1, and the sum of all second weights is 1. Step A3: Based on the evaluation data of multiple gateways and the corresponding first weights, calculate the evaluation score of each sensor for different gateways using a multi-criteria decision model; based on the evaluation data of multiple sensors and the corresponding second weights, calculate the evaluation score of each gateway for different sensors using a multi-criteria decision model.

6. The dynamic and stable pairing method between the sensor and the gateway according to claim 5, characterized in that, The multi-criteria decision-making model is as follows: Where n is the number of gateway evaluation data or sensor evaluation data selected. For normalization function, For gateway evaluation data or sensor evaluation data, For the corresponding first or second weight.

7. The dynamic and stable pairing method between the sensor and the gateway according to claim 1, characterized in that, Step 4 includes the following steps: Step B1: Allocate quotas to each gateway using the quota calculation formula and build a pre-pairing list for each gateway; Step B2: Each sensor looks up its own preference list and sends a connection request to the gateway with the highest ranking that has not been rejected by the corresponding gateway. Step B3: After receiving a sensor request, the gateway adds the sensor to the pre-pairing list. Then, according to the gateway's preference list, the sensors in the pre-pairing list are sorted to obtain a sensor candidate set. When the total number of sensors in the sensor candidate set is greater than the quota, the gateway rejects the sensors ranked after the quota in the sensor candidate set and removes them from the sensor candidate set. Step B4: After receiving the rejection operation from the gateway, the sensor removes the gateway from the sensor's preference list, obtains a new sensor preference list, and replaces the old sensor preference list; Step B5: Repeat steps B2 to B4 until the termination condition is met, generating a stable pairing scheme between all sensors to be paired and all available gateways.

8. The dynamic and stable pairing method between the sensor and the gateway according to claim 2, characterized in that, It also includes step 6: After the sensor and gateway are paired, if one of the reconfiguration conditions is met, then steps 1 to 5 are repeated. Reassignment conditions include: (a) CPU utilization is greater than 85%, the RSSI value from sensor to gateway is less than -90dBm, a new gateway is added or the existing gateway is offline; (ii) Recalculate the global preference score of the current pairing scheme at preset intervals to obtain the theoretical global preference score. When the theoretical global preference score is greater than 1.15 times the current global preference score.

9. A dynamic and stable pairing system for a sensor and a gateway, characterized in that, The method for implementing the dynamic and stable pairing of the sensor and the gateway according to any one of claims 1-8 includes the following units: Information acquisition unit: used to acquire relevant information about all sensors to be paired and relevant information about all available gateways; Based on the relevant information of all sensors to be paired and the relevant information of all available gateways, multiple gateway evaluation data for each sensor and multiple sensor evaluation data for each gateway are calculated respectively. The scoring calculation unit is used to assign a corresponding first weight to the evaluation data of each gateway and a corresponding second weight to the evaluation data of each sensor. Based on multiple gateway evaluation data and their corresponding first weights, a multi-criteria decision model is used to calculate the evaluation score of each sensor for different gateways. Based on evaluation data from multiple sensors and corresponding secondary weights, a multi-criteria decision model is used to calculate the evaluation score of each gateway for different sensors. Preference list generation unit: used to construct a preference list for each sensor by sorting the evaluation scores of different gateways in descending order based on the evaluation scores of different gateways; Based on the evaluation scores of each gateway for different sensors, the preferences list for each gateway is constructed by sorting the evaluation scores of different sensors in descending order. Pairing scheme generation unit: used to generate relevant information of all sensors to be paired and stable pairing schemes between all available gateways based on the preference list of each sensor and the preference list of each gateway using an improved delayed reception algorithm; Connection establishment unit: Used to send pairing commands to the sensor according to a stable pairing scheme, and the sensor establishes a network connection with the corresponding gateway according to the pairing command.

Images