Conflict-aware multi-loRa gateway online downlink scheduling method

Abstract

This invention discloses a multi-LoRa gateway online downlink scheduling method based on collision awareness. It initializes a Co-SF collision count table, a Co-SF collision awareness table, an Inter-SF collision count table, and an Inter-SF collision awareness table. The network server performs Co-SF and Inter-SF collision awareness on downlink data packets, and updates the Co-SF and Inter-SF collision awareness tables. When sending downlink data packets, the network server determines whether there is an idle channel, and then selects a gateway without transmission collisions to send the downlink data packets by querying the Co-SF and Inter-SF collision awareness tables. By sensing and avoiding transmission collisions, the method ultimately improves downlink concurrency capabilities.

Description

Technical Field

[0001] This invention belongs to the technical field of low-power wide-area network design in the Internet of Things, and mainly relates to a method for scheduling multiple LoRa gateways in online downlink based on conflict awareness. Background Technology

[0002] The Internet of Things (IoT) enables interconnection between things and between things and people. With the rapid development of IoT technology (especially wireless communication technology), humanity is entering an era of interconnectedness. In the traditional IoT wireless communication field, based on different communication distances, wireless communication technologies can be mainly divided into two categories: (1) short-range wireless communication technologies, mainly including Wi-Fi, Bluetooth, NFC, ZigBee, RFID, etc. (2) long-range wireless communication technologies, mainly including UMTS, GSM, 5G, etc. Among them, short-range wireless communication technologies cannot cover wide-area scenarios, while traditional long-range wireless communication technologies often require sacrificing a large amount of terminal device power consumption in exchange for communication coverage. With the popularization of IoT technology in smart industry, smart cities, smart farms, and other fields, the demand for wide coverage, low power consumption, and low cost wireless communication is becoming increasingly urgent. Against this background, Low-Power Wide-Area Network (LPWAN) technology has emerged.

[0003] LPWAN, with its characteristics of small data volume, large connectivity, and low cost, is widely used in a wide range of scenarios such as smart industry, smart cities, and smart farms to provide low-power long-distance communication. Based on whether the spectrum is licensed, the mainstream LPWAN technologies on the market can be mainly divided into two categories: (1) non-cellular technologies with unlicensed spectrum, mainly including LoRa (Long Range) and Sigfox. (2) Cellular IoT technologies with licensed spectrum, mainly including NB-IoT and LTE-M. Among them, LoRa stands out among LPWAN technologies because of its advantages such as open architecture, on-demand self-networking, and miniaturized easy deployment. It is especially suitable for outdoor environments that cannot be covered by operator networks, such as smart industry, smart cities, and smart farms that require long-term low-power data monitoring. Therefore, in-depth and thorough forward-looking research on LoRa networks has important theoretical and application value.

[0004] A LoRa network mainly consists of terminals, gateways, network servers, and application servers. LoRa terminals and gateways connect via LoRaWAN in a single-hop star network topology. Terminal devices transmit sensor data to the gateway using a pure ALOHA method according to certain transmission parameters. The main transmission parameters that need to be set when LoRa terminals communicate with the gateway are: carrier frequency (CF), spreading factor (SF), bandwidth (BW), code rate (CR), and transmission power (TP). LoRa terminal devices need to select a communication channel to transmit data to the gateway; a channel consists of a combination of a carrier frequency and a spreading factor. A LoRa gateway can set up to eight carrier frequencies, simultaneously monitoring the signals transmitted on these eight carrier frequencies and demodulating these eight signals in parallel. The communication process between LoRa terminals and gateways is subject to two types of transmission interference: Co-SF interference and Inter-SF interference. Co-SF interference occurs when data packets sent by different terminals use the same CF and SF, and their transmission times overlap; Co-SF interference will inevitably lead to transmission collisions. Inter-SF interference occurs when data packets sent by different terminals use the same CF (Cross Message) but different SF (Signal Message), and their transmission times overlap. Inter-SF interference is caused by the imperfect orthogonality of LoRa symbols and can lead to transmission collisions. The gateway sends demodulated data packets to the network server via cellular networks, Ethernet, or Wi-Fi. After parsing and processing the data packets, the network server uploads the corresponding data to the application server according to application requirements.

