Multi-channel line selection scheduling method for coping with communication co-frequency collision

Abstract

The invention discloses a multi-channel line selection scheduling method for coping with communication co-frequency collision, and belongs to the technical field of wireless communication. According to the method, an intelligent scheduling center located on a communication physical layer is established, and an original service data packet from an upper-layer application is recombined; thirdly, assigning three types of identifiers, namely a channel, a service level and a priority, to the data packet through service layer calibration; then, the line selector accurately distributes the data packets to the most appropriate LoRa channel queue according to channel identifiers and the like, and cooperative shunting of communication loads is achieved; and finally, in the queue, the sending position of the data packet is dynamically adjusted based on the priority mark, and the high-priority data can jump the queue and is sent by the LoRa module bound at the head of the queue. According to the method, the data are shunted and scheduled from the service application layer, so that co-frequency collision can be avoided fundamentally, the network throughput and the channel utilization rate are improved remarkably, the real-time performance and the service quality of key services are guaranteed through a priority mechanism, and the method has higher application value.

Description

Technical Field

[0001] The present application relates to the field of wireless communication technology, and more specifically, to a multi-channel line selection scheduling method for coping with communication co-frequency collisions. Background Art

[0002] LoRa technology, a core low-power wide-area network (LPWAN) communication technology, plays a key role in the Internet of Things, industrial automation, smart cities, and other fields thanks to its advantages such as long range, low power consumption, and high sensitivity. However, LoRa communication is inherently a narrowband communication technology, with relatively limited available channel and frequency band resources. Therefore, in high-density deployment scenarios such as the Industrial Internet of Things, when a large number of end nodes need to communicate concurrently within the same near-field airspace, competition for channel resources inevitably leads to serious co-channel interference. These interferences not only directly result in packet loss and reduced communication success rates, but also increase data retransmission overhead, severely impacting overall network throughput and service reliability. Despite continuous optimization efforts at the physical layer, these efforts have gradually reached performance bottlenecks. Therefore, how to overcome the limitations of the physical layer and construct a more efficient multi-channel scheduling mechanism from a new perspective to systematically address the co-channel interference problem in multi-node concurrent communication has become a pressing technical challenge in the development of LoRa technology.

[0003] To address the above challenges, existing technologies mainly adopt the following solutions, but all of them have limitations to varying degrees:

[0004] One is based on the optimization of the communication physical layer, such as prior art 1, US20180132169A1. For example, different signals are distinguished by dynamically adjusting the spreading factor (SF) and coding rate (CR), or channel sensing (Listen Before Talk, LBT) and forward error correction (FEC) mechanisms are introduced to passively avoid conflicts. However, the essence of this method still does not change the physical constraints of single-channel transmission. In the scenario where the number of terminal nodes increases sharply, optimizing the physical layer parameters can only reduce the probability of collision to a certain extent, and cannot fundamentally solve the risks of channel capacity saturation and overload. The performance improvement has reached the theoretical bottleneck allowed by the Shannon limit.

[0005] The second approach is to use a static multi-channel allocation scheme, such as prior art 2, CN110519847A. This scheme pre-allocates fixed, non-interfering physical frequency bands to different nodes or service types, enabling parallel transmission. The main drawback of this scheme is its rigid resource allocation. It cannot adaptively adjust to real-time dynamic changes in network load. This often results in some channels being constantly busy and accumulating data due to high-load services, while other channels remain underloaded or even idle for long periods of time. This results in significant channel resource waste and low overall network utilization.

[0006] The third approach is to use a retransmission mechanism based on collision detection, such as in Existing Technology 3, document "LoRa Network Collision Probability Modeling and Optimization." Upon detecting a data collision or transmission failure, the terminal device resends the data packet after a random delay. This approach results in frequent listening and retransmission operations in high-density networks, significantly increasing terminal energy consumption and contradicting the original intention of LoRa technology as a low-power IoT solution. Furthermore, the additional delay and uncertainty introduced by retransmissions make it difficult to meet the stringent requirements for real-time and continuous service in scenarios such as industrial control.

[0007] In summary, existing technologies are either limited to physical layer optimization or have problems such as low resource utilization, high energy consumption, and inability to ensure business continuity. They are unable to provide a systematic solution that can balance high throughput, high reliability, and low power consumption to effectively address the challenges of co-frequency collisions in high-density deployments. Summary of the Invention

[0008] In order to overcome the limitations of the prior art, according to one aspect of the present application, a multi-channel line selection scheduling method for coping with communication frequency collision is provided, which includes:

[0009] Obtain original business data packets from upper-layer application systems;

[0010] Reorganizing the original service data packet based on a standard data frame format to obtain a service data packet;

[0011] Performing service layer calibration on the service data packet to obtain a channel identifier, a service layer identifier, and a priority tag;

[0012] Based on the channel identifier and / or the service level identifier, the line selector allocates the service data packet to the most appropriate LoRa channel queue;

[0013] In the most suitable LoRa channel queue, dynamically adjusting the position of the service data packet based on the priority tag;

[0014] When the service data packet is at the front end of the most suitable LoRa channel queue, the service data packet is sent through the LoRa module bound to the most suitable LoRa channel queue.

[0015] Compared with the existing technology, the main purpose of the multi-channel line selection and scheduling method for co-frequency collisions of communications provided by this application is to overcome the bottlenecks and shortcomings of the existing technology, that is, it is no longer limited to the optimization of the physical layer or the static and inefficient resource allocation method, but aims to provide an innovative multi-channel line selection and scheduling method for co-frequency collisions of communications. The core goal of this method is to start from the business application layer and build a multi-channel diversion mechanism that can intelligently perceive business needs and dynamically coordinate network resources, so as to fundamentally solve the channel congestion and co-frequency collision problems in high-density deployment environments, so as to meet the stringent requirements of modern industrial Internet of Things and other scenarios for high communication throughput, high reliability and strong real-time performance.

[0016] Specifically, the core concept of this method lies in establishing an intelligent scheduling hub located above the physical communication layer. This scheduling hub first standardizes and restructures all raw service data packets flowing in from upper-layer application systems, encapsulating them in a digital envelope containing key scheduling instructions. Next, the method performs refined service-layer calibration on each service data packet, a step that is the cornerstone of intelligent scheduling. It assigns three key identifiers to each data packet: a channel identifier based on the device's geographic location or functional partitioning, used to achieve macro-level hard isolation of physical channels; a service-level identifier based on service attributes, used to differentiate service policies; and a priority tag based on service real-time requirements, used to ensure the timely transmission of critical data. After data calibration, the line selector, acting as an intelligent sorting system, accurately assigns data packets to the most appropriate LoRa channel queue based on the packet's channel and service-level identifiers, achieving the goal of collaboratively distributing the overall communication load across multiple parallel channels. Furthermore, within a single channel queue, the present invention introduces a dynamic adjustment mechanism based on priority marking, that is, high-priority data packets can override the normal queuing order and achieve instant queue interruption, thereby ensuring the service quality of emergency or critical business at the micro level.

