Equipment communication method based on LoRa private protocol

Abstract

The invention discloses an equipment communication method based on a LoRa private protocol, and relates to the technical field of wireless communication, and the method comprises the following steps: a communication request initiator generates a request message, and carries out message subpackaging under the condition that the size of the request message exceeds the maximum length limit of LoRa single packet transmission; the message sub-packet comprises a packet header, a packet body and a packet tail; the communication request initiator sequentially sends all the message subpackages from the subpackage 1 until the last message subpackage is sent; the communication request responder receives the packet header of the subpackage 1 in the request message and verifies the packet header of the subpackage 1; the technical key points are as follows: when a large message is transmitted, the message is firstly fragmented, each fragment is filled into a LoRa data packet according to a format of a LoRa data packet structure, then each sub-packet is sequentially sent out in sequence, and a receiver receives all sub-packets and then recombines the sub-packets into a complete message, so that the error rate during transmission is greatly reduced, and the transmission effect is ensured.

Description

Technical Field

[0001] The present invention relates to the field of wireless communication technology, and in particular to a device communication method based on a LoRa private protocol. Background Art

[0002] In today's rapidly developing technological era, the demand for remote monitoring and data transmission is growing, covering a wide range of industries and applications, including but not limited to environmental protection, smart agriculture, industrial automation, smart cities, logistics tracking and emergency response systems; these application areas generally rely on high-performance sensor networks to collect key data (such as temperature, displacement, flow, radiation and vibration, etc.) and transmit this data to the central monitoring system in real time.

[0003] Given that most of these sensors are located in outdoor environments where electricity cannot be directly supplied, they must be able to operate in low-power mode. In addition, given that the distance between the monitoring point and the monitoring center is usually very far, the sensor equipment must be capable of long-distance data transmission. Existing wireless communication technologies, such as Wi-Fi, are not suitable for large-scale remote monitoring networks due to their transmission distance and power consumption limitations. Similarly, although cellular network technologies such as 2G / 3G / 4G can achieve long-distance data transmission, their high deployment costs and high power consumption limit their practicality in these applications. In particular, when the amount of data transmitted is too large, it is very easy to cause transmission errors or affect the transmission effect. Summary of the invention

[0004] 1. Technical issues to be resolved

[0005] In view of the shortcomings of the prior art, the present invention provides a device communication method based on the LoRa private protocol. When transmitting a large message, the message is first fragmented, and each fragment is filled into a LoRa data packet according to the format of the LoRa data packet structure, and then each packet is sent out in sequence. After the receiver receives all the packets, they are reassembled into a complete message, which greatly reduces the error rate during transmission, ensures the transmission effect, and solves the problems raised in the background technology.

[0006] (II) Technical solution

[0007] To achieve the above objectives, the present invention is implemented through the following technical solutions:

[0008] A device communication method based on LoRa private protocol comprises the following steps:

[0009] The communication request initiator generates a request message and performs message packetization when the request message size exceeds the limit;

[0010] The initiator of the communication request sends out all message sub-packets in sequence starting from sub-packet 1 until the last message sub-packet is sent;

[0011] The communication request responder receives the header of sub-packet 1 in the request message, obtains the plaintext data of each sub-packet body of the message after verification and adjustment, and forms the complete message data;

[0012] The communication request responder parses the command field in the packet header of any message subpacket, uses the complete message data, performs corresponding operations and generates a response message;

[0013] The communication request responder processes the response message in packets;

[0014] The communication request responder determines whether the request message is a multicast or broadcast message;

[0015] If yes, a response message is returned according to the delay setting time T, if not, a response message is returned without delay; among them, a broadcast packet returns a response message unconditionally, a multicast packet needs to determine whether it is in the group, and a unicast packet needs to match the entire destination device serial number dest_SN before returning a response message, and no response is made in other cases;

[0016] The initiator of the communication request receives the message subpackets of all response messages and obtains the decrypted complete message data.

[0017] Furthermore, the request message size exceeds the limit, which means that the request message size exceeds the maximum length limit of LoRa single packet transmission;

[0018] The message packet includes a packet header, a packet body and a packet tail; wherein the data in the packet header includes a packet start flag field, a packet length field, a packet option field, a destination device serial number field, a source device serial number field, a packet serial number field, a command field, a random key field and a packet header check field;

[0019] The data in the package body includes the payload data as source data;