[0005] Due to the aforementioned LoRa transmission conflicts, the existing downlink concurrent communication capabilities between LoRa gateways and terminals cannot meet the needs of large-scale IoT applications. The main reason is that when sending downlink commands to a large number of terminal devices, the limited number of gateways and their receiving capabilities, coupled with the large number of terminal devices, easily lead to channel conflicts during concurrent transmission. In online applications, where communication needs cannot be known in advance, transmission conflicts are even more likely to occur. Specifically, a typical LoRa network has only a few to dozens of channels, but large-scale applications require the support of tens of thousands of terminal devices. Furthermore, overlapping areas between gateways increase the probability of downlink data packet conflicts. These factors make channel resources extremely scarce relative to the number of terminal devices and unable to be effectively utilized, resulting in a high probability of data packet transmission conflicts. This problem is particularly severe in online applications. Therefore, improving the downlink concurrent communication capabilities of LoRa gateways to terminals in online applications, thereby increasing the number of terminal devices concurrently sending downlink commands per unit coverage area, is a core issue that urgently needs to be addressed. Summary of the Invention

[0006] This invention addresses the problem of low data packet concurrency caused by numerous transmission collisions in existing technologies by providing a collision-aware multi-LoRa gateway offline downlink scheduling method. It initializes a Co-SF collision count table, a Co-SF collision awareness table, an Inter-SF collision count table, and an Inter-SF collision awareness table. The network server performs Co-SF and Inter-SF collision awareness on downlink data packets and updates the Co-SF and Inter-SF collision awareness tables accordingly. When sending downlink data packets, the network server determines whether there is an available channel and then selects a collision-free gateway to send the downlink data packets by querying the Co-SF and Inter-SF collision awareness tables. By sensing and avoiding transmission collisions, the downlink concurrency capability is ultimately improved.

[0007] To achieve the above objectives, the technical solution adopted by this invention is as follows: A multi-LoRa gateway online downlink scheduling method based on collision awareness is used. This involves initializing the Co-SF collision count table, Co-SF collision awareness table, Inter-SF collision count table, and Inter-SF collision awareness table; performing Co-SF and Inter-SF collision awareness on downlink data packets by the network server; and updating the Co-SF and Inter-SF collision awareness tables. When sending downlink data packets, the network server determines whether there is an idle channel, and then selects a gateway without transmission collisions to send the downlink data packets by querying the Co-SF and Inter-SF collision awareness tables.

[0008] As an improvement of the present invention, a conflict-aware multi-LoRa gateway online downlink scheduling method includes the following steps:

[0009] S1, Co-SF Conflict Detection: Initially, the network server randomly selects a gateway to send downlink data packets to the terminal. Based on the uplink status of the data packets, it detects Co-SF conflicts between downlink data packets sent by two gateways to the terminal. The conflict detection method is as follows: Initialize the Co-SF conflict count table and the Co-SF conflict detection table. Record the detected downlink data packet conflict results in the Co-SF conflict count table. Each time a Co-SF conflict occurs, the corresponding value in the Co-SF conflict count table is incremented by 1. If the value is greater than 0, the value is decremented by 1 for each successful transmission. The Co-SF conflict detection table is formed when the network server reads the data. If the value in the Co-SF conflict count table exceeds the threshold, the Co-SF conflict detection table is set to 1, indicating that a Co-SF conflict will occur when the two gateways send downlink data packets to the corresponding terminal. If the threshold is not exceeded, the Co-SF conflict detection table is set to 0, indicating that no Co-SF conflict has occurred.

[0010] S2, Inter-SF Conflict Detection: Detecting Inter-SF conflicts between downlink data packets sent from two gateways to the terminal. The conflict detection method is as follows: Initialize the Inter-SF conflict count table and the Inter-SF conflict detection table. Each time an Inter-SF conflict occurs, the corresponding value in the Inter-SF conflict count table is incremented by 1. If the value is greater than 0, the value is decremented by 1 for each successful transmission. The Inter-SF conflict detection table is formed when the network server reads the data. If the value in the Inter-SF conflict count table exceeds the threshold, the Inter-SF conflict detection table is set to 1, indicating that an Inter-SF conflict will occur when the two gateways send downlink data packets to the corresponding terminal. If the threshold is not exceeded, the Inter-SF conflict detection table is set to 0, indicating that no Inter-SF conflict has occurred.

[0011] S3, Downlink Scheduling: When sending downlink data packets, the network server determines whether there is an idle channel, and then selects a gateway that will not cause transmission conflicts to send the downlink data packets by querying the Co-SF conflict awareness table in step S2 and the Inter-SF conflict awareness table in step S3.