[0017] By adopting the above-mentioned technical concept of top-level design and collaborative scheduling from the business layer, the present invention can bring significant beneficial effects.

[0018] First, this method achieves physical isolation of communication loads by actively distributing different data streams to multiple physical channels with fixed frequencies, fundamentally avoiding the occurrence of same-frequency collisions and significantly improving the success rate of data packet transmission.

[0019] Secondly, this intelligent line selection mechanism based on business needs enables the network to dynamically utilize all channel resources, avoiding the resource waste phenomenon of busy channels always busy and idle channels always idle under the traditional static allocation method, thereby significantly improving the overall network throughput and channel utilization.

[0020] Finally, by implementing priority scheduling in the channel queue, high-value data such as emergency alarms and critical controls can always pass first, which greatly guarantees the continuity and real-time performance of core businesses, making the LoRa network capable of application scenarios with more stringent reliability requirements, and having stronger practical application value and wider applicability. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The above and other purposes, features, and advantages of the present application will become more apparent through a more detailed description of the embodiments of the present application in conjunction with the accompanying drawings. The accompanying drawings are intended to provide a further understanding of the embodiments of the present application and constitute a part of the specification. Together with the embodiments of the present application, they are used to explain the present application and do not constitute a limitation of the present application. In the drawings, the same reference numerals generally represent the same components or steps.

[0022] Figure 1 This is a flowchart of a multi-channel line selection and scheduling method for coping with communication co-frequency collision according to an embodiment of the present application.

[0023] Figure 2 This is a flowchart of the multi-channel line selection scheduling method for coping with communication frequency collision according to an embodiment of the present application, in which the line selector allocates the service data packet to the most suitable LoRa channel queue based on the channel state matrix.

[0024] Figure 3 This is another flowchart of the multi-channel line selection scheduling method for coping with communication frequency collision according to an embodiment of the present application, in which the line selector allocates the service data packet to the most suitable LoRa channel queue based on the channel state matrix.

[0025] Figure 4 This is another flow chart of a multi-channel line selection and scheduling method for coping with communication co-frequency collision according to an embodiment of the present application.

[0026] Figure 5 This is another flowchart of a multi-channel line selection and scheduling method for coping with communication co-frequency collision according to an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. While the drawings illustrate certain embodiments of the present disclosure, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0028] Therefore, in response to the technical defects disclosed in the background technology, the present application proposes a multi-channel line selection scheduling method to deal with communication co-frequency collisions. Figure 1 This is a flowchart of a multi-channel line selection and scheduling method for coping with communication co-frequency collision according to an embodiment of the present application. Figure 4 This is another flow chart of a multi-channel line selection and scheduling method for coping with communication co-frequency collision according to an embodiment of the present application. Figure 5 Another flow chart of a multi-channel line selection scheduling method for coping with communication frequency collision according to an embodiment of the present application

[0029] like Figure 1 、 Figure 4 and Figure 5 As shown, according to an embodiment of the present application, the multi-channel line selection scheduling method for dealing with communication co-frequency collisions includes: S1, obtaining an original business data packet from an upper-layer application system; S2, reorganizing the original business data packet based on a standard data frame format to obtain a business data packet; S3, performing business layer calibration on the business data packet to obtain a channel identifier, a business layer identifier and a priority tag; S4, based on the channel identifier and / or the business layer identifier, the line selector allocates the business data packet to the most suitable LoRa channel queue; S5, in the most suitable LoRa channel queue, dynamically adjusting the position of the business data packet based on the priority tag; and, S6, when the business data packet is at the front end of the most suitable LoRa channel queue, sending the business data packet through the LoRa module bound to the most suitable LoRa channel queue.

[0030] In step S1, the original service data packet is obtained from the upper-layer application system. That is, the multi-channel line selection and scheduling method for co-channel communication collision begins with obtaining the original service data from the upper-layer application system. This step is the foundation and data entry point for the entire multi-channel line selection and scheduling process.

[0031] In practice, this step consists of two core steps: first, implementing interface monitoring and data reception, and second, loading metadata. During this phase, one or more standard communication interfaces are pre-existing, such as a RESTful API endpoint, a WebSocket service, a TCP / IP socket listening port, or a message queue (such as RabbitMQ or Kafka) that subscribes to a specific topic. These interfaces remain in a listening or active state, awaiting connections or data pushes from upper-layer applications. When an upper-layer application, such as a factory's Manufacturing Execution System (MES), IoT cloud platform, or Supervisory Control and Data Acquisition (SCADA), generates a business event (such as a sensor reading or control command), it sends a data packet containing the event information to the interface using a pre-agreed protocol. The service process deployed on this interface then receives the data, typically in the form of a raw, unprocessed byte stream or string, such as a JSON or XML text file containing business information. Next, the metadata loading phase begins, the design of which is closely linked to subsequent business-layer calibration. In order to support the metadata parsing of the business data packet in the subsequent business layer calibration to obtain the device ID and data type, this acquisition step must ensure the integrity of key information when loading the data. This means that this step is not just data reception at the physical level. Its inherent requirement is that the received data packet must contain metadata that can fully identify its source and nature. Specifically, when the system performs the acquisition operation, it will receive and cache the original business data packet containing key information such as device ID and data type as a whole to ensure that this information enters the processing flow of this method accurately and prepares all the original data elements for the subsequent automated analysis and calibration steps.

[0032] It's worth noting that in this embodiment, the "original business data packet" refers to the initial data unit generated by the upper-level application system based on its own business logic, without any formatting modification or header information additions performed by this method. The format and content of this data packet are defined by the upper-level application system. It carries the core business intent and is the original material containing all the information to be processed.