[0020] The data in the packet tail is the verification data, which is the verification information generated by taking the data in the packet header and the packet body as input, and is used to determine whether the data is sent incorrectly during the transmission process.

[0021] Furthermore, the packet start flag field describes the starting position of the data of a packet, and combined with the packet length field, the starting and ending positions of the data belonging to a packet are obtained;

[0022] The packet length field describes the length of a packet, which is the total byte length from the packet header packet start flag field to the packet tail check data;

[0023] The packet option field is the auxiliary description information of the packet, which consists of several flag bits;

[0024] The destination device serial number field describes the identity information of the packet responder. The device that receives the packet uses the serial number to match the condition with its own device serial number. If the match is successful, the packet is received and processed in the next step. Otherwise, the packet is discarded.

[0025] The source device serial number field describes the identity information of the packet initiator. If the device that receives the packet needs to return a response packet, it obtains the device serial number of the corresponding target device that the response packet should return from the source device serial number field;

[0026] The packet sequence number field shows which subpacket the packet is in a complete message;

[0027] The command field describes the intent of the packet;

[0028] The random key field is used for data encryption;

[0029] The packet header check field is used to check whether an error occurs during the packet header transmission process.

[0030] Furthermore, the flag bits include but are not limited to an acknowledgment flag bit and a message end flag bit; the acknowledgment flag bit describes whether the packet is a request packet or a response packet, wherein an acknowledgment flag bit of 0 indicates a request packet, and an acknowledgment flag bit of 1 indicates a response packet, and the response packet is a response to the request packet; the message end flag bit describes whether the fragment packet is the last fragment packet of a complete message.

[0031] Furthermore, before the packet is sent, the process of adding ciphertext data is as follows: a dynamically generated random key of 2 bytes is sent, filled into the random key field of the packet header, and the plaintext data of the packet body is encrypted;

[0032] Before encryption, check whether the length of the plaintext data in the packet to be sent is an integer multiple of the random key length;

[0033] If not, the plaintext data of the packet body is padded with zeros at the end, and then two bytes are taken from the plaintext data of the packet body after the zero-padded processing and XORed with the random key to generate 2 bytes of ciphertext data. This is repeated until all the plaintext data of the packet body after the zero-padded processing is encrypted;

[0034] Discard the single ciphertext byte data generated by zero padding at the end of the packet body, intercept the original packet body length data, and fill it into the packet body.

[0035] Furthermore, after receiving the packet, the decryption process is as follows: the receiving device uses the random key in the random key field of the packet header to decrypt the ciphertext data of the packet body;

[0036] Before decryption, check whether the length of the ciphertext data in the package body is an integer multiple of the random key length;

[0037] If not, the ciphertext data of the packet body is padded with zeros at the end, and then two bytes are taken from the ciphertext data of the packet body after the zero-padded processing and XOR processing is performed with the random key to generate 2 bytes of plaintext data. This is repeated until all the ciphertext data of the packet body after the zero-padded processing is decrypted;

[0038] Discard the plaintext byte data at the end of the package body, intercept the original package body length data, and obtain the decrypted package body data.

[0039] Furthermore, the verification process is as follows:

[0040] Verify the packet header. If the verification is successful, calculate the packet body length through the packet length field in the packet header, read the packet body ciphertext data and the packet tail verification data; combine the packet header, packet body and packet tail data into a complete packet, and then decide to discard the packet or accept the packet and proceed to the next step according to the reception conditions of broadcast, multicast and unicast;

[0041] If the receiving conditions are met, the complete packet is verified. After the verification is passed, the random key field in the packet header is used to decrypt the ciphertext data in the packet body. This process is repeated to obtain the plaintext data of each message packet body and cache it.

[0042] Furthermore, the method for implementing broadcasting is:

[0043] The device serial number is split into the group number plus the device ID. When a device receives a packet and verifies that it is correct, it makes a conditional judgment on the destination device serial number in the packet header. If the group number part is 0xFFFF, it indicates that the packet is a broadcast packet, and it responds.

[0044] The method to implement multicast is:

[0045] If the group number is not 0xFFFF, but the device ID is 0xFFFFFFFF, it indicates that the packet is a multicast packet. The group number is compared with the group number in the device serial number. If they are consistent, a response is made.

[0046] The method to implement unicast is:

[0047] If the group number part is not 0xFFFF and the device ID part is not 0xFFFFFFFF, it indicates that the packet is a unicast packet, and the response is made after the serial number of its own device is consistent with the serial number of the responder device in the packet header.

[0048] Furthermore, the response message is sub-packetized, and the ACK bit in the packet header is set to 1, indicating that it is a response packet. The destination device serial number is filled with the source device serial number in the request message, and the source device serial number is filled with its own device serial number.

[0049] Furthermore, when the response message is returned according to the delay setting time length T, the calculation process of the delay setting time length T is as follows:

[0050] First, obtain the total byte length L of the current request message and the predetermined initial setting time T 0 ;

[0051] Secondly, build a mathematical function combination model to combine L and T 0 As input, the formula on which the combined model is based is as follows:

[0052]

[0053] In the formula, C represents a constant used to adjust the influence of the logarithmic function on T, and the value range of C is 1 to 10, and G represents a random factor, and the value range is 0 to 1;

[0054] Finally, the calculated delay setting time length T is output.

[0055] (III) Beneficial effects

[0056] The present invention provides a device communication method based on the LoRa private protocol, which has the following beneficial effects:

[0057] The communication method adopts the request-response mode. The initiator sends a request message, and the responder receives the request message, performs the corresponding operation and returns the response message. The sender of the request message receives the response message and performs the corresponding processing. In order to solve the limitation that the length of the data sent by LoRa at a time cannot exceed 256 bytes, a LoRa data packet structure is designed. When transmitting a large message, the message is first fragmented, and each fragment is filled into the LoRa data packet according to the format of the LoRa data packet structure. Then, each packet is sent out in sequence. After the receiver receives all the packets, they are reassembled into a complete message.

[0058] Using this LoRa data packet structure, one-to-one and one-to-many communication can be achieved between the communication request initiator and the communication request responder; one-to-one communication is unicast communication, and one-to-many communication can be achieved for multicast and broadcast communication; in one-to-many communication, in order to prevent multiple communication request responders from returning response messages at the same time to cause data collision, a random delay response mechanism is designed, and the delay is set dynamically according to the actual situation, which reduces the probability of data collision while ensuring the accuracy and effectiveness of the delay setting; considering the need for data transmission security, the designed LoRa data packet structure supports encryption and decryption of message data. By using this communication method and relaying with multiple devices, data can be transmitted over long distances in real time, ensuring the transmission effect. BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 This is a schematic diagram of the LoRa data packet structure of the present invention;

[0060] Figure 2 This is a schematic diagram of the data encryption and decryption method of the present invention;

[0061] Figure 3 It is a schematic diagram of the communication mode of the present invention;

[0062] Figure 4 It is a schematic diagram of the communication timing of the present invention. DETAILED DESCRIPTION

[0063] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0064] Embodiment 1

[0065] Reference Figure 1 A device communication method based on the LoRa private protocol. When transmitting data between devices, packets are used as the basic unit. Due to the technical characteristics of LoRa, the maximum data length of a single LoRa transmission packet is generally 256 bytes. In order to transmit messages that exceed this length limit, a method is designed to fragment the message. The size of each fragmented packet is no greater than the limited length. The receiver assembles the complete message after receiving all the fragments.

[0066] In this embodiment, the packet content consists of three parts: a packet header, a packet body, and a packet tail; the packet header is used to describe information such as the packet length, the identity information of the packet sender, the identity information of the packet receiver, and the meaning of the packet body payload data; the packet body payload data is the source data, such as sensor status information data, device control information data, etc.; the packet tail check data is the check information generated with the packet header and the packet body data as input, and the packet receiver determines whether the data is sent incorrectly during the transmission process through the packet tail check information;

[0067] The packet header can be subdivided into the packet start flag field SOP, the packet length field length, the packet option field option, the destination device serial number field dest_SN_1~2, the source device serial number field source_SN_1~2, the packet sequence number field seq_number, the command field command, the random key field random_key and the packet header check field Header_CRC16;

[0068] The packet start flag field describes the starting position of the data in a packet. Combined with the packet length, the starting and ending positions of the data belonging to a packet can be obtained. In actual application, it needs to be fixed to a certain value, such as 0xAAAA.

[0069] The packet length field describes the length of a packet, indicating the total byte length from the packet header start flag field to the packet tail check data.