[0012] As an improvement of the present invention, step S1 specifically includes:

[0013] S11: The network server first initializes the Co-SF collision count table. u Co-SF Conflict Perception Table S1 u S and S1 are both symmetric matrices, u = m * n, where m is the number of gateways, n is the number of data packets, i, j = {1, ..., m} are the indices of the gateways, and a, b = {1, ..., n} are the indices of the terminals. vw The initial value is 0, v = i*a, w = j*b, indicating whether a Co-SF collision will occur when gateway i sends a downlink data packet to terminal a and gateway j sends a downlink data packet to terminal b at the same time.

[0014] S12: If the uplink data packet corresponding to the downlink command sent by gateway i to terminal a indicates that the downlink was unsuccessful, and the downlink data packet sent by gateway j to terminal b is a downlink data packet sent at the same SF, CF, and time as the downlink command, then a collision is recorded, and S is set to... vw With S wv The value of S is incremented by 1; each time an uplink data packet v and uplink data packet w indicate that the downlink has failed, S... vw With S wv Add 1 to all, if S vw With S wvIf, assuming a value greater than 0, one of the terminals indicates a successful downlink data packet in its uplink data packet, then S will be set to... vw With S wv Decrease by 1 for each element, and so on, to fill table S. u ;

[0015] S13: Each time the network server needs to schedule gateways based on conflict awareness, it reads the Co-SF conflict count table S. u Read the value of the instant and the table S for that instant. u Thresholding is applied to create the Co-SF conflict-aware table S1. u When S vw With S wv If the value exceeds the threshold, it indicates a conflict between the two terminals, and then... and Set each value to 1, and form the Co-SF conflict perception table S1. u ;like and If the value is 1, it indicates that if gateway j sends a downlink command to terminal b at the same time that gateway i sends a downlink command to terminal a, it will cause a conflict between the two downlink data packets.

[0016] As another improvement of the present invention, step S2 specifically includes:

[0017] S21: Initialize Inter-SF Collision Count Table A u×u Inter-SF Conflict Awareness Table A1 u×u A and A1 u×u Let u be an asymmetric matrix, where m is the number of gateways, n is the number of data packets, i, k = {1, ..., m} are the indices of the gateways, a, c = {1, ..., n} are the indices of the terminals, and A vl The initial value is 0, v = i*a, l = k*c, indicating whether an Inter-SF conflict will occur when gateway i sends a downlink data packet to terminal a and gateway k sends a downlink data packet to terminal c.

[0018] S22: If gateway i sends a downlink command to terminal c that is a data packet with a different SF, the same CF, and sent at the same time as the downlink data packet, and if terminal c's uplink data packet indicates downlink success while terminal a's uplink data packet indicates downlink failure, then A... vl The value of A is increased by 1, while A lv The value remains unchanged; if both terminals' uplink data packets indicate downlink failure and are judged as Inter-SF conflicts, then A vl With A lv All increment by 1; whenever an Inter-SF conflict occurs where gateway i sends a downlink command to terminal a, then A...vl Add 1, and A lv The same applies if the two downlink data packets both experience Inter-SF collisions, then A... vl With A lv Add 1 to all; if A vl Or A lv If the value is greater than 0, and the corresponding uplink data packet is receivable, then A will be... vl Or A lv Decrease each value by 1, and so on, to fill Table A. u× u;

[0019] S23: Each time the network server needs to schedule gateways based on conflict awareness, it reads the Inter-SF conflict count table A. u×u Read the values ​​at each instant and apply a threshold to the instantaneous table to create the Inter-SF conflict-aware table A1. u×u , when A vl If the value exceeds the threshold, it indicates that a downlink data packet sent to terminal a may collide, and then... Set to 1 and form Inter-SF conflict perception table A1. u×u If A vl With A lv Setting both to 1 indicates that if gateway i sends a downlink command to terminal a, and at the same time gateway i sends a downlink command to terminal c, downlink communication between the two gateways will fail.

[0020] As another improvement of the present invention, the threshold value in the Co-SF collision count table and the Inter-SF collision count table is 3.

[0021] As another improvement of the present invention, step S3 specifically includes:

[0022] S31: The network server selects a gateway for downlink. Based on the start and end times of the downlink request, it selects a gateway from m gateways that is available during the time period from the start to the end of the downlink request for further filtering. If there is no available gateway, the downlink is rejected.