[0033] In order to more intuitively demonstrate the execution process of this acquisition step, the embodiment of the present application is illustrated with the application scenario of a smart factory. In this scenario, the factory central monitoring platform, which serves as the upper-level application system, needs to issue an emergency command to shut down a core stamping equipment that is overheating due to abnormal temperature. At this time, the monitoring platform will generate an original business data packet, the content of which may be a string in JSON format. The specific example is: {"device_id":"T-A01-Stamp-003","data_type":"alert","command":"shutdown","value":{"temperature":152.0,"unit":"℃"}}. Subsequently, the monitoring platform sends this JSON string to the / api / v1 / data interface preset by this scheduling method via an HTTP POST request. In this method, a functional module responsible for obtaining the original business data packet will completely read all the contents of its request body, that is, the above-mentioned JSON string, after listening to this HTTP request. At this point, the acquisition step is completed. It successfully loads an original business data packet from a specific business scenario, which contains a clear device ID (T-A01-Stamp-003), data type (alert), and other business information, into the system memory intact, and is ready to be handed over to the next step of the process for reorganization based on the standard data frame format.

[0034] In step S2, the original service data packets are reassembled based on a standard data frame format to obtain a service data packet. That is, after successfully receiving the original service data packets, they are reassembled based on a standardized data frame format to obtain a structured service data packet. This step is the structural foundation for all subsequent intelligent scheduling, unifying and organizing raw data from different upper-layer applications in various formats into a standard data carrying system.

[0035] The technical purpose of this step is to address data heterogeneity and establish data format consistency within the system. The raw business data packets generated by upper-layer application systems vary significantly in format, length, and encoding. Directly processing such heterogeneous data would require the scheduling system to write a large amount of complex adaptation logic, which would not only lead to redundant and bloated systems but also make them difficult to maintain and prone to errors. Therefore, all incoming data is uniformly encapsulated using a standard data frame format. This process is similar to loading a variety of cargo (raw data) into a standardized container. The advantage of this approach is that subsequent scheduling modules (such as the route selector and queue manager) do not need to be concerned with the specific contents of the container; they only need to operate according to a unified and predictable container structure. Furthermore, this step focuses on reorganization and structuring. By adding identifiers and unifying data format information, a standardized information mounting point is pre-established for subsequent business-layer identifiers, laying a solid foundation for automated intelligent scheduling.

[0036] During the implementation process, a standard data frame format specifically designed for this method is predefined during the system design phase. This format is a rigorous data structure template, typically consisting of two core components: a fixed- or variable-length header and a subsequent payload. The header field is crucial, being designed to store all subsequent scheduling control information. Therefore, upon receiving the original service data packet, a new data structure instance conforming to this standard data frame format is first created in memory. Next, header space is allocated and initialized. The system allocates a specified amount of storage space for each field in the header information (e.g., for the subsequent channel identifier, service level identifier, priority tag, data sequence number, and payload length) according to the predefined format. These fields can be initialized to zero or specific default values; their actual values ​​will be calculated and populated during the subsequent service layer calibration step. The next step involves payload encapsulation. The system places the previously acquired, complete, unmodified original service data packet intact into the reserved payload position within the newly created data structure. At the same time, the system calculates the actual byte length of the original service data packet and immediately writes this length value into the payload length field of the header. This action is crucial to ensure that the data receiver can accurately separate the header and payload from the entire data stream. After the above operations, a new, structured service data packet is generated. It not only carries the complete original service information but also has a standardized header, preparing it for the next step of service layer calibration.

[0037] It is worth mentioning that in the embodiments of this application, the standard data frame format refers to the unified data encapsulation specifications and structural blueprint followed within this scheduling method. It is a protocol that all subsequent data processing modules must adhere to to ensure the consistency and predictability of data interactions within the system. The service data packet specifically refers to the output result generated after executing this reorganization step. It fundamentally differs from the original service data packet in that the latter is a pure content payload, while the former is a composite data object that includes the latter as its payload and has a standardized header and structured form.

[0038] To make the above process description more concrete, this embodiment continues to use the previous smart factory emergency shutdown scenario for explanation. After the system has received the original business data packet in the form of a JSON string with the content {"device_id":"T-A01-Stamp-003",...}, the step of reorganizing the original business data packet based on the standard data frame format will be initiated. Assuming that the standard data frame format defined in this method has a header consisting of 6 bytes, which are used to store the channel ID (Channel ID), layer ID (Layer ID), priority ID (Priority ID), sequence number (Sequence Number, occupying 2 bytes) and payload length (Payload Length).

[0039] In this scenario, the system allocates a new memory space, with the first six bytes reserved for the data header. The system places the original JSON string as an indivisible data block (the payload) after this six-byte header. The system calculates the actual length of the JSON string—assuming it's 80 bytes, for example—and writes the value 80 into the payload length field within the six-byte header. Meanwhile, other header fields, such as the channel ID, are temporarily set to zero. The reassembly process is now complete. The previously unformatted JSON string has been transformed into a new, structured service data packet. In memory, it appears as a continuous data block, such as [0|0|0|0|80]+["{"device_id":"...",...}"], with the first portion being the initialized header and the second portion being the complete original payload. This processed service data packet is ready for seamless processing by subsequent calibration modules because it has a standard structure that all modules recognize and trust.

[0040] In step S3, the service data packets are subjected to service-layer calibration to obtain channel identifiers, service level identifiers, and priority tags. That is, after successfully reorganizing the original data into standardized service data packets, the service data packets are subjected to service-layer calibration to obtain the corresponding channel identifiers, service level identifiers, and priority tags. This step constitutes the decision-making core of the entire intelligent scheduling mechanism. It assigns clear scheduling instructions to previously unprocessed data packets, transforming them from passive communication payloads into active participants with clear scheduling intent.

[0041] The technical purpose of this step is to achieve a strategic shift from passive collision avoidance to active collaborative traffic diversion. Traditional communication methods often only deal with conflicts at the physical resource level, but this method takes a different approach. Its fundamental focus is to pre-plan communication paths by deeply understanding the attributes of the service itself, thereby avoiding conflicts at the source. The purpose of this step is to achieve a deep understanding and digital translation of the service. It does this by attaching refined labels to each data packet, namely the channel identifier, service level identifier, and priority tag mentioned above, thereby converting abstract service requirements (such as indicating "this data comes from workshop A" or "this data is an emergency alarm") into machine-readable and executable scheduling instructions. As also explained in the design scheme of the present invention, the system performs data segmentation, layering, and hierarchical processing, so that incoming data packets carry these three classification identifiers, so that the subsequent line selector and queue manager can perform accurate physical channel allocation and queue priority adjustment based on them. Therefore, without the three key identifiers generated in this step, the subsequent intelligent line selection and dynamic queue interruption mechanism will be impossible to implement.