[0070] The packet option field is the auxiliary description information of the packet, which consists of multiple flag bits, such as the reply flag bit, the message end flag bit, etc.; the reply flag bit describes whether the packet is a request packet (the reply flag bit is 0) or a response packet (the reply flag bit is 1). The response packet is a response to the request packet. For example, the communication request sender sends a request packet to obtain sensor data, and the communication request responder returns a response packet with sensor data after receiving the request packet. The message end flag bit describes whether the fragment packet is the last fragment packet of a complete message (0 indicates the last fragment packet);

[0071] The destination device serial number field describes the identity information of the packet receiver. The device that receives the packet uses the serial number to match its own serial number. If the match is successful, the packet data is processed in the next step, otherwise the packet data is discarded.

[0072] The source device serial number field describes the identity information of the packet sender. If the device that receives the packet needs to return a response packet, it can learn from the source device serial number field which device the response packet should be returned to.

[0073] The packet sequence number field indicates the number of fragments of a complete message.

[0074] The command field describes the intention of the packet, such as whether the packet is a request packet for obtaining sensor data or setting certain switches. In addition, the receiver also understands the packet body data based on the command field.

[0075] The random key field is used for data encryption to prevent data from being stolen. Transmitting the random key in the header of each packet has two functions. First, the communicating devices are exempted from the tedious process of configuring the key. The key required by the receiver to decrypt the packet data can be found directly in the header. Second, the key is randomly generated. Even if the packet data is the same and the same encryption method is used, the keys are different and the encrypted data generated is different, which reduces the probability of the encrypted data being deciphered.

[0076] The packet header checksum field is used to check whether errors occur during packet header transmission;

[0077] The length of the packet header is a fixed value. After receiving the LoRa data, the receiving device looks for the packet start flag SOP. After finding it, it reads the packet header length data, takes out the data before the packet header check field to generate a CRC16 check value, and compares it with the packet header check field. If they are consistent, the packet length is subtracted from the packet header length to obtain the total length of the packet body length and the packet tail check data, and then the packet body data and the packet tail check data are read. Then the packet header data and the packet body data are used to generate a CRC32 check value, and compared with the packet tail check data. If they are consistent, it indicates that there is no error in the transmission of the packet.

[0078] Embodiment 2

[0079] Reference Figure 2 A device communication method based on the LoRa private protocol can realize three communication modes: unicast, multicast and broadcast; the implementation method is to split the device serial number into a group number plus a device ID; when a device receives a packet and verifies it, it makes a conditional judgment on the destination device serial number in the packet header. If the group number part is 0xFFFF, it indicates that the packet is a broadcast packet and needs to be responded to; if the group number part is not 0xFFFF, but the device ID part is 0xFFFFFFFF, it indicates that the packet is a multicast packet, and then the group number is compared with the group number in its own device serial number. If they are consistent, a response is required; if the group number part is not 0xFFFF and the device ID part is not 0xFFFFFFFF, it indicates that the packet is a unicast packet, and the device serial number of the device itself and the receiving device serial number in the packet header are completely consistent before a response can be made.

[0080] Embodiment 3

[0081] Reference Figure 3 , a device communication method based on the LoRa private protocol can encrypt the transmitted data to prevent the data from being stolen; before the packet is sent, the sending device dynamically generates a random key random_key with a length of 2 bytes and fills it into the random key field of the packet header, and uses it to encrypt the plaintext data of the packet body; before encryption, check whether the length of the plaintext data of the packet body to be sent is an integer multiple of the length of the random key, if not, the plaintext data of the packet body is padded with zeros at the end, that is, the byte 0x00 is added; then, two bytes are taken from the plaintext data of the packet body after the zero-padded processing each time, and XOR processing is performed with the random key to generate 2-byte ciphertext data, and this is repeated until all the plaintext data of the packet body after the zero-padded processing is encrypted; finally, the ciphertext byte data generated by adding the byte 0x00 data at the end of the packet body is discarded, and only the data of the original packet body length is intercepted, but it is encrypted data and filled into the packet body;