[0023] S32: If there are available gateways, the network server queries whether there are any gateways among the available gateways that do not cause Co-SF or Inter-SF conflicts, based on the Co-SF conflict awareness table in step S2 and the Inter-SF conflict awareness table in step S3. If there are, a set of conflict-free gateways can be obtained, and downlink transmission can be completed.

[0024] As a further improvement of the present invention, in step S32, if there are multiple conflict-free gateways, the gateway with the largest uplink SNR is selected as the downlink gateway.

[0025] Compared with the prior art, the present invention has the following beneficial effects:

[0026] (1) To address the problem that existing LoRa gateways can only support a limited number of concurrent downlink terminals and cannot meet the needs of LPWAN applications, a conflict-aware LoRa gateway online downlink scheduling method is proposed for the first time. It is mainly based on gateway scheduling at the MAC layer, can be used directly on existing commercial LoRa baseband chips, and has low communication overhead, low deployment and maintenance costs, and low hardware complexity or terminal power consumption.

[0027] (2) In view of the transmission characteristics of LoRa network of "small data, large connection", this invention addresses the complex transmission characteristics of LoRa, such as Co-SF conflict, the problem of a large number of Inter-SF interference caused by the non-perfect orthogonality between data packets transmitted by different SFs, and the large number of transmission conflicts caused by the limited parallel downlink capability of LoRa gateway. By sensing the transmission conflicts, the concurrency of LoRa gateway during offline downlink can be improved.

[0028] (3) Considering the large-scale deployment of LoRa networks, this invention takes into account the awareness of downlink conflict data packets in a multi-gateway environment, and provides a guarantee for the optimized scheduling of downlink channel resources in a multi-gateway environment, so as to improve the downlink communication capabilities of multiple LoRa gateways. Attached Figure Description

[0029] Figure 1 This is an architecture diagram of the multi-LoRa gateway online downlink scheduling system based on conflict awareness, as described in this invention.

[0030] Figure 2 This is a data interaction diagram of the conflict-aware multi-LoRa gateway online downlink scheduling method of the present invention;

[0031] Figure 3 This is a flowchart illustrating the conflict awareness process of the multi-LoRa gateway online downlink scheduling method based on conflict awareness, as described in this invention. Detailed Implementation

[0032] The present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments. It should be understood that the following specific embodiments are for illustrative purposes only and are not intended to limit the scope of the present invention.

[0033] Example 1

[0034] A conflict-aware multi-LoRa gateway online downlink scheduling method, the specific architecture of which is as follows: Figure 1As shown, a LoRa network mainly consists of LoRa terminals, LoRa gateways, network servers, and application servers. LoRa terminals are typically battery-powered and send uplink data packets to the gateway with specific transmission parameters. The gateway sends downlink data packets to the LoRa terminal to instruct it to perform uplink operations. The gateway then forwards the demodulated data packets to the network server via networks such as Ethernet. The network server schedules downlink operations to the LoRa gateway according to this downlink scheduling method, and the network server uploads corresponding data to the application server as needed. The data interaction of the downlink scheduling method of this invention is as follows: Figure 2 As shown, the interaction process involves three parties: the LoRa terminal, the LoRa gateway, and the LoRa network server. The LoRa terminal sends uplink data packets to the LoRa gateway, which forwards the uplink data packets to the LoRa network server. Initially, the LoRa network server randomly selects a gateway to send downlink data packets. After receiving the downlink data packets, the LoRa terminal sends uplink data packets containing downlink success information to the LoRa gateway. The LoRa gateway then sends this uplink data packet to the LoRa network server. After updating the collision count table, the network server selects a gateway to send downlink data packets to the LoRa terminal based on the collision awareness table.

[0035] A conflict-aware multi-LoRa gateway online downlink scheduling method specifically includes the following steps:

[0036] Step S1: Initially, the network server randomly selects a gateway to send downlink data packets to the terminal. Subsequently, based on the uplink data packet situation, it detects conflicts between downlink data packets sent by two gateways to the terminal. Considering the uncertainty of Inter-SF conflicts and the determinism of Co-SF conflicts, Co-SF conflicts are detected first. Before detection, two tables need to be initialized: a Co-SF conflict count table and a Co-SF conflict detection table. The detected downlink data packet conflict results are recorded in the Co-SF conflict count table. Each time a Co-SF conflict occurs, the corresponding value in the Co-SF conflict count table is incremented by 1. Similarly, if the value is greater than 0, the value is decremented by 1 for each successful transmission. The Co-SF conflict count table is always in a changing state. The Co-SF conflict detection table is formed when the network server reads the data. If the value in the Co-SF conflict count table exceeds a threshold, the Co-SF conflict detection table is set to 1, indicating that a Co-SF conflict will occur when the two gateways send downlink data packets to the corresponding terminal; otherwise, it is set to 0.