[0042] The technical implementation of this step is an automated decision-making process based on preset rules and real-time analysis. This process is refined to the operational level and can be decomposed into two closely connected links: first, metadata analysis; second, table lookup or rule matching based on the analysis results to determine the three core identifiers. In a specific implementation method, in order to calibrate the service data packet and ultimately obtain the channel identifier, service level identifier and priority tag, the following operations are included: first, the service data packet is subjected to metadata analysis to obtain the device ID and data type; then, based on this device ID and data type, the required channel identifier, service level identifier and priority tag can be determined.

[0043] Specifically, during the metadata parsing phase, the system focuses on the payload of the business data package encapsulated in the previous process. The system parses the payload and accurately extracts two key metadata fields: the device ID and the data type. For example, if the payload is in JSON format, the system can retrieve the corresponding values ​​by field names (such as device_id and data_type). This process is similar to removing the shipping label from a courier package to understand the specific origin and nature of the goods. After successfully obtaining the device ID and data type, the system immediately proceeds to the second phase: determining the three aforementioned identifiers based on the parsing results. This process relies on three independent sets of preconfigured logical rules or mapping tables in the system. The system uses the parsed metadata as query input and uses these rules to derive the output.

[0044] The process of determining channel identifiers is primarily based on the device ID and the application of relevant sharding rules. In the specific concept of this method, sharding involves dividing the distribution area covered by LoRa terminals into multiple independent regions (this division can be implemented based on functional scenarios). Each region is assigned a channel, occupying a separate frequency band. Based on this, the system maintains a mapping table of device IDs to channels, such as {"T-A01-.":1,"T-B01-.":2,...}. When the parsed device ID is T-A01-Stamp-003, the system can determine its corresponding channel identifier as 1 by querying this table or performing a regular expression match. Determining service level identifiers implements tiering rules. Similarly, the concept states that tiering involves classifying LoRa terminals into different levels based on their service attributes. Based on the parsed data type or the device function implied by the device ID, the system queries another mapping table dedicated to service levels. For example, {"alert":0x01,"control":0x02,"telemetry":0x03}. If the parsed data type is alert, the service level identifier is determined to be 0x01. Finally, the priority tag is determined to implement the tiering rules. The system will prioritize based on service urgency, for example, categorizing it into levels 1 to 10. This priority mechanism will allow high-priority messages to be dynamically queued for delivery. The system can also make decisions based on data type or more complex business logic, such as defining a rule: IF data_type == 'alert' THEN priority = 1; ELSE IF device_id LIKE 'core_equip_%' THEN priority = 3; ELSE priority = 8.

[0045] After determining the specific values ​​for the channel identifier, service level identifier, and priority tag, the system writes them into the corresponding fields within the header reserved during the previous step of reassembling the service data packet. This completes the entire service layer calibration process, and a standard service data packet is now assigned complete scheduling instructions, transforming into an intelligent data packet.

[0046] It is worth mentioning that in the technical solution of this application, the channel identifier is an identifier that directly or indirectly points to a specific physical LoRa channel (i.e., frequency). It is mainly used to implement macro traffic segmentation based on space or functional partitioning. The service level identifier is a classification label used to distinguish different service properties (such as control, monitoring, and alarm), providing a basis for differentiated services. The priority tag is a numerical value indicating the urgency of data packet transmission, which will directly determine the order in which the data packet is sent in the same channel queue.

[0047] That is, in the embodiment of the present application, the process of performing service layer calibration on the service data packet to obtain a channel identifier, a service level identifier, and a priority tag includes: performing meta information parsing on the service data packet to obtain a device ID and a data type; and determining the channel identifier, the service level identifier, and the priority tag based on the device ID and the data type.

[0048] To further illustrate the abstract description above, let's continue using the emergency shutdown scenario as an example. In the previous step, a service data packet with an empty header field and a payload containing the emergency shutdown JSON content was obtained. Now, the service layer identification step begins: The first step is metadata parsing: the system parses the JSON payload and extracts "device_id": "T-A01-Stamp-003" and "data_type": "alert". The second step is to determine the identifier based on the parsed results: Next, the channel identifier is determined: the system queries the sharding rule table. Suppose the rule defines that all devices in the "A01" area use channel 5. Therefore, the channel identifier is determined to be 5. Next, the service level identifier is determined: the system queries the hierarchical rule table. The rule defines that the alert type belongs to the emergency alarm level, and its corresponding service level identifier is 0x01. Finally, the priority tag is determined: the system queries the hierarchical rule table. The rule specifies that the alert type has the highest priority tag, 1. The third step is to write the result: the system writes the values ​​5, 0x01, and 1 into the Channel ID, Tier ID, and Priority ID_ fields of the service packet header, respectively. After this calibration step is completed, the service packet, which originally had a header of [0|0|0|...], now has its header updated to [5|1|1|...]. This calibrated packet clearly indicates its destination (channel 5) and declares its identity (emergency alarm) and privilege (highest priority), paving the way for precise and accurate dispatch.

[0049] In step S4, based on the channel identifier and / or the service level identifier, the line selector allocates the service data packet to the most appropriate LoRa channel queue. That is, after the service data packet has been accurately calibrated, the method officially enters its core decision-making and allocation phase, namely, executing the key step of allocating the service data packet to the most appropriate LoRa channel queue through the line selector based on the channel identifier and / or the service level identifier. This step constitutes a bridge connecting data understanding and physical execution, and its function is like that of an intelligent traffic dispatcher, responsible for guiding data packets carrying clear instructions to the correct, unobstructed physical transmission channel.

[0050] The technical purpose of this step is to convert logical-level scheduling instructions into physical-level resource allocation actions. The service-layer calibration in the previous step merely labels the data packets for their destinations; the data packets themselves do not move autonomously. The core value of this step lies in reading these labels and dynamically and intelligently determining which physical transmission path is currently most suitable, then executing the so-called distribution action. Specifically, after data processing is complete, the selector distributes the data to different channels. This selector distribution is a critical step in the entire scheduling process, ensuring that identified data packets are ultimately delivered to their predetermined or optimal channel queues. Specifically, in this embodiment of the present application, the most suitable LoRa channel queue means that the allocation is not a rigid, simple one-to-one mapping, but rather incorporates adaptability to the dynamic changes in real-world channels. This is a core advantage over traditional static allocation methods. The technical implementation of this step is a comprehensive decision-making process that combines rule-driven and state-aware approaches. It is not a single, isolated action, but rather consists of multiple sub-steps of intelligent distribution logic.

