A hierarchical MQTT message priority scheduling system for mass terminals

Abstract

The application discloses a kind of layered MQTT message priority scheduling systems of mass terminal, including terminal agent module, it is deployed on mass terminal, for generating metadata for the MQTT message to be published;Edge scheduling gateway, it is deployed on the gateway of terminal and cloud platform, for receiving the MQTT message published by terminal in jurisdiction, and at least one of secondary priority determination and scheduling of message based on metadata, local network state and computing load, and selectively aggregate or cache to low priority message;Cloud collaborative scheduler, with multiple edge scheduling gateway communication connection, for receiving the state summary of each gateway, and according to global business target and resource condition, dynamically issue scheduling strategy parameters to each edge scheduling gateway, so that edge scheduling gateway carries out local scheduling.The application realizes local priority determination and scheduling, ensures to ensure that high priority message is processed first, reduces network bandwidth occupancy and computing resource consumption.

Description

Technical Field

[0001] This invention relates to the field of message transmission technology, and in particular to a hierarchical MQTT message priority scheduling system for a large number of terminals. Background Technology

[0002] In the Internet of Things (IoT) field, the MQTT protocol, with its lightweight design and publish / subscribe model, has become a mainstream communication protocol, widely used in data transmission scenarios involving massive numbers of terminal devices. However, existing technologies still have some drawbacks: First, the MQTT protocol itself does not provide a message priority mechanism, only defining three QoS service quality levels, which cannot differentiate scheduling based on the urgency of the business. Developers can only simulate priorities by customizing topic structures or message payloads. This application-layer implementation lacks standardization and cannot be uniformly scheduled and managed at the Broker level. Second, the traditional MQTT architecture uses a centralized Broker model. When a massive number of terminals connect simultaneously, a single Broker node handling 100,000 connections experiences high CPU utilization, making horizontal scaling difficult. When the same queue accumulates, real-time generated messages will be placed at the end of the queue, causing delays in the processing of critical messages. Low-priority messages often consume a large amount of network bandwidth and computing resources during congestion, while high-priority messages may be blocked. Although priorities can be simulated by splitting into multiple topics, the accumulation of one topic will affect multiple related devices. The lack of a fine-grained priority scheduling mechanism cannot guarantee the stable operation of critical businesses, and the utilization of computing resources is low. Summary of the Invention

[0003] To address at least one of the aforementioned technical problems, this invention provides a hierarchical MQTT message priority scheduling system for a large number of terminals.

[0004] In a first aspect, the present invention provides a hierarchical MQTT message priority scheduling system for a large number of terminals, the system comprising:

[0005] The terminal agent module, deployed on a massive number of terminals, is used to generate metadata for MQTT messages to be published. The metadata includes an initial priority identifier and message value decay attributes.

[0006] The edge scheduling gateway is deployed on the gateway between the terminal and the cloud platform. It is used to receive MQTT messages published by the terminal within the jurisdiction, and to perform secondary priority determination and scheduling of messages based on at least one of metadata, local network status and computing load, and to perform selective aggregation or caching of low-priority messages.

[0007] The cloud-based collaborative scheduler communicates with multiple edge scheduling gateways to receive status summaries from each gateway and dynamically distributes scheduling policy parameters to each edge scheduling gateway based on global business objectives and resource status, enabling the edge scheduling gateways to perform local scheduling. The scheduling policy parameters include at least priority mapping weights and bandwidth quotas.

[0008] Preferably, the low-priority message is an MQTT message whose initial priority identifier is lower than a first threshold;

[0009] The aggregation operation includes: merging multiple MQTT messages that meet the aggregation conditions within a predetermined time window or data volume window to generate an aggregated message; assigning a new priority to the aggregated message and then forwarding it.

[0010] Preferably, the terminal agent module is further configured to:

[0011] The message value decay attribute is calculated based on the initial urgency and business type of the MQTT message and a preset value decay function model; the value decay function model is determined based on the initial message value and the effective decay coefficient.

[0012] The effective attenuation coefficient is determined based on the end-to-end expected delay sensitivity factor, the terminal state uncertainty factor, and the cloud feedback correction factor.

[0013] Preferably, the edge scheduling gateway is equipped with a hybrid queuing model to manage the message queues to be processed;

[0014] The hybrid queuing model includes at least: a high-priority emergency queue, a time-sensitive queue that considers message lifespan and deadline, and a weighted fair queue to ensure service fairness.

[0015] Preferably, the emergency queue is a message queue whose priority level in the secondary priority determination result is greater than the second threshold;

[0016] The time-sensitive queue is a queue generated by determining the deadline based on the message value decay attribute or business rules, determining the remaining validity time of the message based on the deadline and the current time, and sorting the queues according to the remaining processing time.

[0017] The weighted fair queue is a queue that classifies messages according to their business source and assigns weights to each business flow. The edge scheduling gateway is also used to extract messages from the weighted fair queue using a weighted round-robin algorithm.

[0018] Preferably, the cloud-based collaborative scheduler is further configured to:

[0019] Based on the status summary of each edge scheduling gateway, the load ratio of emergency queue messages in the message queue to be sent and the corresponding link quality indicators between the edge scheduling gateway and the cloud are extracted.

[0020] Using the total available bandwidth resources of the entire network as a constraint, a target optimization function is constructed with the goal of minimizing the overall emergency queue message latency; where the bandwidth quota allocated to each edge scheduling gateway is directly proportional to the load proportion of emergency queue messages and inversely proportional to the reciprocal of the link quality index;

[0021] The bandwidth quota value is obtained by solving the objective optimization function and is sent to the corresponding edge scheduling gateway as part of the scheduling strategy parameters.