[0037] Step S11: Before officially starting the downlink, the network server first initializes the Co-SF collision count table S. u Co-SF Conflict Perception Table S1 uSince the Co-SF collision will result in the loss of both data packets, S and S1 are both symmetric matrices, u = m * n, where m is the number of gateways, n is the number of data packets, i, j = {1, ..., m} are the indices of the gateways, and a, b = {1, ..., n} are the indices of the terminals. vw The initial value is 0, v = i*a, w = j*b, indicating whether a Co-SF collision will occur when gateway i sends a downlink data packet to terminal a, and gateway j sends a downlink data packet to terminal b simultaneously. Based on the downlink success message contained in the uplink data packets received by the network server from terminals a and b, if the downlink fails, it is determined whether the two downlink data packets were sent using the same SF and CF, and whether their transmission times overlapped. vv =1, meaning that by default, Co-SF collisions will not occur between different data packets. Table S1 u To be read from the web server at the time of the query, table S u The instantaneous values ​​are displayed in a table after thresholding.

[0038] Step S12: The terminal initially sends uplink data packets randomly. The gateway forwards the uplink data packets to the network server, and the network server randomly selects a gateway to send downlink data packets. The terminal's uplink data packets will contain information on whether the downlink data packet to the gateway was successful. The network server modifies the collision count table based on this information. If the uplink data packet corresponding to the downlink command sent by gateway i to terminal a indicates that the downlink was unsuccessful, and assuming that the downlink data packet sent by gateway j to terminal b is a downlink data packet sent at the same SF, CF, and time as the downlink command, then a collision is recorded, and S12 is set to 1. vw With S wv The value of each is incremented by 1. Subsequently, whenever an uplink data packet v or uplink data packet w indicates a failed downlink connection, S... vw With S wv Add 1 to all, if S vw With S wv If, assuming a value greater than 0, one of the terminals indicates a successful downlink data packet in its uplink data packet, then S will be set to... vw With S wv Decrease by 1 for each element, and so on, to fill table S. u ;

[0039] Step S13: Each time the network server needs to schedule the gateway based on the conflict awareness situation, it reads the Co-SF conflict count table S. u Read the value of the instant and the table S for that instant. u Thresholding is applied to create the Co-SF conflict-aware table S1. u When S vw With S wvWhen the number of collisions exceeds the threshold, it indicates that the number of collisions has exceeded the set threshold, meaning that the two terminals are very likely to collide. and Set each value to 1, and form the Co-SF conflict perception table S1. u .like and If the value is 1, it means that if gateway j sends a downlink command to terminal b at the same time as gateway i sends a downlink command to terminal a, the two downlink data packets will conflict. Therefore, it is necessary to avoid gateway j sending a downlink command to terminal b at the same time as gateway i sending a downlink command to terminal a.

[0040] In this embodiment, the threshold is 2, 3, or 4, with a typical threshold value of 3 being optimal.

[0041] Step S2: If downlink data packets received by two terminals collide, but the corresponding values ​​for these two terminals in the Co-SF conflict awareness table are 0, meaning that no Co-SF conflict has occurred between these two terminals, then the data packets between these two terminals may have experienced an Inter-SF conflict. Inter-SF conflicts occurring between downlink data packets sent from two gateways to the terminals are detected, and the detection results are recorded in the Inter-SF conflict table. Each time an Inter-SF conflict occurs, the corresponding value in the Inter-SF conflict table is incremented by 1. Similarly, if the value is greater than 0, the value is decremented by 1 for each successful transmission. The Inter-SF conflict counter table is always in a changing state. The Inter-SF awareness table is formed when the network server reads the data. If the value in the Inter-SF conflict table exceeds a threshold, the Inter-SF awareness table is set to 1, indicating that an Inter-SF conflict will occur when downlink data packets are sent from these two gateways to the corresponding terminals; otherwise, it is set to 0.