[0051] In a specific embodiment of the present application, first of all, at the most basic execution level, it is necessary to obtain the real-time operating status of all LoRa channel queues, and this measure is to obtain a channel state matrix. This channel state matrix forms the basis for the line selector to make decisions. For example, each row vector in the channel state matrix can represent the status information of each channel, and this status information may include the status of the location, occupancy, queue length, and recent error rate. This series of information together constitutes a real-time portrayal of the health and busyness of each physical channel. In the design of the entire mechanism, it is also clear that the system will poll and monitor the status of each channel in place, as well as the occupancy or idleness, in order to maintain this channel state matrix.

[0052] Secondly, after establishing a foundation for state awareness, the selector's decision-making process officially begins. This is a hierarchical decision-making process. The first-level decision (Plan A) is based on a predetermined channel allocation. The process begins by identifying a predetermined channel for the service data packet based on the channel identifier. This is the most direct routing method. Next, the system performs a health check on the predetermined channel: it examines the corresponding row vector in the channel status matrix mentioned above and determines whether the predetermined channel's presence is healthy and its occupancy is idle. If these checks pass, the system further determines the channel's congestion level. Specifically, if the presence and occupancy of the predetermined channel are healthy and idle, it determines whether its queue length exceeds a preset threshold. If all these checks pass—meaning the hardware is healthy, the channel is idle, and the queue is not long—the system makes the final allocation. If the queue length of the predetermined channel does not exceed the preset threshold, the predetermined channel is designated as the most suitable LoRa channel queue.

[0053] Furthermore, when Plan A fails to execute, the system will initiate its second-layer decision (Plan B), which is to perform failover or load balancing. This backup logic can be designed as follows: in response to the predetermined channel's in-place status being faulty or under maintenance, and its occupancy being occupied, it will actively query the channel status matrix and use this as a basis to determine the most suitable LoRa channel queue at the moment. The definition of optimal here has specific calculation or comparison criteria. For example, the selected most suitable LoRa channel queue should be in-place healthy, idle, with the shortest queue length among all alternative channels, and the lowest recent error rate. This means that the line selector will traverse all other healthy, idle channels and select a channel with the lowest comprehensive load and the best communication quality as an alternative path.

[0054] It is worth mentioning that in the embodiment of the present application, the line selector refers to a software logic part that implements all the aforementioned decisions and places the data packet entity into the target queue. The LoRa channel queue refers to the data buffer area associated with each physical LoRa transmitting module. It is a first-in-first-out (FIFO) queue in its basic form, but its internal order can be changed by the subsequent priority adjustment mechanism. The most suitable LoRa channel queue is the result of a dynamic evaluation, which is calculated in real time based on the channel status matrix. It may be a predetermined channel (when it is in good condition) or a backup channel with the best comprehensive score (when there is a problem with the predetermined channel).

[0055] That is, in this embodiment, the process of the line selector allocating the service data packet to the most appropriate LoRa channel queue based on the channel identifier and / or the service level identifier includes: obtaining a channel state matrix; and, based on the channel state matrix, the line selector allocating the service data packet to the most appropriate LoRa channel queue. More specifically, each row vector in the channel state matrix represents the state information of each channel, and the state information of each channel includes the in-place status, occupancy status, queue length, and recent error rate.

[0056] Figure 2 This is a flowchart of the multi-channel line selection scheduling method for co-channel collision in accordance with an embodiment of the present application, in which the line selector allocates the service data packet to the most appropriate LoRa channel queue based on the channel state matrix. Figure 2 As shown, more specifically, based on the channel status matrix, the line selector allocates the business data packet to the most suitable LoRa channel queue, including: S210, based on the channel identifier, determining the reserved channel of the business data packet; S220, checking the corresponding row vector in the channel status matrix, and determining whether the in-place status of the reserved channel is healthy and the occupancy is idle; S230, in response to the in-place status of the reserved channel being healthy and the occupancy being idle, judging whether the queue length of the reserved channel exceeds a preset threshold; S240, in response to the queue length of the reserved channel not exceeding the preset threshold, determining the reserved channel as the most suitable LoRa channel queue. At the same time, based on the channel status matrix, the line selector allocates the service data packet to the most suitable LoRa channel queue, and also includes: S250, in response to the in-place status of the predetermined channel being faulty or under maintenance and the occupancy status being occupied, querying the channel status matrix and determining the most suitable LoRa channel queue, the in-place status of the most suitable LoRa channel queue being healthy, the occupancy status being idle, the queue length being the shortest and the recent error rate being the lowest.

[0057] To more vividly illustrate the execution of this step, this example continues to use the previous smart factory scenario. In the previous step, the system has received an emergency shutdown command packet labeled with information such as [Channel_ID=5, Layer_ID=1, Priority_ID=1,...]. This packet is now submitted to the line selector. Assume that the current channel state matrix data is as shown in the following table:

[0058] Channel number In place Occupancy Queue length Recent error rate Channel 5 (reserved) OK BUSY 30 2％ Channel 6 OK IDLE 5 1％ Channel 7 OK IDLE 8 3％

[0059] First, the reserved channel is determined: the selector reads the Channel_ID 5 in the packet header and determines that the reserved channel is channel 5. Next, the reserved channel is checked: the selector examines the row vector of channel 5 in the matrix. It finds that its occupancy is BUSY, and its queue length of 30 may exceed the threshold set for emergency services. At this point, since Plan A has failed, Plan B is initiated: Given that the current status of the reserved channel is unsuitable, particularly for transmitting this priority 1 emergency command, the selector begins searching for a backup channel. Next, the backup channel is evaluated: the selector selects all channels with an OK status and an IDLE status, namely channels 6 and 7 in this table. Next, a comparison is performed to select the optimal channel: between channels 6 and 7, channel 6's queue length (5) is shorter than channel 7's (8), and its recent error rate (1%) is also lower than channel 7's (3%). Therefore, based on the aforementioned optimization criteria, channel 6 is determined to be the most suitable LoRa channel queue. Finally, the allocation operation is performed: the line selector finally makes a decision to put the emergency shutdown service data packet into the sending queue of channel 6 instead of the originally scheduled channel 5.

[0060] In another embodiment of the present application, the technical implementation of this step can also be upgraded to a more forward-looking intelligent decision-making model, which introduces a neural network based on, for example, LSTM to predict the probability of conflict. The execution process can be: first use historical data to train the model and obtain the future congestion probability prediction value; then add the prediction value to the channel state matrix to form an updated channel state matrix containing more dimensional information; finally, when making a decision, whether it is Plan A or Plan B, the system will consider factors such as hardware status, queue length, error rate, etc., and will also consider this congestion probability prediction value, giving priority to the channel that is least likely to be congested in the future. This allows the decision-making ability of the line selector to evolve from responding to the current state to being able to predict future trends.