[0082] After receiving the packet, the receiving device uses the random key in the random key field of the packet header to decrypt the ciphertext data in the packet body. Similarly, before decryption, it is necessary to check whether the length of the ciphertext data in the packet body is an integer multiple of the length of the random key. If not, the ciphertext data in the packet body is padded with zeros at the end. Subsequently, two bytes are taken from the ciphertext data in the packet body after the zero-padded processing each time and XORed with the random key to generate 2 bytes of plaintext data. This is repeated until all the ciphertext data in the packet body after the zero-padded processing is decrypted. Finally, the plaintext byte data generated by adding the byte 0x00 data at the end of the packet body is discarded, and only the data of the original packet body length is intercepted, that is, the decrypted packet body data is obtained.

[0083] The above provides a simple data encryption and decryption method, which is suitable for devices and systems with weak computing power. If the computing power of the device is strong, or it is equipped with a hardware AES encryption and decryption module, encryption and decryption methods such as AES128 and AES256 can be used. When using the AES encryption and decryption method, the packet header random key field, the destination device serial number field, the source device serial number field, the packet serial number field and other fields can be combined with the method of supplementing 0x00 data to generate a 128-bit or 256-bit key. The actual method of permutation and combination can be determined by yourself to reduce the risk of data being deciphered due to leakage of the key generation method.

[0084] Embodiment 4

[0085] Reference Figure 4 , a device communication method based on the LoRa private protocol, the actual communication timing process is described in the following steps: S1, the communication request initiator generates a request message, if the request message size exceeds the maximum length limit of the LoRa single packet transmission, the message is sub-packetized. In the packet header setting, the packet start flag field is fixed to 0xAAAA; the packet length is set according to the actual size of each sub-packet. The ACK bits are all set to 0, indicating that it is a request packet; the MF bit of the last subpacket is set to 0, indicating that it is the last subpacket of the complete message, and the MF bits of the remaining subpackets are set to 1; the source device serial number is filled with its own device serial number; the destination device serial number is filled according to whether the scope of the request message is unicast, multicast or broadcast; the packet sequence number is set from 1 for the first subpacket to n for the last subpacket, where n is determined by the actual message size; the command field is filled according to the actual request command, and each subpacket is filled with the same value; the random key field is filled with a dynamically generated random key, which is different for each subpacket; the header check value field is filled with a CRC16 check value generated based on the other header fields filled above; then, each subpacket uses the random key in its own header to encrypt its own packet body data; finally, the tail check value is filled with a CRC32 check value generated based on the previously filled header and the encrypted packet body data.

[0086] S2. The communication request initiator sends out all message subpackets generated in S1 in sequence starting from subpacket 1 until the last message subpacket is sent.

[0087] S3. The communication request responder receives the header of the request message sub-packet 1 and verifies the header; after the verification is passed, the length of the packet body is calculated through the packet length field in the header, and the ciphertext data of the packet body and the verification data of the tail are read; the header, body and tail data are combined into a complete packet, and then according to the receiving conditions of broadcast, multicast and unicast, it is decided whether to discard the packet or receive the packet and proceed to the next step; if the receiving conditions are met, the whole packet is verified. After the verification is passed, the ciphertext data of the packet body is decrypted using the random key field in the header to obtain the plaintext data of the packet body of message sub-packet 1 and cache it; this is repeated until the plaintext data of the last message sub-packet body is obtained and cached; finally, all cached plaintext data of the packet body are combined into a complete message data.

[0088] S4. The communication request responder understands and uses the complete message data finally generated by S3 according to the meaning of the command field in the header of any message sub-packet in S3, performs corresponding operations and generates a response message.

[0089] S5. The communication request responder divides the response message of S4 into packets, sets the ACK bit in the packet header to 1 to indicate that it is a response packet, fills the source device serial number in the request message with the destination device serial number, and fills the source device serial number with its own device serial number. The remaining packet header field filling, packet body data encryption, and packet tail check value filling methods are the same as those described in S1.

[0090] S6, the communication request responder determines whether the request message is a multicast or broadcast message. If so, it returns the response message according to the delay setting time T to prevent multiple responders from returning response messages at the same time, causing data collision. When returning the response message, all the message subpackets generated in S5 are sent out in sequence starting from subpacket 1 until the last message subpacket is sent;

[0091] When the response message is returned according to the delay setting time length T, the calculation process of the delay setting time length T is as follows:

[0092] First, obtain the total byte length L of the current request message and the predetermined initial setting time T 0 ;

[0093] Secondly, build a mathematical function combination model to combine L and T 0 As input, the formula on which the combined model is based is as follows:

[0094]