[0022] Preferably, the edge scheduling gateway is equipped with a context-aware module;

[0023] The context-aware module is used to monitor and analyze multiple messages from the same region, associated devices, or associated topics; when any preset associated event rule is detected, the priority of the corresponding message is automatically increased.

[0024] Preferably, the associated event rules include:

[0025] Spatial association rules, determined based on the device's geographical location or network topology, are configured to be triggered when the number of abnormal events occurring within a preset time window in the same area exceeds a certain threshold.

[0026] Logical association rules, determined based on the business logic relationships between devices, are configured to be triggered when the combination of data reported by multiple associated devices meets a preset complex event pattern;

[0027] Time-series association rules: Based on the data change trend of the same device or topic, they are configured to be triggered when the continuously reported data value or change rate exceeds the change rate threshold.

[0028] Preferably, the topic name of the MQTT message is encoded using a hierarchical structure, and the topic name contains at least one priority field for explicitly identifying the message;

[0029] Both the edge scheduling gateway and the cloud collaborative scheduler are equipped with a topic parsing and routing module, which is used to parse the priority field in the topic name in order to identify and differentiate message streams with different priorities.

[0030] In a second aspect, the present invention also provides an electronic device, including a hierarchical MQTT message priority scheduling system for a large number of terminals as described in any preferred embodiment of the first aspect.

[0031] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0032] This invention generates priority metadata through a terminal agent module. An edge scheduling gateway performs secondary priority determination based on this metadata, combined with a hybrid queuing model, ensuring priority processing of urgent queue messages and significantly reducing end-to-end latency of critical business messages. The edge scheduling gateway enables localized scheduling, alleviating pressure on the central broker; it aggregates and caches low-priority messages, reducing network bandwidth consumption; and the cloud-based collaborative scheduler dynamically allocates bandwidth quotas based on global resource conditions, achieving optimized resource configuration. A context-aware module monitors and analyzes related messages, automatically increasing message priority when preset related event rules are met, achieving intelligent scheduling based on business scenarios; the cloud-based collaborative scheduler dynamically adjusts scheduling strategies based on link quality indicators and load ratios, improving system adaptability. A weighted fair queue assigns weights to different business flows and uses a weighted round-robin algorithm to extract messages, avoiding single business flows monopolizing resources and ensuring overall system service fairness. Through hierarchical topic name encoding and topic resolution routing modules, it identifies and differentiates message flows of different priorities, combining message value decay attributes to ensure priority processing of time-sensitive messages, improving overall system reliability.

[0033] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0034] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the accompanying drawings used in the embodiments of the present invention or the background art will be described below.

[0035] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the specification, serve to illustrate the technical solutions of this disclosure.

[0036] Figure 1 This is a schematic diagram of the structure of a hierarchical MQTT message priority scheduling system for a large number of terminals, provided in an embodiment of the present invention.

[0037] Figure 2 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0038] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0039] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0040] Please see Figure 1 , Figure 1 This is a schematic diagram illustrating the structure of a hierarchical MQTT message priority scheduling system for a large number of terminals, provided as an embodiment of the present invention. Figure 1 As shown, the system includes:

[0041] The terminal agent module, deployed on a massive number of terminals, is used to generate metadata for MQTT messages to be published. The metadata includes an initial priority identifier and message value decay attributes.

[0042] The edge scheduling gateway is deployed on the gateway between the terminal and the cloud platform. It is used to receive MQTT messages published by the terminal within the jurisdiction, and to perform secondary priority determination and scheduling of messages based on at least one of metadata, local network status and computing load, and to perform selective aggregation or caching of low-priority messages.

[0043] The cloud-based collaborative scheduler communicates with multiple edge scheduling gateways to receive status summaries from each gateway and dynamically distributes scheduling policy parameters to each edge scheduling gateway based on global business objectives and resource status, enabling the edge scheduling gateways to perform local scheduling. The scheduling policy parameters include at least priority mapping weights and bandwidth quotas.

[0044] Traditional MQTT terminals typically publish raw data directly to the broker. While message priority (QoS) can be configured, it is often static and isolated, failing to reflect dynamic business value, resulting in network bandwidth being consumed by a large number of low-value messages. Therefore, in this embodiment, metadata generation, particularly "value decay attributes," is added to the terminal broker module. The core reason for this is the recognition of the time-sensitive value of IoT messages. By imbuing messages with "value life," the subsequent scheduling system can make better decisions, such as prioritizing the sending of an instruction that is about to expire rather than a log that never expires—that is, scheduling intelligence introduced from the data source.

[0045] In smart cities and the Industrial Internet of Things (IIoT), the number of terminal devices is enormous, including hundreds of thousands of smart meters and water meters, and numerous surveillance cameras and environmental monitoring sensors throughout the city. Simultaneous data reporting from all terminals puts immense bandwidth pressure and congestion risks on cellular networks and enterprise gateways. The terminal agent module deploys lightweight agent software on each IoT terminal, such as sensors and smart devices. When a terminal generates an MQTT message to be published, the agent does not directly send the original message. Instead, it appends a structured "metadata" based on the message's business content (such as alarms, status reports, file uploads) and preset rules. MQTT is a lightweight, publish / subscribe messaging protocol specifically designed for IoT and machine-to-machine communication. All sensor readings, device status, and control commands are encapsulated into MQTT messages for transmission.

[0046] Key metadata fields include an initial priority identifier and a message value decay attribute. The initial priority identifier is initially marked by the terminal based on the urgency of the message. The message value decay attribute defines a time function or rule to quantify the rate at which the value of the message decreases over time. For example, the value of "real-time control instructions" decays very quickly, while the value of "non-urgent logs" decays slowly.