[0061] Specifically, in this preferred embodiment, the method employs a more advanced and intelligent enhanced approach to the allocation decision-making process of its line selector. This enhanced approach goes beyond simply passively responding to the current channel state and instead utilizes techniques such as machine learning to proactively predict future channel congestion, thereby elevating allocation decisions to a new level of foresight.

[0062] In this preferred embodiment, in the process of the line selector allocating service data packets to the most suitable LoRa channel queue based on channel identification and / or service level identification, it first obtains a channel state matrix; then, the collected channel state historical time series data, service data packet arrival time distribution and node activation cycle pattern are provided as input to a trained LSTM-based conflict probability prediction model, and the model calculates the congestion probability prediction value of each channel; then, these congestion probability prediction values ​​are added to the channel state matrix to obtain an updated channel state matrix, in which the row vector of each channel includes the aforementioned in-place status, occupancy, queue length, and recent error rate, as well as a new congestion probability prediction value; finally, the decision link is based on this updated channel state matrix containing more information, and the line selector allocates the service data packet to the most suitable LoRa channel queue.

[0063] In particular, the introduction of predictive models aims to overcome the inherent limitations of real-time perception capabilities, thereby achieving a qualitative shift from reactive after-the-fact response to proactive avoidance measures. Relying solely on the real-time channel state matrix for decision-making is like a driver observing only the taillights of a nearby car; they cannot foresee that the road a kilometer away is about to become paralyzed due to some foreseeable event, such as the arrival of rush hour. In IoT applications, many data transmission behaviors exhibit strong periodicity and regularity, such as all devices collectively reporting data at the top of the hour. If the dispatching system can only passively search for alternative channels after congestion occurs, by detecting increasing queue lengths or changes in error rates, the efficiency and real-time nature of communication will have already been compromised. Therefore, by introducing a model that can learn from historical patterns and predict the future, the system can acquire a near-prophetic capability, proactively and calmly directing data flows to future idle channels before foreseeable congestion occurs, ultimately achieving truly peak-shifting communication and optimizing resource utilization. This makes the channel line selection process no longer a matter of feeling one's way across a river, but rather like navigating by looking at a future traffic map.

[0064] More specifically, the first step in implementing this preferred embodiment is to obtain a channel status matrix. This step is consistent with the aforementioned basic line selection method. The system first obtains a real-time data snapshot that includes the real-time status, occupancy, queue length, and recent error rate of all channels. This data forms the basis for subsequent predictions and decisions.

[0065] The second step in implementing this preferred embodiment involves using a model to obtain a predicted congestion probability. This step itself involves two major steps: model preparation and data input. During the system deployment phase, a collision probability prediction model based on an LSTM (Long Short-Term Memory) network is pre-trained. The LSTM model was chosen because, as a special type of recurrent neural network, it is particularly adept at processing and learning long-term dependencies in time series data. Once deployed, the trained model is periodically invoked, for example, every 10 seconds. During invocation, the system aggregates three key types of historical time series data as input feature vectors for the model: channel status historical time series data (for example, the sequence of queue length changes per second for each channel over the past hour); service packet arrival time distribution (i.e., the frequency and pattern of data request arrivals during different time periods throughout the day, as derived from application-layer statistics); and node activation cycle patterns (i.e., the reporting cycle for specific devices or device groups, such as every 5 minutes, as obtained from the IoT platform). When this input data, rich in historical patterns, is fed into the LSTM model, it outputs a vector through its complex internal gating units (i.e., input gate, forget gate, and output gate) and a series of nonlinear calculations. Each element of this vector is a congestion probability prediction value, a decimal between 0 and 1, representing the model's predicted probability of congestion on the corresponding channel within a predefined time window in the future, such as the next 60 seconds.

[0066] The third step in implementing this preferred embodiment is to add the obtained congestion probability prediction value to the channel state matrix to obtain an updated channel state matrix. This step aims to enhance and integrate the basic data obtained in the first step. The system will append the congestion probability prediction value vector obtained in the previous step as a new column of data to the original channel state matrix. This generates an updated channel state matrix with richer information dimensions. Now, each row vector of this matrix not only describes the current physical state of a channel, but also includes a quantitative assessment of its future congestion risk.

[0067] The fourth step in the implementation process of this preferred embodiment is to allocate service data packets based on the updated channel state matrix. This is the final landing link of the decision. When the selector needs to select the most suitable LoRa channel queue for the data packet, its decision basis is no longer the old state matrix, but the updated channel state matrix containing the predicted information. Whether it is to start the backup plan to find an alternative channel or to make the final decision among multiple alternative channels with the same conditions, the congestion probability prediction value of the fifth dimension will be used as a decision factor with a high weight. Specifically, the selector will give priority to the channel with the smallest predicted value, even if some of its current indicators, such as queue length, are slightly inferior to other channels, but as long as the model predicts that it will be unobstructed in the future, it may become a better choice at present.

[0068] Figure 3 This is another flow chart of the multi-channel line selection scheduling method for co-channel collision in accordance with an embodiment of the present application, in which the line selector allocates the service data packet to the most appropriate LoRa channel queue based on the channel state matrix. Figure 3 As shown, in this preferred embodiment, based on the channel identifier and / or the service level identifier, the line selector allocates the service data packet to the most suitable LoRa channel queue, including: S310, obtaining a channel state matrix; S320, inputting the channel state historical time series data, the service data packet arrival time distribution and the node activation cycle pattern into the trained LSTM-based conflict probability prediction model to obtain the congestion probability prediction value of each channel; S330, adding the congestion probability prediction value of each channel to the channel state matrix to obtain an updated channel state matrix, wherein each row vector of the updated channel state matrix includes the in-place status, occupancy status, queue length, recent error rate and congestion probability prediction value; and, S340, based on the updated channel state matrix, the line selector allocates the service data packet to the most suitable LoRa channel queue.