[0095] Wherein, C represents a constant used to adjust the influence of the logarithmic function on T, and the value range of C is 1 to 10. The value in this embodiment is usually 10. By selecting a suitable C value, the influence of the packet length L on T can be controlled. Logarithmic function: log 2 (L+1) is used to introduce a nonlinear relationship. Since the logarithmic function grows more slowly when the input value is large, this helps prevent a small change in the packet length L from causing a sharp increase in T. At the same time, L+1 ensures that the value inside the logarithmic function is always greater than zero. T 0 A basic value of delay is provided. Even if the total byte length is zero, there will be a non-zero delay. G represents a random factor, which ranges from 0 to 1. Different devices have different random factors. After the random factor is introduced, even if the length of the broadcast or multicast packet received by multiple receivers is the same as L, the final calculated delay setting time length T is different, thus avoiding data collision.

[0096] Finally, the calculated delay setting time T is output;

[0097] S7. The communication request initiator receives all response message subpackets according to the method described in S3, and obtains the decrypted complete response message data; the communication request initiator performs further processing on the response message data, which will not be described in detail here.

[0098] S8. Communication ends.

[0099] In the application, the several formulas involved are all calculated by taking their numerical values ​​after removing the dimensions, and the formulas are established by collecting a large amount of data and performing software simulation to obtain a formula for the most recent actual situation. Some coefficients or weights in the formulas are set by technical personnel in this field according to actual conditions, so they will not be elaborated here.

[0100] The above embodiments may be implemented in whole or in part by software, hardware, firmware or any other combination thereof. When implemented using software, the above embodiments may be implemented in whole or in part in the form of a computer program product. A person of ordinary skill in the art may appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein may be implemented in electronic hardware, or in a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution.

[0101] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, and may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0102] The above description is only a specific implementation manner of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application.

Claims

1. A device communication method based on LoRa private protocol, characterized in that: The steps of this method are as follows: The communication request initiator generates a request message and performs message packetization when the request message size exceeds the limit; The initiator of the communication request sends out all message sub-packets in sequence starting from sub-packet 1 until the last message sub-packet is sent; The communication request responder receives the header of sub-packet 1 in the request message, obtains the plaintext data of each sub-packet body of the message after verification and adjustment, and forms the complete message data; The communication request responder parses the command field in the packet header of any message subpacket, uses the complete message data, performs corresponding operations and generates a response message; The communication request responder processes the response message in packets; The communication request responder determines whether the request message is a multicast or broadcast message; If yes, a response message is returned according to the delay setting time T, if not, a response message is returned without delay; among them, a broadcast packet returns a response message unconditionally, a multicast packet needs to determine whether it is in the group, and a unicast packet needs to match the entire destination device serial number dest_SN before returning a response message, and no response is made in other cases; The initiator of the communication request receives the message subpackets of all response messages and obtains the decrypted complete message data.

2. A device communication method based on LoRa private protocol according to claim 1, characterized in that: The request message size exceeds the limit, which means that the request message size exceeds the maximum length limit of LoRa single packet transmission; The message packet includes a packet header, a packet body and a packet tail; wherein the data in the packet header includes a packet start flag field, a packet length field, a packet option field, a destination device serial number field, a source device serial number field, a packet serial number field, a command field, a random key field and a packet header check field; The data in the package body includes the payload data as source data; The data in the packet tail is the verification data, which is the verification information generated by taking the data in the packet header and the packet body as input, and is used to determine whether the data is sent incorrectly during the transmission process.

3. A device communication method based on LoRa private protocol according to claim 2, characterized in that: The packet start flag field describes the starting position of the data in a packet, and combined with the packet length field, the starting and ending positions of the data belonging to a packet are obtained; The packet length field describes the length of a packet, which is the total byte length from the packet header packet start flag field to the packet tail check data; The packet option field is the auxiliary description information of the packet, which consists of several flag bits; The destination device serial number field describes the identity information of the packet responder. The device that receives the packet uses the serial number to match the condition with its own device serial number. If the match is successful, the packet is received and processed in the next step. Otherwise, the packet is discarded. The source device serial number field describes the identity information of the packet initiator. If the device that receives the packet needs to return a response packet, it obtains the device serial number of the corresponding target device that the response packet should return from the source device serial number field; The packet sequence number field shows which subpacket the packet is in a complete message; The command field describes the intent of the packet; The random key field is used for data encryption; The packet header check field is used to check whether an error occurs during the packet header transmission process.