[0047] In a preferred embodiment, the topic name of the MQTT message is encoded using a hierarchical structure, and the topic name contains at least one priority field for explicitly identifying the message;

[0048] Both the edge scheduling gateway and the cloud collaborative scheduler are equipped with a topic parsing and routing module, which is used to parse the priority field in the topic name in order to identify and differentiate message streams with different priorities.

[0049] By embedding priority information directly into MQTT topic names, gateways and the cloud can quickly identify message priorities by parsing topic names, enabling differentiated processing. For example, edge gateways and cloud schedulers have built-in topic parsing modules that extract priority identifiers at fixed locations; based on the parsed priorities, messages are distributed to different processing queues or channels, with high-priority messages going through fast channels and low-priority messages going through normal channels; by "tagging" topic names, the system can immediately identify message importance, achieving priority-based message routing.

[0050] Typically, existing methods attempt to implement complex scheduling algorithms in the cloud. However, with a massive number of terminals, aggregating all message metadata and network status information to the cloud incurs significant control signaling overhead and latency. Furthermore, the cloud cannot perceive the ever-changing wireless network conditions at the edge, such as transient congestion, in real time. Therefore, this embodiment decentralizes core scheduling decisions to the edge scheduling gateway. This reduces latency and uplink pressure; the edge gateway, being close to the terminal, can respond in milliseconds and locally aggregate / cachate low-priority messages, directly reducing uplink traffic. It also effectively utilizes local information; only edge nodes can perceive the micro-state of the network within their jurisdiction in real time and accurately, such as Wi-Fi interference and cellular signal strength. The "secondary judgment" based on this is more accurate and adaptable to dynamic environments than any static cloud rules.

[0051] Specifically, an edge scheduling gateway with computing capabilities is deployed on an edge server or gateway close to the terminal. It receives MQTT messages (including metadata) from all terminals within its jurisdiction. The gateway combines the received message metadata, local real-time network status (such as current link latency, packet loss rate, and queue depth), and its own computing load (CPU / memory utilization) to dynamically recalculate message priorities using a built-in or cloud-deployed scheduling algorithm model. For high-priority, low-latency messages (such as urgent alarms), they are immediately forwarded to the cloud or local application via the optimal path. For low-priority, latency-tolerant messages, selective aggregation or short-term caching is performed, waiting for network idle time or when the message value approaches a critical point before retransmission, thus significantly reducing instantaneous network traffic and transmission overhead. Typically, high and low priorities are determined by comparing with thresholds. Low-priority messages are usually MQTT messages with an initial priority below the first threshold. The aggregation operation here includes: merging multiple MQTT messages that meet the aggregation conditions within a predetermined time window or data volume window to generate an aggregated message; assigning a new priority to the aggregated message before forwarding it.

[0052] Preferably, when assigning a new priority to an aggregated message, the following factors typically need to be considered:

[0053] Original highest priority: The highest initial priority identifier among all messages in this batch. In other words, the importance of a batch of messages is determined by the most urgent one.

[0054] The most urgent timeliness: Analyze the value decay attributes of all messages to identify the one that is about to expire or whose value decays the fastest. Its urgency determines that the entire batch cannot wait too long.

[0055] Aggregation benefits: Aggregation itself is intended to save resources. This benefit can be seen as a "cost" of slightly lowering priority (not needing to process immediately), or as a reason to maintain priority (higher processing efficiency). Generally, large-batch aggregation can slightly lower priority, while small-batch aggregation maintains it.

[0056] Business strategy weights: The priority mapping weights issued by the cloud-based coordinating scheduler will affect the calculation. For example, if the cloud requires priority to be given to the "temperature topic," then the priority calculation of temperature sensor aggregated messages will receive a bonus.

[0057] To assign new priorities, the following calculation method can be used:

[0058] ;

[0059] In the formula, The new priority for aggregated messages, This represents the highest allowed priority value in the message scheduling system. This is the highest initial priority value in the current batch of messages. This represents the average urgency of the batch message value decay. These are the weighting factors for this business topic, distributed from the cloud. This is a discount factor based on the aggregation size; for example, it takes a value of 0.95 when the number exceeds 10, and a value of 0.9 when it exceeds 20. ; , These are all weighting coefficients, usually Greater than And the sum of the two is 1.

[0060] Through the above calculations, the aggregated message acquires a single, representative new priority. This priority will determine its position in the edge gateway's forwarding queue. After being received in the cloud, it may be used for further queue processing or task distribution. The aggregation operation is a process from classification and temporary storage to window triggering, and then to structured encapsulation. Assigning a new priority is a strategic value fusion calculation that integrates the urgency of the original message, timeliness pressure, and global business strategy, ensuring that the aggregation operation, which aims at "efficiency," does not compromise the "utility" of critical information and ensures timely delivery.

[0061] Understandably, if each edge gateway performs "selfish" optimizations based solely on local information, it could harm global objectives. For example, all gateways vying for bandwidth during peak hours could lead to core network congestion and overall inefficiency. To address this issue, this embodiment further introduces a cloud-based collaborative scheduler for global coordination. The cloud platform grasps the macro-level objectives of all services; only it can determine whether, at any given moment, priority should be given to security data in region A or production data in region B. Core network bandwidth is a shared and scarce resource across edge nodes. The cloud, acting as the "command center," dynamically allocates bandwidth quotas and adjusts priority mapping weights, much like an intelligent transportation system, enabling optimal global resource allocation across different regions and service flows. This prevents localized congestion and ensures the quality of service for critical services throughout the entire network.