[0069] More specifically, based on the updated channel state matrix, the process of the line selector allocating the service data packet to the most suitable LoRa channel queue includes: determining the predetermined channel for the service data packet based on the channel identifier; checking the corresponding row vector in the channel state matrix and determining whether the predetermined channel has a healthy status and an idle status; in response to the predetermined channel having a healthy status and an idle status, determining whether the queue length of the predetermined channel exceeds a preset threshold; and, in response to the queue length of the predetermined channel not exceeding the preset threshold, determining the predetermined channel as the most suitable LoRa channel queue. Simultaneously, based on the updated channel state matrix, the process of the line selector allocating the service data packet to the most suitable LoRa channel queue also includes: in response to the predetermined channel having a faulty or maintenance status and an occupied status, querying the channel state matrix and determining the most suitable LoRa channel queue, wherein the most suitable LoRa channel queue has a healthy status, an idle status, a shortest queue length, a lowest recent error rate, and a minimum predicted congestion probability.

[0070] In step S5, the position of the service data packet in the most suitable LoRa channel queue is dynamically adjusted based on the priority tag. That is, once the service data packet is successfully sent to its most suitable LoRa channel queue through the decision of the intelligent line selector, this method does not end its scheduling management function. Instead, it immediately initiates a refined intra-queue management step, namely, dynamically adjusting the specific position of the service data packet in the LoRa channel queue based on the pre-calibrated priority tag. The function of this step is equivalent to opening up an additional dedicated emergency express lane in each physical communication channel to specifically guarantee priority access for critical services.

[0071] The core goal of this step is to provide differentiated quality of service to meet the vastly different real-time communication requirements of different services. While multi-channel allocation resolves conflicts between channels at a macro level, it does not address resource contention within the same channel. A logical channel queue may, at any given moment, hold dozens or even hundreds of data packets waiting to be sent. If a strict first-come, first-served principle is adhered to, an extremely urgent fire alarm message might be forced to queue behind a routine heartbeat packet from an unimportant device, delaying the optimal response time. This situation is absolutely unacceptable in application scenarios such as industrial control or security monitoring. Therefore, this step is designed to break this rigid queuing model. As the overall design philosophy of this method advocates, different services will be processed at different levels, with high-urgency services being given the ability to jump the queue. The priority mechanism embodies this capability, allowing high-priority tasks to be dynamically inserted into the queue. This clearly demonstrates the mission of this step: to perform real-time, hierarchical processing of data packets and, accordingly, grant them dynamic queue-jumping privileges to ensure that urgent services receive absolute priority.

[0072] The technical implementation of this step is a typical priority-based queue insertion and reordering algorithm. When a new service data packet with a marked priority enters a specific LoRa channel queue, it is not simply mechanically added to the end of the queue. Instead, it triggers a dynamic intra-queue position adjustment process, which includes the following steps:

[0073] The first sub-step involves reading and comparing priorities. The software module managing the channel's queue (called the queue manager) immediately reads the priority tag in the header of the newly enqueued packet. Simultaneously, it iterates over all other packets already in the queue and reads their respective priority tags. This process aims to correctly place the newly enqueued packet within the current queue's priority sequence.

[0074] The next key substep is dynamic repositioning. Based on the priority comparison results, the system can employ two main insertion strategies. The first is ordered insertion. Starting from the head of the queue (i.e., the first position to be sent), the system scans toward the tail, searching for the first existing packet with a lower or equal priority than the newly enqueued packet. The new packet is then inserted before the position found there. This strategy ensures that the queue is always sorted from highest to lowest priority (or, if priorities are equal, by arrival time). The second approach is a more efficient implementation, especially when using a standardized data structure such as a priority queue to implement the LoRa channel queue. In this case, the insertion operation itself incorporates automatic reordering logic. When a new element (i.e., a service packet) and its associated priority are added to the priority queue, the data structure automatically reorders the internal elements using algorithms such as heaps with significantly optimized time complexity (e.g., logarithmic time O(log n)), ensuring that the highest priority element always rises to the top of the queue and is immediately available for subsequent retrieval. Regardless of the implementation ultimately used, the result is the same: a high-priority packet does not have to wait; it effectively squeezes out all lower-priority packets that precede it, and thus gets closer to the sender.

[0075] It should be understood that in the embodiment of the present application, the LoRa channel queue is a dynamic rather than static first-in, first-out queue, and its internal order will change at any time due to the priority insertion mechanism. The priority tag is the only basis for driving this dynamic adjustment behavior. It is assigned in the previous business layer calibration step and represents the urgency of the business itself. The so-called dynamic adjustment of the position of the business data packet does not mean frequently copying and moving a large number of data blocks in the physical memory, but is usually achieved by changing the pointer or index of the record position in the data structure. This is a very efficient way of changing the logical position in terms of computation. For example, if this queue is implemented using a linked list, the adjustment action may only be to modify the subsequent pointing pointers of several nodes.

[0076] In step S6, when the service data packet is at the front of the most suitable LoRa channel queue, the service data packet is sent through the LoRa module bound to the most suitable LoRa channel queue. At this point, the entire scheduling process has reached the final execution link, which is also the decisive step for converting all logical scheduling into physical communication actions: when the service data packet is at the front of the most suitable LoRa channel queue, the service data packet is sent through the LoRa physical module bound to this LoRa channel queue.

[0077] The technical purpose of this step is to physically transmit the intelligently scheduled data waiting in the logical queue into the air, completing the ultimate communication mission. While all previous steps involved software-level deployment, this step formally signals the start of the battle. Without this physical transmission link, the entire scheduling system would be merely an internal data sequencer, unable to generate any real communication value. The significance of this step lies in transforming the combined efforts of all previous steps—that is, routing the correct service data packets, at the correct priority, to the correct channel queue—into a final, actual radio signal capable of parallel transmission over the air. This method aims to achieve, for example, up to 10 concurrent transmission channels, and this step directly implements this concurrent transmission. Through it, the entire system achieves the ultimate goal of ensuring that data distribution and transmission are completed in a consistent and orderly manner.

[0078] The technical implementation of this step is a closed-loop control process driven by software and hardware, with periodic checks and triggering mechanisms. This process is independently completed by a software entity (for example, a dedicated background sending thread or a scheduling worker process) that always works with a specific channel queue and its bound LoRa module. The specific execution sub-steps are summarized as follows:

[0079] First, there's the continuous polling monitoring of trigger conditions. The sending thread associated with each LoRa channel queue constantly and frequently checks two basic prerequisites. The primary prerequisite is that it must confirm whether the queue it manages is not empty, that is, whether there is an element at the front of the queue. Second, and equally important, the thread must communicate with the physical hardware (or query a status flag) to confirm whether the LoRa hardware module bound to the queue is currently idle, meaning it is not currently executing a previous transmission task. Only when both conditions are met (i.e., there is data to be sent in the queue and the sending device is idle) is a transmission action officially triggered.