[0042] Step S21: Initialize Inter-SF Collision Count Table A u×u Inter-SF Conflict Awareness Table A1 u×u A and A1 u×u Let u be an asymmetric matrix, where m is the number of gateways, n is the number of data packets, i, k = {1, ..., m} are the indices of the gateways, a, c = {1, ..., n} are the indices of the terminals, and A vl The initial value is 0, v = i*a, l = k*c, indicating whether an Inter-SF conflict will occur when gateway i sends a downlink data packet to terminal a and gateway k sends a downlink data packet to terminal c. This is determined by the downlink success message received by the network server from the uplink data packets of both terminals. If the downlink fails, it is determined whether the two downlink data packets were sent using different SFs but the same CF, and whether their transmission times overlapped. A vv=1, meaning that by default, Inter-SF collisions will not occur between different data packets. Table A1 u×u To read table A at the time of the web server access. u×u The instantaneous values ​​are displayed in a table after thresholding.

[0043] Step S22: If the uplink data packet corresponding to the downlink command sent by gateway i to terminal a cannot be received, and there is no downlink data packet that has a Co-SF conflict with it, then downlink data packets sent at the same time but with a different SF may have an Inter-SF conflict with this data packet, resulting in the loss of this data packet. Assume that the downlink command sent by gateway i to terminal c is a data packet sent at the same time but with a different SF than this downlink data packet. If the uplink data packet of terminal c indicates downlink success, but the uplink data packet of terminal a indicates downlink failure, then A... vl The value of A is increased by 1, while A lv The value remains unchanged. If both terminals' uplink data packets indicate downlink failure and are judged as Inter-SF collisions, then A vl With A lv Add 1 to each. Thereafter, whenever an Inter-SF conflict occurs where gateway i sends a downlink command to terminal a, then A... vl Add 1, and A lv The same applies if the two downlink data packets both experience Inter-SF collisions, then A... vl With A lv Add 1 to all; if A vl Or A lv If the value is greater than 0, and the corresponding uplink data packet is receivable, then A will be... vl Or A lv Decrease each value by 1, and so on, to fill Table A. u×u ;

[0044] Step S23: Each time the network server needs to schedule gateways based on conflict awareness, it reads the Inter-SF conflict count table A. u×u Read the values ​​at each instant and apply a threshold to the instantaneous table to create the Inter-SF conflict-aware table A1. u×u . When A vl When the number of collisions exceeds the threshold, it indicates that the number of collisions exceeds the set threshold, meaning that the downlink data packets sent to terminal a are very likely to collide. Set to 1 and form Inter-SF conflict perception table A1. u×u If A vl With A lv Setting both to 1 indicates that if gateway i sends a downlink command to terminal a, and gateway / sends a downlink command to terminal c, then downlink communication between the two gateways will fail.

[0045] In this embodiment, the threshold value is 2, 3, or 4, with a typical threshold value of 3 being optimal.

[0046] Therefore, the conflict-aware multi-LoRa gateway online downlink scheduling method conflict-aware process in this step is as follows: Figure 3 As shown. The network server schedules the gateway to send downlink data packets to the terminal. If the uplink data packet sent by the terminal indicates that the downlink was successful, the gateway selected by the network server for downlink can remain unchanged. If the downlink fails, it first determines whether it is a Co-SF conflict. If it is a Co-SF conflict, the corresponding value in the Co-SF conflict counter table S is incremented by 1. If the conflicting terminal successfully uploads, the corresponding value in table S is decremented by 1. The instantaneous value of the Co-SF conflict counter table S read by the network server during scheduling is the Co-SF conflict awareness table S1. If the instantaneous value exceeds the threshold, the corresponding value in the Co-SF conflict awareness table S1 is set to 1; otherwise, it is set to 0. If no Co-SF conflict occurs, it is determined whether it is an Inter-SF conflict. If it is an Inter-SF conflict, the corresponding value in Inter-SF conflict count table A is incremented by 1. If the conflicting terminal successfully uploads, the corresponding value in table A is decremented by 1. When the network server schedules, it reads the instantaneous value of Inter-SF conflict count table A, which is the Inter-SF conflict awareness table A1. If the instantaneous value exceeds the threshold, the corresponding value in Inter-SF conflict awareness table A1 is set to 1; if it does not exceed the threshold, it is set to 0.

[0047] Step S3: When a downlink data packet needs to be sent, the network server first determines whether there is an idle channel, and then selects a channel that will not cause a transmission conflict by querying the above-mentioned conflict awareness table.