[0062] Specifically, a global scheduler is deployed at the cloud platform center. It does not directly handle massive message flows but maintains control plane communication with all edge scheduling gateways. For global collaborative processes, it periodically receives status summaries (such as average load, queue status, and number of terminals in the jurisdiction) reported by each edge gateway. The cloud scheduler performs calculations and analyses based on global business objectives (such as ensuring smooth video surveillance across the entire network or prioritizing industrial control data in a specific area) and global resource conditions (such as core network bandwidth bottlenecks). The calculated control parameters, such as priority mapping weights, are used to increase the weight of certain types of business messages, and bandwidth quotas are dynamically distributed to each edge gateway to allocate differentiated uplink bandwidth limits to different edge nodes. The edge gateways adjust their local scheduling algorithms according to the policy parameters in the cloud, forming a closed loop of "local execution, global optimization."

[0063] Therefore, this embodiment constructs a hierarchical, feedback-based scheduling system of "terminal pre-labeling, edge intelligent decision-making, and cloud-based global control." This approach systematically addresses three major contradictions in massive IoT scenarios: the mismatch between static priorities and dynamic business needs, the mismatch between centralized processing and distributed deployment, and the mismatch between local and global optima. By rationally dividing and coordinating computation and decision-making among terminals, the edge, and the cloud, it achieves end-to-end message value perception and adaptive resource scheduling from data source to final processing, thereby maximizing the business efficiency of the entire IoT system with limited resources.

[0064] In one embodiment, the terminal agent module is further configured to:

[0065] The message value decay attribute is calculated based on the initial urgency and business type of the MQTT message and a preset value decay function model; the value decay function model is determined based on the initial message value and the effective decay coefficient.

[0066] The effective attenuation coefficient is determined based on the end-to-end expected delay sensitivity factor, the terminal state uncertainty factor, and the cloud feedback correction factor.

[0067] Traditional methods typically assign a fixed "lifetime" to each type of message. For example, an alarm message might arrive within one second under smooth network conditions, maintaining its value for five seconds. However, under network congestion, end-to-end latency could reach 10 seconds. A fixed "5-second expiration" is clearly unreasonable. Furthermore, in some scenarios, a terminal with sufficient battery power can quickly retransmit, while a message from a terminal with depleted battery power may not have a chance to be retransmitted. The value decay of its "last report" should be slower, giving the system more processing opportunities. A fixed decay model cannot be changed based on cloud-based adjustments to the overall business situation.

[0068] To address this, this embodiment introduces a value decay function model, which calculates the value decay attribute of a message over time. Specifically, three indicators are introduced when calculating the value decay attribute: an end-to-end expected latency sensitivity factor, designed to address network dynamics by linking the message value decay rate to the current network condition; a terminal state uncertainty factor, designed to address terminal heterogeneity by linking the message value decay rate to the terminal's own reliability and state; and a cloud feedback correction factor, designed to address global optimization by enabling the value decay model to dynamically adjust according to the cloud's global strategy, achieving synergy.

[0069] In one specific implementation, the value decay function model is as follows:

[0070] ;

[0071] ;

[0072] In the formula, For the message at the moment Its current value This refers to the lifetime of the message since its generation. The initial value of the message. It is a natural constant. For effective attenuation coefficient, Based on the attenuation coefficient, These are the weighting coefficients. End-to-end expected delay sensitivity factor For the uncertainty factor of the terminal state, This is a correction factor provided by the cloud.

[0073] The end-to-end expected latency sensitivity factor is calculated as follows:

[0074] ;

[0075] In the formula, The average round-trip time currently measured (e.g., the most recent 5-second sliding window); This is the historical baseline of the link. (e.g., the lowest 10th percentile over 7 days) Preset Tolerance threshold (e.g., 500 ms); results are cropped to the [0, 1] interval. The higher, The larger the value, the faster the attenuation; if the network is normal, ,at this time It is approximately 0.

[0076] The terminal state uncertainty factor is calculated as follows:

[0077] ;

[0078] In the formula, This is the time interval since the last heartbeat / status update from this terminal was received. This is a normal heartbeat cycle. To tolerate timeout windows; the longer the terminal is disconnected, the longer the connection is lost. The larger the value, the lower the credibility / timeliness of the message it sends.

[0079] The cloud-based feedback correction factor is calculated as follows:

[0080] ;

[0081] In the formula, This represents the proportion of such messages that were actually processed within the past window. The system's expected utilization threshold. The scaling factor is used to control the feedback strength and satisfies... It is usually taken as 0.5.

[0082] In one embodiment, the edge scheduling gateway has a hybrid queuing model internally for managing the message queues to be processed;

[0083] The hybrid queuing model includes at least: a high-priority emergency queue, a time-sensitive queue that considers message lifespan and deadline, and a weighted fair queue to ensure service fairness.

[0084] Preferably, the emergency queue is a message queue whose priority level in the secondary priority determination result is greater than the second threshold;

[0085] The time-sensitive queue is a queue generated by determining the deadline based on the message value decay attribute or business rules, determining the remaining validity time of the message based on the deadline and the current time, and sorting the queues according to the remaining processing time.

[0086] The weighted fair queue is a queue that classifies messages according to their business source and assigns weights to each business flow. The edge scheduling gateway is also used to extract messages from the weighted fair queue using a weighted round-robin algorithm.

[0087] In scenarios with a massive number of IoT terminals, edge dispatch gateways need to process MQTT messages with different characteristics from a large number of terminals. These messages may include:

[0088] Urgent alert message: Extremely low latency processing required, no delays allowed.