4. A device communication method based on LoRa private protocol according to claim 3, characterized in that: The flag bits include but are not limited to the acknowledgment flag bit and the message end flag bit; the acknowledgment flag bit describes whether the packet is a request packet or a response packet, wherein the acknowledgment flag bit is 0 for a request packet, and the acknowledgment flag bit is 1 for a response packet, and the response packet is a response to the request packet. The message end flag bit describes whether the fragment packet is the last fragment packet of a complete message.

5. A device communication method based on LoRa private protocol according to claim 3, characterized in that: Before sending a packet, the process of adding ciphertext data is as follows: Send a dynamically generated 2-byte random key, fill it into the random key field in the packet header, and encrypt the plaintext data in the packet body; Before encryption, check whether the length of the plaintext data in the packet to be sent is an integer multiple of the random key length; If not, the plaintext data of the packet body is padded with zeros at the end, and then two bytes are taken from the plaintext data of the packet body after the zero-padded processing and XORed with the random key to generate 2 bytes of ciphertext data. This is repeated until all the plaintext data of the packet body after the zero-padded processing is encrypted; The single ciphertext byte data generated by zero padding at the end of the packet body is discarded, the original packet body length data is intercepted, and it is filled into the packet body.

6. A device communication method based on LoRa private protocol according to claim 5, characterized in that: After receiving the packet, the decryption process is as follows: the receiving device uses the random key in the random key field of the packet header to decrypt the ciphertext data in the packet body; Before decryption, check whether the length of the ciphertext data in the package body is an integer multiple of the random key length; If not, the ciphertext data of the packet body is padded with zeros at the end, and then two bytes are taken from the ciphertext data of the packet body after the zero-padded processing and XOR processing is performed with the random key to generate 2 bytes of plaintext data. This is repeated until all the ciphertext data of the packet body after the zero-padded processing is decrypted; Discard the plaintext byte data at the end of the package body, intercept the original package body length data, and obtain the decrypted package body data.

7. A device communication method based on LoRa private protocol according to claim 1, characterized in that: The verification process is as follows: Verify the packet header. If the verification is successful, calculate the packet body length through the packet length field in the packet header, read the packet body ciphertext data and the packet tail verification data; combine the packet header, packet body and packet tail data into a complete packet, and then decide to discard the packet or accept the packet and proceed to the next step according to the reception conditions of broadcast, multicast and unicast; If the receiving conditions are met, the complete packet is verified. After the verification is passed, the random key field in the packet header is used to decrypt the ciphertext data in the packet body. This process is repeated to obtain the plaintext data of each message packet body and cache it.

8. A device communication method based on LoRa private protocol according to claim 7, characterized in that: The method to implement broadcasting is: The device serial number is split into the group number plus the device ID. When a device receives a packet and verifies that it is correct, it makes a conditional judgment on the destination device serial number in the packet header. If the group number part is 0xFFFF, it indicates that the packet is a broadcast packet, and it responds. The method to implement multicast is: If the group number is not 0xFFFF, but the device ID is 0xFFFFFFFF, it indicates that the packet is a multicast packet. The group number is compared with the group number in the device serial number. If they are consistent, a response is made. The method to implement unicast is: If the group number part is not 0xFFFF and the device ID part is not 0xFFFFFFFF, it indicates that the packet is a unicast packet, and the response is made after the serial number of its own device is consistent with the responder device serial number in the packet header.

9. A device communication method based on LoRa private protocol according to claim 1, characterized in that: The response message is sub-packetized, and the ACK bit in the packet header is set to 1, indicating that it is a response packet. The destination device serial number is filled with the source device serial number in the request message, and the source device serial number is filled with its own device serial number.

10. A device communication method based on LoRa private protocol according to claim 1, characterized in that: When the response message is returned according to the delay setting time T, the calculation process of the delay setting time T is as follows: First, obtain the total byte length L of the current request message and the predetermined initial setting time length T0; Secondly, a mathematical function combination model is built, taking L and T0 as input. The formula based on this combination model is as follows: In the formula, C represents a constant used to adjust the influence of the logarithmic function on T, and the value range of C is 1 to 10, and G represents a random factor, and the value range is 0 to 1; Finally, the calculated delay setting time length T is output.

Images