[0048] Step S31: The network server selects a gateway for downlink. Based on the start and end times of the downlink request, it selects a gateway from m gateways that is available during the time period from the start to the end of the downlink request for further filtering. If there is no available gateway, the downlink is rejected.

[0049] Step S32: Given that there are available gateways, the network server queries the available gateways to see if there are any gateways that do not cause Co-SF or Inter-SF conflicts, based on the Co-SF and Inter-SF conflict awareness tables. If so, a set of conflict-free gateways can be obtained.

[0050] Step S33: If there is only one conflict-free gateway, then the gateway is used as the downlink gateway to generate downlink data packets; if there are multiple conflict-free gateways, then the gateway with the largest uplink SNR is selected as the downlink gateway.

[0051] In summary, this invention detects transmission conflicts in real-time communication between LoRa terminals and gateways and forms a conflict awareness table. This table records whether transmission conflicts, including Co-SF and Inter-SF conflicts, will occur between terminals. Based on this table, the LoRa gateway schedules downlink data packets online. This invention effectively addresses the problem of transmission conflicts during LoRa gateway downlink transmission when the gateway sends downlink data packets to terminals online. This is caused by a large number of terminal devices, limited gateway numbers and concurrent downlink capabilities, and overlapping communication areas among multiple gateways. These issues prevent terminals from receiving downlink commands and transmitting data. The method presented in this invention is highly effective and efficient.

[0052] It should be noted that the above content merely illustrates the technical concept of the present invention and should not be construed as limiting the scope of protection of the present invention. For those skilled in the art, various improvements and modifications can be made without departing from the principle of the present invention, and all such improvements and modifications fall within the scope of protection of the claims of the present invention.

Claims

1. A method for scheduling multiple LoRa gateways in online and offline modes based on conflict awareness, characterized in that: Initialize the Co-SF collision count table, Co-SF collision awareness table, Inter-SF collision count table, and Inter-SF collision awareness table. Perform Co-SF and Inter-SF collision awareness on the network server for downlink data packets, and update the Co-SF and Inter-SF collision awareness tables. When sending downlink data packets, the network server determines if there is an available channel and then selects a conflict-free gateway to send the downlink data packets by querying the Co-SF and Inter-SF collision awareness tables. This includes the following steps: S1, Co-SF Conflict Detection: Initially, the network server randomly selects a gateway to send downlink data packets to the terminal. Based on the uplink status of the data packets, it detects Co-SF conflicts between downlink data packets sent by two gateways to the terminal. The conflict detection method is as follows: Initialize the Co-SF conflict count table and the Co-SF conflict detection table. Record the detected downlink data packet conflict results in the Co-SF conflict count table. Each time a Co-SF conflict occurs, the corresponding value in the Co-SF conflict count table is incremented by 1. If the value is greater than 0, the value is decremented by 1 for each successful transmission. The Co-SF conflict detection table is formed when the network server reads the data. If the value in the Co-SF conflict detection table exceeds the threshold, the Co-SF conflict detection table is set to 1, indicating that a Co-SF conflict will occur when the two gateways send downlink data packets to the corresponding terminal. If the value does not exceed the threshold, the Co-SF conflict detection table is set to 0, indicating that no Co-SF conflict has occurred. S2, Inter-SF Conflict Detection: Detecting Inter-SF conflicts between downlink data packets sent from two gateways to the terminal. The conflict detection method is as follows: Initialize the Inter-SF conflict count table and the Inter-SF conflict detection table. Each time an Inter-SF conflict occurs, the corresponding value in the Inter-SF conflict count table is incremented by 1. If the value is greater than 0, the value is decremented by 1 for each successful transmission. The Inter-SF conflict detection table is formed when the network server reads the data. If the value in the Inter-SF conflict count table exceeds the threshold, the Inter-SF conflict detection table is set to 1, indicating that an Inter-SF conflict will occur when the two gateways send downlink data packets to the corresponding terminal. If the threshold is not exceeded, the Inter-SF conflict detection table is set to 0, indicating that no Inter-SF conflict has occurred. S3, Downlink Scheduling: When sending downlink data packets, the network server determines whether there is an idle channel, and then selects a gateway that will not cause transmission conflicts to send the downlink data packets by querying the Co-SF conflict awareness table in step S2 and the Inter-SF conflict awareness table in step S3.