[0089] Time-sensitive data, such as periodically reported sensor data, may not be urgent, but it will lose its value if processed too late.

[0090] Background traffic, such as log uploads and software upgrade packages, can tolerate a relatively large delay, but a certain amount of bandwidth needs to be guaranteed to avoid "starving".

[0091] Using only a single queue may cause the following problems:

[0092] Low-priority messages starve: If high-priority messages keep coming in, low-priority messages may never be processed.

[0093] Ignoring the timeliness of messages: A medium-priority message that is about to expire may require more urgent handling than a high-priority message that has just been generated.

[0094] Lack of fairness: Some service flows may monopolize bandwidth, causing other service flows to be unable to receive services.

[0095] Therefore, this embodiment adopts a hybrid queuing model, distributing messages to different queues according to different scheduling objectives and employing different scheduling strategies:

[0096] Emergency queue (high-priority queue): Employs strict priority scheduling. Ensures that the highest priority messages are processed immediately, meeting their stringent low-latency requirements.

[0097] Time-sensitive queues: Employ scheduling strategies prioritizing either the earliest deadline or the minimum remaining slack time. Prioritize message timeliness to ensure messages are processed before they expire, maximizing message effectiveness.

[0098] Weighted Fair Queues: Employs weighted round-robin scheduling. Bandwidth is allocated among different service flows according to their weights, ensuring fairness, preventing starvation, and allowing different bandwidth ratios to be allocated based on service importance.

[0099] Specifically, the edge scheduling gateway maintains three logical queues in memory: an emergency queue for messages whose priority level is greater than the second threshold in the secondary priority determination result. For example, messages with priorities of "urgent" and "high" are placed in this queue. A time-sensitive queue for messages with a defined deadline. The deadline for these messages can be calculated from the message value decay attribute, such as the time point corresponding to when the message value decays to a certain threshold, or it can be directly specified by business rules. The queues are sorted according to the remaining validity time of the messages; the shorter the remaining validity time, the higher the position in the queue. A weighted fairness queue for messages that do not belong to the above two categories, or those that belong but require fairness to be guaranteed. This queue is classified according to business flow, such as by message topic, terminal group, tenant, etc. Each business flow is assigned a weight, which can be determined based on factors such as business contracts and priority mapping weights.

[0100] Furthermore, the edge scheduling gateway needs to decide how to select messages from these three queues for sending. Preferably, the overall scheduling strategy can adopt a combination of strict priority and round-robin. That is, the urgent queue is processed first, and only when the urgent queue is empty are the time-sensitive queue and the weighted fair queue processed. A certain ratio can be used for scheduling between the time-sensitive queue and the weighted fair queue, for example, using weighted round-robin. The specific process is as follows:

[0101] 1) Message Arrival and Enqueueing: When the edge scheduling gateway receives a message (which may come from a terminal agent or an aggregation operation), it first performs a secondary priority determination. Based on the determination result, it checks the message's priority level: if the priority is greater than the second threshold, it is placed in the emergency queue (sorted by priority from highest to lowest, and by arrival time for messages of the same priority). Otherwise, it checks whether the message has a deadline (or its remaining valid time can be calculated): if it has a deadline, it is placed in the timeliness queue, sorted in ascending order of remaining valid time (the one with the shortest remaining time is placed first). If it has no deadline, or if fairness needs to be ensured, it is placed in the corresponding sub-queue of the weighted fairness queue according to its business flow classification.

[0102] 2) Message Dequeueing and Sending: Check the emergency queue. If it is not empty, retrieve the first message (highest priority) from the emergency queue and send it. If the emergency queue is empty, check the time-sensitive queue and the weighted fairness queue. A scheduling ratio can be used here, for example, prioritizing the time-sensitive queue 70% of the time and the weighted fairness queue 30%. Specifically, each time a selection needs to be made between these two queues, a random number is generated, and the queue to be selected is determined based on the interval the random number falls into. Alternatively, a more refined approach can be to use a weighted ratio, such as a 70% weight for the time-sensitive queue and a 30% weight for the weighted fairness queue, and then perform weighted round-robin. When retrieving messages from the time-sensitive queue, always select the message with the shortest remaining validity period. When retrieving messages from the weighted fairness queue, a weighted round-robin algorithm is used: maintain a counter for each business flow, and round-robin each sub-queue according to the weighted ratio, retrieving the first message from the selected sub-queue each time.

[0103] 3) Queue Maintenance: Time-sensitive queues need to periodically check whether messages have expired. Expired messages can be discarded or downgraded. Each queue may need to have a length limit to prevent memory exhaustion. When a queue is full, it should be managed according to a discarding strategy, such as discarding the oldest or lowest priority messages.

[0104] 4) Collaboration with the Cloud: The scheduling strategy parameters issued by the cloud-based collaborative scheduler can influence the scheduling behavior of queues. For example, adjusting the second threshold can change the range of messages entering the emergency queue; adjusting the weights of different business flows in the weighted fair queue; and adjusting the scheduling ratio between the time-sensitive queue and the weighted fair queue. The edge scheduling gateway can report queue status, such as queue length, number of dropped messages, and average waiting time, as part of the status summary to the cloud for global optimization.