[0080] Second, data packets are dequeued and delivered. Once the trigger conditions are met, the sending thread immediately performs a dequeue operation, extracting a service data packet from the front of the LoRa channel queue for which it is responsible. This extracted data packet is typically a byte array in memory containing a fully structured header and raw payload information. The sending thread then uses this byte array as a parameter to call a send function (API) provided by the underlying hardware driver, delivering the entire data packet to the hardware driver layer of the associated LoRa module.

[0081] Third, the physical layer modulation and transmission phase begins. After receiving the byte array from the upper layer, the LoRa module fully manages all subsequent physical transmission processes. According to the specific specifications of the LoRaWAN communication protocol, it encodes the data packet, adds physical layer header information, and performs a cyclic redundancy check (CRC). Finally, through its built-in RF front-end circuitry, it modulates this digitized data packet into a specific frequency, spread-spectrum radio wave signal (i.e., a chirped spread-spectrum signal), which is then transmitted into the air via the antenna. The specific frequency referred to here is the unique operating frequency assigned to the channel when it is created. Because this method's architecture strongly binds each channel queue to an independent LoRa module operating at a different frequency, this step naturally achieves true multi-channel parallel transmission without co-frequency collisions.

[0082] The foregoing description is merely a preferred embodiment of the present invention and does not constitute any form of limitation to the present invention. Any simple modification of the technical solution of the present invention by a person skilled in the art, by means of equivalent substitution or equivalent transformation, without departing from the overall technical content of the technical solution of the present invention, shall fall within the scope of protection of the technical solution of the present invention.

Claims

1. A multi-channel line selection scheduling method for coping with communication frequency collision, characterized in that: include: Obtain original business data packets from upper-layer application systems; Reorganizing the original service data packet based on a standard data frame format to obtain a service data packet; Performing service layer calibration on the service data packet to obtain a channel identifier, a service layer identifier, and a priority tag; Based on the channel identifier and / or the service level identifier, the line selector allocates the service data packet to the most appropriate LoRa channel queue; In the most suitable LoRa channel queue, dynamically adjusting the position of the service data packet based on the priority tag; When the service data packet is at the front end of the most suitable LoRa channel queue, the service data packet is sent through the LoRa module bound to the most suitable LoRa channel queue.

2. The multi-channel line selection scheduling method for coping with communication frequency collision according to claim 1 is characterized in that: Performing service layer calibration on the service data packet to obtain a channel identifier, a service layer identifier, and a priority tag includes: Parsing metadata of the service data packet to obtain a device ID and a data type; Based on the device ID and the data type, a channel identifier, a service level identifier, and a priority tag are determined.

3. The multi-channel line selection scheduling method for coping with communication frequency collision according to claim 1 is characterized in that: Based on the channel identifier and / or the service level identifier, the line selector allocates the service data packet to the most appropriate LoRa channel queue, including: Obtain channel state matrix; Based on the channel state matrix, the line selector allocates the service data packet to the most appropriate LoRa channel queue.

4. The multi-channel line selection scheduling method for coping with communication frequency collision according to claim 3 is characterized in that: Each row vector in the channel state matrix represents the state information of each channel, and the state information of each channel includes the in-place status, occupancy status, queue length and recent error rate.

5. The multi-channel line selection and scheduling method for coping with communication frequency collision according to claim 4 is characterized in that: Based on the channel state matrix, the line selector allocates the service data packet to the most appropriate LoRa channel queue, including: Determining a predetermined channel for the service data packet based on the channel identifier; Checking a corresponding row vector in the channel state matrix and determining whether the in-place state of the predetermined channel is healthy and whether the occupancy state is idle; In response to the in-place status of the predetermined channel being healthy and the occupancy status being idle, determining whether a queue length of the predetermined channel exceeds a preset threshold; In response to the queue length of the predetermined channel not exceeding a preset threshold, the predetermined channel is determined as the most suitable LoRa channel queue.

6. The multi-channel line selection and scheduling method for coping with communication frequency collision according to claim 5, characterized in that: Based on the channel state matrix, the line selector allocates the service data packet to the most appropriate LoRa channel queue, including: In response to the in-place status of the predetermined channel being faulty or under maintenance and the occupancy being occupied, querying the channel state matrix and determining the most suitable LoRa channel queue, wherein the in-place status of the most suitable LoRa channel queue is healthy, the occupancy is idle, the queue length is the shortest, and the recent error rate is the lowest.

7. The multi-channel line selection scheduling method for coping with communication frequency collision according to claim 3 is characterized in that: Based on the channel identifier and / or the service level identifier, the line selector allocates the service data packet to the most appropriate LoRa channel queue, including: Obtain channel state matrix; The channel status historical time series data, service data packet arrival time distribution, and node activation cycle pattern are input into the trained LSTM-based conflict probability prediction model to obtain the congestion probability prediction value of each channel; Adding the congestion probability prediction value of each channel to the channel state matrix to obtain an updated channel state matrix, wherein each row vector of the updated channel state matrix includes an in-place status, an occupancy status, a queue length, a recent error rate, and a congestion probability prediction value; Based on the updated channel state matrix, the line selector allocates the service data packet to the most appropriate LoRa channel queue.

8. The multi-channel line selection and scheduling method for coping with communication frequency collision according to claim 7, characterized in that: Based on the updated channel state matrix, the line selector allocates the service data packet to the most appropriate LoRa channel queue, including: Determining a predetermined channel for the service data packet based on the channel identifier; Checking a corresponding row vector in the channel state matrix and determining whether the in-place state of the predetermined channel is healthy and whether the occupancy state is idle; In response to the in-place status of the predetermined channel being healthy and the occupancy status being idle, determining whether a queue length of the predetermined channel exceeds a preset threshold; In response to the queue length of the predetermined channel not exceeding a preset threshold, the predetermined channel is determined as the most suitable LoRa channel queue.

9. The multi-channel line selection scheduling method for coping with communication frequency collision according to claim 8, characterized in that: Based on the updated channel state matrix, the line selector allocates the service data packet to the most appropriate LoRa channel queue, further comprising: In response to the in-place status of the predetermined channel being faulty or under maintenance and the occupancy being occupied, the channel state matrix is ​​queried and the most suitable LoRa channel queue is determined, wherein the in-place status of the most suitable LoRa channel queue is healthy, the occupancy is idle, the queue length is the shortest, the recent error rate is the lowest, and the congestion probability prediction value is the smallest.

Images