2. The multi-LoRa gateway online downlink scheduling method based on conflict awareness as described in claim 1, characterized in that: Step S1 specifically includes: S11: The network server first initializes the Co-SF collision count table. Co-SF Conflict Perception Table S and All are symmetric matrices. n is the number of data packets. , is the index for the terminal. The initial value is 0. This indicates whether a Co-SF conflict will occur when gateway i sends a downlink data packet to terminal a, and gateway j sends a downlink data packet to terminal b at the same time. S12: If from the gateway If the uplink data packet corresponding to the downlink command sent to terminal a indicates that the downlink failed, and the downlink data packet sent by gateway j to terminal b is a downlink data packet sent at the same SF, CF, and time as the downlink command, then a collision is recorded. and The value is incremented by 1 each time an uplink data packet v and uplink data packet w indicate that the downlink failed. and Add 1 to all, if and If, assuming a value greater than 0, one of the terminals indicates a successful downlink data packet in its uplink data packet, then... and Decrease by 1 for each element, and so on to fill the table. ; S13: Each time the network server needs to schedule gateways based on conflict awareness, it reads the Co-SF conflict count table. Read the value at time and add it to the table of instantaneous times. Thresholding is applied to create a Co-SF conflict-aware table. ,when and If the value exceeds the threshold, it indicates a conflict between the two terminals, and then... and Each value is set to 1, and a Co-SF conflict perception table is formed. ;like and A value of 1 indicates that if gateway j sends a downlink command to terminal b at the same time, gateway... Sending a downlink command to terminal a will cause a collision between the two downlink data packets.

3. The multi-LoRa gateway online downlink scheduling method based on conflict awareness as described in claim 1, characterized in that: Step S2 specifically includes: S21: Initialize the Inter-SF collision count table Inter-SF Conflict Awareness Table A and It is an asymmetric matrix. n is the number of data packets. , is the index for the terminal. The initial value is 0. This indicates whether an Inter-SF collision will occur when gateway i sends a downlink data packet to terminal a, and gateway k sends a downlink data packet to terminal c simultaneously. S22: If gateway i sends a downlink command to terminal c that is a data packet sent at the same time but with a different SF than the downlink data packet, and if terminal c's uplink data packet indicates downlink success while terminal a's uplink data packet indicates downlink failure, then... The value is increased by 1, and The value remains unchanged; if both terminals' uplink data packets indicate downlink failure and are judged as Inter-SF conflicts, then and Increment by 1 for each gateway event; If an Inter-SF collision occurs when sending a downlink command to terminal a, then Add 1, and The same applies if the two downlink data packets both experience Inter-SF collisions, then... and Add 1 to all; if or If the value is greater than 0, and the corresponding uplink data packet is receivable, then... or Decrease by 1 for each element, and so on to fill the table. ; S23: Each time the network server needs to schedule gateways based on conflict awareness, it reads the Inter-SF conflict count table. Read the values ​​at each moment and apply a threshold to the instantaneous table to create an Inter-SF conflict-aware table. ,when If the value exceeds the threshold, it indicates that a downlink data packet sent to terminal a may collide, and then... Set to 1 and form the Inter-SF conflict awareness table. ;like and All set to 1, indicating that it is controlled by the gateway. While sending downlink commands to terminal a, if the gateway If a device sends a downlink command to terminal c, downlink communication between both gateways will fail.

4. The conflict-aware multi-LoRa gateway online downlink scheduling method as described in claim 2 or 3, characterized in that: The threshold value in the Co-SF collision count table and the Inter-SF collision count table is 3.

5. The multi-LoRa gateway online downlink scheduling method based on conflict awareness as described in claim 4, characterized in that: Step S3 specifically includes: S31: The network server selects a gateway for downlink. Based on the start and end times of the downlink request, it selects a gateway from m gateways that is available during the time period from the start to the end of the downlink request for further filtering. If there is no available gateway, the downlink is rejected. S32: If there are available gateways, the network server queries whether there are any gateways among the available gateways that do not cause Co-SF or Inter-SF conflicts, based on the Co-SF conflict awareness table in step S2 and the Inter-SF conflict awareness table in step S3. If there are, a set of conflict-free gateways can be obtained, and downlink transmission can be completed.

6. The multi-LoRa gateway online downlink scheduling method based on conflict awareness as described in claim 5, characterized in that: In step S32, if there are multiple conflict-free gateways, the gateway with the largest uplink SNR is selected as the downlink gateway.

Images