[0105] Therefore, the hybrid queuing model provided in this embodiment employs strict priority scheduling of the emergency queue to ensure that the highest priority messages are forwarded immediately, meeting their stringent latency requirements and thus guaranteeing personal safety or the stable operation of critical infrastructure. Based on time-sensitive queues, the system can prioritize processing messages that are about to expire, reducing message value loss due to processing delays and maximizing the overall utility of messages. This is particularly important for monitoring and control scenarios with high real-time requirements. Weighted fair queues ensure that different business flows receive bandwidth according to predetermined weights, preventing certain flows from monopolizing resources and improving the fairness and rationality of resource allocation. Through reasonable queue design and scheduling strategies, the system can maximize the utilization of network bandwidth and edge computing resources while meeting various performance indicators, thereby improving the efficiency of the entire IoT system. By dynamically adjusting queue parameters such as thresholds and weights through a cloud-based collaborative scheduler, global optimization of edge scheduling behavior can be achieved, enabling the system to adapt to constantly changing business objectives and network conditions.

[0106] In one embodiment, the cloud-based collaborative scheduler is further configured to:

[0107] Based on the status summary of each edge scheduling gateway, the load ratio of emergency queue messages in the message queue to be sent and the corresponding link quality indicators between the edge scheduling gateway and the cloud are extracted.

[0108] Using the total available bandwidth resources of the entire network as a constraint, a target optimization function is constructed with the goal of minimizing the overall emergency queue message latency; where the bandwidth quota allocated to each edge scheduling gateway is directly proportional to the load proportion of emergency queue messages and inversely proportional to the reciprocal of the link quality index;

[0109] The bandwidth quota value is obtained by solving the objective optimization function and is sent to the corresponding edge scheduling gateway as part of the scheduling strategy parameters.

[0110] Each edge gateway can only schedule bandwidth based on messages and network conditions within its jurisdiction. It may request more bandwidth due to a sudden surge in urgent messages within its jurisdiction, but this could lead to resource contention with other more urgent services across the network. Therefore, this embodiment aims to provide a utility-maximizing resource allocation model, formalizing the bandwidth allocation problem as a mathematical optimization problem.

[0111] Optimization goal: Minimize overall emergency queue message latency. This is the highest-level business objective, as the latency of emergency messages directly affects system security and core value.

[0112] Core constraint: Total available bandwidth resources across the entire network. This is the most fundamental physical limitation; bandwidth cannot be created out of thin air.

[0113] Decision variable: Bandwidth quota allocated to each edge gateway.

[0114] Allocation principle: Allocate bandwidth, a scarce resource, to the places that need it most and can best utilize it in the most efficient way. The underlying logic is:

[0115] The load ratio is directly proportional to the emergency queue: the more "emergency tasks" a gateway has (higher load ratio), the more serious the "fire" situation in its jurisdiction, and the more "firefighting resources" (bandwidth) it should receive.

[0116] Inversely proportional to the inverse of link quality metrics: poor link quality (such as high packet loss and high latency) means low channel "throughput efficiency." Allocating too much bandwidth to it will have diminishing marginal returns (because the channel itself limits throughput). Conversely, allocating more resources to gateways with good link quality will yield a higher "return on investment."

[0117] Specifically, the implementation process is as follows:

[0118] 1) The edge scheduling gateway periodically reports a status summary to the cloud-based collaborative scheduler, which must include:

[0119] Emergency queue load ratio: Total emergency queue message size / Total size of all pending messages, reflecting the density of "urgent business" on this node.

[0120] Link quality metric: A comprehensive value that can be calculated using the formula (1 - packet loss rate) × (baseline delay / current delay). The value ranges from 0 to 1, with higher values ​​indicating better link quality.

[0121] 2) Constructing and Solving the Objective Optimization Function: After collecting the aforementioned data from all N edge gateways, the cloud-based collaborative scheduler performs mathematical modeling. With the objective of minimizing the overall emergency queue message latency, constraints are constructed: ensuring that the total bandwidth quota allocated to each gateway does not exceed the total available bandwidth of the entire network, and that the bandwidth quota allocated to each gateway is not less than the minimum bandwidth. Bandwidth allocation is performed according to the principle of "proportional to load and inversely proportional to link quality." Then, the objective function is solved, and the obtained bandwidth quota for each gateway is used as the "bandwidth quota" item in the scheduling policy parameters and dynamically distributed to the corresponding edge scheduling gateway.

[0122] 3) Edge execution: After receiving a new bandwidth quota, the edge scheduling gateway immediately adjusts its local traffic scheduler to ensure that the total sending rate of all its messages, especially the emergency queue, does not exceed the accepted bandwidth quota.

[0123] This implementation enables the automatic allocation of bandwidth to where it is most needed and best utilized. In the event of a regional emergency, the cloud can instantly allocate more bandwidth resources to the edge gateways in that region, minimizing end-to-end latency of emergency messages and directly ensuring core business operations. By inversely proportional to bandwidth allocation and link quality metrics, the system naturally directs more traffic to healthier and more efficient network paths, thereby improving the overall utilization efficiency of network bandwidth resources. This is equivalent to using the same total bandwidth to carry more effective data, resolving the contradiction between limited resources and business demands in massive IoT scenarios.

[0124] In one embodiment, the edge scheduling gateway is provided with a context-aware module;

[0125] The context-aware module is used to monitor and analyze multiple messages from the same region, associated devices, or associated topics; when any preset associated event rule is detected, the priority of the corresponding message is automatically increased.

[0126] Preferably, the associated event rules include:

[0127] Spatial association rules, determined based on the device's geographical location or network topology, are configured to be triggered when the number of abnormal events occurring within a preset time window in the same area exceeds a certain threshold.

[0128] Logical association rules, determined based on the business logic relationships between devices, are configured to be triggered when the combination of data reported by multiple associated devices meets a preset complex event pattern;

[0129] Time-series association rules: Based on the data change trend of the same device or topic, they are configured to be triggered when the continuously reported data value or change rate exceeds the change rate threshold.

[0130] In traditional IoT message scheduling, each message is typically processed independently based on its own metadata. However, events in the IoT are often interconnected, and a single message may not reflect the overall situation. For example, a temperature sensor reading rising slowly may be normal, but a sharp rise in a short period could indicate a fire. If scheduling is based solely on the static priority of individual messages, important compound events may be missed, leading to delayed processing of critical information and impacting the system's responsiveness to complex events.

[0131] Therefore, this embodiment aims to infer higher-level events from multiple related messages through context awareness and dynamically adjust message priorities to achieve more intelligent scheduling.

[0132] Spatial correlation: Detects abnormal clustering within a region by utilizing the geographical location of devices or network topology. This is based on the principle that "the credibility of anomalies is higher when multiple independent devices report anomalies simultaneously."

[0133] Logical Relationships: Based on the business logic relationships between devices, such as multiple sensors on a production line, complex event processing technology is used to identify composite events across devices. This embodies the systems thinking that "the whole is greater than the sum of its parts."

[0134] Time-series correlation: Analyze the changing trends of data from the same device or topic to capture abrupt or gradual patterns. This is based on the principle that "the deterioration of a situation often has a process, and early trend changes may foreshadow major events."

[0135] Through these three types of rules, the system can extract high-priority composite event information from low-priority raw data, thereby giving these messages higher priority during scheduling and ensuring that critical events are processed in a timely manner.

[0136] Specifically, in the edge dispatch gateway, the context-aware module operates as an independent component. It subscribes to all messages passing through the gateway and performs real-time analysis. First, it predefines association event rules as described above. These rules can be dynamically updated via configuration files or cloud-based policies. The context-aware module listens for all messages flowing into the gateway and caches them according to dimensions such as device, topic, and region. The caching time is determined based on the rule's time window. For each new message, the module checks if a rule matches it. Matching logical association rules using a complex event processing engine may require pattern recognition across multiple messages. For time-series associations, it maintains historical data sequences for each device / topic and calculates trends.

[0137] Furthermore, when the context-aware module detects that any associated event rule is satisfied, it increases the priority in at least one of the following ways:

[0138] Modify the metadata of the relevant message to raise its initial priority level to the predetermined level;

[0139] An emergency event flag is added to the relevant message, and the secondary priority determination module of the edge scheduling gateway is triggered to recalculate its priority with the highest weight;

[0140] Generate and publish a new high-priority alarm message to a predetermined alarm topic. The alarm message includes a summary of the associated event, a trigger rule identifier, and recommended handling suggestions.

[0141] Finally, the adjusted message is output to the corresponding queue in the hybrid queuing model.

[0142] Therefore, this embodiment, through multi-source information fusion, enables the system to identify complex events that a single sensor cannot detect, such as regional anomalies and equipment linkage failures, allowing for earlier intervention. Messages that were originally low-priority may be elevated due to contextual association, entering the emergency queue for rapid processing. This avoids delays in important events due to low initial priority. Context awareness and priority adjustment at the edge reduce the amount of data uploaded to the cloud while ensuring rapid reporting of critical events. Rules can be dynamically updated, allowing the system to adapt to different scenario requirements; multi-rule association reduces false alarms and missed alarms, making alarms more reliable; different business scenarios can define different association rules, tightly integrating scheduling strategies with business logic to achieve true business-driven scheduling.

[0143] In one embodiment, the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the functions of a hierarchical MQTT message priority scheduling system for massive terminals as described in any of the above embodiments. The system includes:

[0144] The terminal agent module, deployed on a massive number of terminals, is used to generate metadata for MQTT messages to be published. The metadata includes an initial priority identifier and message value decay attributes.

[0145] The edge scheduling gateway is deployed on the gateway between the terminal and the cloud platform. It is used to receive MQTT messages published by the terminal within the jurisdiction, and to perform secondary priority determination and scheduling of messages based on at least one of metadata, local network status and computing load, and to perform selective aggregation or caching of low-priority messages.

[0146] The cloud-based collaborative scheduler communicates with multiple edge scheduling gateways to receive status summaries from each gateway and dynamically distributes scheduling policy parameters to each edge scheduling gateway based on global business objectives and resource status, enabling the edge scheduling gateways to perform local scheduling. The scheduling policy parameters include at least priority mapping weights and bandwidth quotas.

[0147] Please see Figure 2 , Figure 2 This is a schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention.

[0148] The electronic device includes a processor, a memory, an input device, and an output device. The processor, memory, input device, and output device are coupled together via connectors, which may include various interfaces, transmission lines, or buses, etc., and are not limited in this respect in the embodiments of the present invention. It should be understood that in the various embodiments of the present invention, coupling refers to mutual connection through a specific method, including direct connection or indirect connection through other devices, such as through various interfaces, transmission lines, buses, etc.

[0149] The processor can be one or more graphics processing units (GPUs). If the processor is a GPU, the GPU can be a single-core GPU or a multi-core GPU. Optionally, the processor can be a processor group consisting of multiple GPUs, with the multiple processors coupled to each other via one or more buses. Optionally, the processor can also be other types of processors, etc., which are not limited in this embodiment of the invention.

[0150] The memory can be used to store computer program instructions, as well as various types of computer program code, including program code for executing the present invention. Optionally, the memory includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or portable read-only memory (CD-ROM), which is used for related instructions and data.

[0151] Input devices are used to input data and / or signals, and output devices are used to output data and / or signals. Input and output devices can be independent devices or an integrated device.

[0152] It is understood that in this embodiment of the invention, the memory can be used not only to store related instructions, but also the specific data stored in the memory is not limited.

[0153] Understandable, Figure 2 This is merely a simplified design of an electronic device. In practical applications, the electronic device may also include other necessary components, including, but not limited to, any number of input / output devices, processors, memory, etc., and all video analysis devices that can implement embodiments of the present invention are within the protection scope of the present invention.

[0154] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

Claims

1. A hierarchical MQTT message priority scheduling system for massive terminals, characterized in that, The system includes: The terminal agent module, deployed on a massive number of terminals, is used to generate metadata for MQTT messages to be published. The metadata includes an initial priority identifier and message value decay attributes. The edge scheduling gateway is deployed on the gateway between the terminal and the cloud platform. It is used to receive MQTT messages published by the terminal within the jurisdiction, and to perform secondary priority determination and scheduling of messages based on at least one of metadata, local network status and computing load, and to perform selective aggregation or caching of low-priority messages. The cloud-based collaborative scheduler communicates with multiple edge scheduling gateways to receive status summaries from each gateway and dynamically distributes scheduling policy parameters to each edge scheduling gateway based on global business objectives and resource status, enabling the edge scheduling gateways to perform local scheduling. The scheduling policy parameters include at least priority mapping weights and bandwidth quotas. The terminal agent module is also used to: calculate the message value decay attribute based on the initial urgency and business type of the MQTT message and a preset value decay function model; the value decay function model is determined based on the initial message value and the effective decay coefficient. The effective attenuation coefficient is determined based on the end-to-end expected delay sensitivity factor, the terminal state uncertainty factor, and the cloud feedback correction factor. Specifically, the value decay function model is as follows: ； ； In the formula, For the message at the moment Its current value This refers to the lifetime of the message since its generation. The initial value of the message. It is a natural constant. For effective attenuation coefficient, Based on the attenuation coefficient, These are the weighting coefficients. End-to-end expected delay sensitivity factor For the uncertainty factor of the terminal state, Correction factors are provided for feedback from the cloud. The end-to-end expected latency sensitivity factor is calculated as follows: ； In the formula, This represents the average round-trip time currently measured. Historical baseline for end-to-end links Preset The tolerance threshold takes a value in the range [0, 1]. The terminal state uncertainty factor is calculated as follows: ； In the formula, This is the time interval since the last heartbeat / status update from the terminal was received. This is a normal heartbeat cycle. To tolerate timeout windows; The cloud-based feedback correction factor is calculated as follows: ； In the formula, This represents the percentage of messages that were actually processed within the window in the past. The system's expected utilization threshold. The scaling factor is used to control the feedback strength and satisfies... .

2. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 1, characterized in that, The low-priority messages are MQTT messages whose initial priority identifier is lower than the first threshold; The aggregation operation includes: merging multiple MQTT messages that meet the aggregation conditions within a predetermined time window or data volume window to generate an aggregated message; assigning a new priority to the aggregated message and then forwarding it.

3. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 1, characterized in that, The edge scheduling gateway has a hybrid queuing model inside, which is used to manage the message queue to be processed; The hybrid queuing model includes at least: a high-priority emergency queue, a time-sensitive queue that considers message lifespan and deadline, and a weighted fair queue to ensure service fairness.

4. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 3, characterized in that, The emergency queue is a message queue whose priority level is greater than the second threshold in the secondary priority determination result; The time-sensitive queue is a queue generated by determining the deadline based on the message value decay attribute or business rules, determining the remaining validity time of the message based on the deadline and the current time, and sorting the queues according to the remaining processing time. The weighted fair queue is a queue that classifies messages according to their business source and assigns weights to each business flow. The edge scheduling gateway is also used to extract messages from the weighted fair queue using a weighted round-robin algorithm.

5. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 3, characterized in that, The cloud-based collaborative scheduler is also used for: Based on the status summary of each edge scheduling gateway, the load ratio of emergency queue messages in the message queue to be sent and the corresponding link quality indicators between the edge scheduling gateway and the cloud are extracted. Using the total available bandwidth resources of the entire network as a constraint, a target optimization function is constructed with the goal of minimizing the overall emergency queue message latency; where the bandwidth quota allocated to each edge scheduling gateway is directly proportional to the load proportion of emergency queue messages and inversely proportional to the reciprocal of the link quality index; The bandwidth quota value is obtained by solving the objective optimization function and is sent to the corresponding edge scheduling gateway as part of the scheduling strategy parameters.

6. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 1, characterized in that, The edge scheduling gateway is equipped with a context-aware module; The context-aware module is used to monitor and analyze multiple messages from the same region, associated devices, or associated topics; when any preset associated event rule is detected, the priority of the corresponding message is automatically increased.

7. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 6, characterized in that, The associated event rules include: Spatial association rules, determined based on the device's geographical location or network topology, are configured to be triggered when the number of abnormal events occurring within a preset time window in the same area exceeds a certain threshold. Logical association rules, determined based on the business logic relationships between devices, are configured to be triggered when the combination of data reported by multiple associated devices meets a preset complex event pattern; Time-series association rules: Based on the data change trend of the same device or topic, they are configured to be triggered when the continuously reported data value or change rate exceeds the change rate threshold.

8. The hierarchical MQTT message priority scheduling system for massive terminals according to claim 1, characterized in that, The topic name of the MQTT message is encoded using a hierarchical structure, and the topic name contains at least one priority field for explicitly identifying the message; Both the edge scheduling gateway and the cloud collaborative scheduler are equipped with a topic parsing and routing module, which is used to parse the priority field in the topic name in order to identify and differentiate message streams with different priorities.

9. An electronic device, characterized in that, Including the hierarchical MQTT message priority scheduling system for massive terminals as described in any one of claims 1 to 8.

Images