A device communication method based on a LoRa private protocol

Abstract

The application discloses a device communication method based on a LoRa private protocol and relates to the technical field of wireless communication.The steps of the method comprise the following steps: a communication request initiator generates a request message, and packet splitting is performed under the condition that the size of the request message exceeds the maximum length limit of LoRa single package transmission; the packet splitting comprises a packet header, a packet body and a packet tail; the communication request initiator successively sends all the packet splits from the first packet split until the last packet split is sent; and a communication request responder receives the packet header of the first packet split in the request message and checks the packet header of the first packet split.The technical key points are as follows: when a large message is transmitted, the message is first split into fragments, each fragment is filled into a LoRa data package according to the format of the LoRa data package structure, then each packet is successively sent, and after all the packets are received by a receiver, the complete message is recombined, so that the failure rate during transmission is greatly reduced, and the transmission effect is ensured.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of wireless communication, in particular to a device communication method based on LoRa private protocol. BACKGROUND

[0002] In today's rapidly developing technology 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, intelligent agriculture, industrial automation, smart city, logistics tracking and emergency response system; these application fields generally rely on high-performance sensor networks to collect key data (such as temperature, displacement, flow, radiation and vibration, etc.) and transmit these data to the central monitoring system in real time.

[0003] Since most of these sensors are located in outdoor environments where power cannot be directly supplied, they must be able to operate in low-power mode; in addition, since the distance between the monitoring point and the monitoring center is usually very long, the sensor device must have the ability to transmit data over long distances; 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; especially when the data transmission volume is too large, it is very easy to cause transmission errors or affect the transmission effect. SUMMARY

[0004] (I) Technical problems solved

[0005] In view of the deficiencies of the prior art, the present application provides a device communication method based on LoRa private protocol; when transmitting large messages, 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, then each packet is sent in order, and the receiving party reassembles the complete message after receiving all the packets, greatly reducing the error rate during transmission and ensuring the transmission effect, solving the problems raised in the background art.

[0006] (II) Technical solutions

[0007] To achieve the above purpose, the present application is implemented by the following technical solutions:

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

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

[0010] The communication request initiator sends all message fragments from fragment 1 in order until the last message fragment is sent.

[0011] The communication request responder receives the packet header of the first packet in the request packet, and after verification and adjustment, obtains the plaintext data of each packet body and composes complete packet data;

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

[0013] The communication request responder divides the response packet;

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

[0015] If yes, the response packet is returned after a delay of time T, and if no, the response packet is returned without delay; among them, the broadcast packet returns the response packet unconditionally, the multicast packet judges whether it is in the group, the unicast packet returns the response packet only when the destination device serial number dest_SN matches, and the rest of the cases do not respond;

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

[0017] Further, the request packet size exceeds the limit means that the request packet size exceeds the maximum length limit of LoRa single packet transmission under the condition that

[0018] The packet data 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 sequence number field, a command field, a random key field and a packet header verification field;

[0019] The data in the packet body includes the payload data as the 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 judge whether the data is sent incorrectly in the transmission process.

[0021] Further, the packet start flag field describes the starting position of the data of a packet, and in combination with the packet length field, the beginning and end 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 start flag field in the packet header to the verification data in the packet tail;

[0023] The packet option field is auxiliary description information of the packet, which is composed of a plurality of flag bits;

[0024] The device serial number field describes the identity information of the packet responder, and the receiving device uses the sequence number to conditionally match with the device serial number of the receiving device. If the matching is successful, the receiving device processes the packet and performs 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 receiving device needs to return a response packet, the device serial number of the corresponding target device to which the response packet should be returned is obtained from the source device serial number field;

[0026] The packet sequence number field shows the number of the packet in a complete message;

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

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

[0029] The packet header verification field is used to verify whether an error occurs in the transmission process of the packet header.

[0030] Further, the flag bits include but are not limited to a response flag bit and a message end flag bit. The response flag bit describes whether the packet is a request packet or a response packet. The response flag bit is 0 for a request packet and 1 for a response packet. The response packet is a response to the request packet. The message end flag bit describes whether the packet is the last packet of a complete message.

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

[0032] 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;

[0033] If not, perform zero padding processing on the plaintext data of the packet body, and then take out two bytes of the zero-padded plaintext data of the packet body each time and perform XOR processing with the random key to generate 2-byte ciphertext data. Repeat this process until the zero-padded plaintext data of the packet body is completely encrypted;

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

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

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

[0037] If not, the end of the package body cipher data is zero-filled, and then two bytes of the zero-filled package body cipher data are taken out each time to be XOR processed with the random key to generate 2-byte plaintext data, and the process is repeated until the zero-filled package body cipher data is completely decrypted;

[0038] The last byte of plaintext data of the package body is discarded, and the original package length data is intercepted to obtain the decrypted package data.

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

[0040] The package header is verified, and after the verification is passed, the package length is calculated through the package length field in the package header, the package cipher data and the package tail verification data are read; the package header, the package body and the package tail data are combined into a complete package, and then it is determined whether to discard the package or receive the package and perform the next step of processing according to the receiving conditions of broadcast, multicast and unicast;

[0041] If the receiving conditions are met, the complete package is verified, and after the verification is passed, the package cipher data is decrypted using the random key field in the package header, and the process is repeated to obtain each message packet body plaintext data and cache.

[0042] Further, the method for realizing broadcast is as follows:

[0043] The device serial number is split into a group number and a device ID, and when a device receives a package and verifies that it is correct, the destination device serial number in the package header is conditionally judged. If the group number part is 0xFFFF, it means that the package is a broadcast package, and a response is performed;

[0044] The method for realizing multicast is as follows:

[0045] If the group number part is not 0xFFFF, but the device ID part is 0xFFFFFFFF, it means that the package is a multicast package, and the group number is compared with the group number in the own device serial number. If they are consistent, a response is performed;

[0046] The method for realizing unicast is as follows:

[0047] If the group number part is not 0xFFFF, and the device ID part is also not 0xFFFFFFFF, it means that the package is a unicast package, and a response is performed after the own device serial number and the responder device serial number in the package header are consistent.

[0048] Further, the response message is packetized, the ACK bit in the package header is set to 1, indicating that it is a response package, 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 the own device serial number.

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

[0050] First, the total byte length L of the current request message and the predetermined initial setting duration T0 are obtained;

[0051] Second, a mathematical function combination model is built, taking L and T0 as inputs, and the formula on which the combination model is based is as follows:

[0052]

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

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

[0055] (Three) beneficial effects

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

[0057] The communication method adopts a request and response mode, an initiator sends a request message, a responder receives the request message, performs corresponding operations, and returns a response message, and the sender of the request message receives the response message and performs corresponding processing, in order to solve the limitation that the length of data sent by LoRa at a time cannot exceed 256 bytes, a LoRa data packet structure is designed, when a large message is transmitted, 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, then the sub-packets are sequentially sent in order, and the receiver receives all the sub-packets and then recombines them into a complete message;

[0058] Using the LoRa data packet structure, one-to-one and one-to-many communication between a communication request initiator and a communication request responder can be realized; one-to-one communication is unicast communication, and one-to-many communication can realize groupcast and broadcast communication; in one-to-many communication, in order to prevent multiple communication request responders from returning response messages at the same time and causing data collision, a random delay response mechanism is designed, the delay is dynamically set according to actual conditions, the probability of data collision is reduced, and the accuracy and effectiveness of the delay setting are ensured; considering the need for data transmission security, the designed LoRa data packet structure supports encryption and decryption of message data, using the set of communication methods and using multiple devices for relaying, data can be transmitted over a long distance in real time, and the transmission effect is ensured. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1 It is a schematic diagram of the LoRa data packet structure of the application;

[0060] Figure 2 It is a schematic diagram of the data encryption and decryption method of the application;

[0061] Figure 3 A communication mode schematic diagram of the present application;

[0062] Figure 4 A communication timing schematic diagram of the present application. DETAILED DESCRIPTION

[0063] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0064] Embodiment one

[0065] With reference to Figure 1 A device communication method based on a LoRa private protocol, data transmission between devices is performed in a packet as a basic unit. Due to the technical characteristics of LoRa, the maximum data length of a packet transmitted by LoRa at a time is generally 256 bytes. In order to be able to transmit a message whose length exceeds this length limit, a method is designed to fragment the message, and the size of each packet after fragmentation is not greater than the limit length. The receiver assembles the complete message after receiving all the fragments.

[0066] In this embodiment, the packet content is composed of a packet header, a packet body and a packet tail. The packet header is used to describe the packet length, the packet sender identity information, the packet receiver identity information, the packet body load data meaning and other information. The packet body load data is source data, such as sensor state information data, device control information data, etc. The packet tail check data is check information generated by taking the packet header and packet body data as input. The packet receiver judges whether the data is sent incorrectly in the transmission process through the packet tail check information.

[0067] The packet header can be subdivided into a packet start-of-packet (SOP) field, a packet length field, a packet option field, a destination device serial number field (dest_SN_1-2), a source device serial number field (source_SN_1-2), a packet sequence number field (seq_number), a command field, a random key field, and a packet header check field (Header_CRC16).

[0068] The packet start-of-packet field describes the starting position of the data of a packet. In combination with the packet length, the beginning and end 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 section describes the length of a packet, indicating the total byte length from the packet head packet start flag field to the packet tail check data.

[0070] The packet option field is auxiliary description information of the packet, composed of multiple flag bits, such as a response flag bit and a message end flag bit. The response flag bit describes whether the packet is a request packet (the response flag bit is 0) or a response packet (the response flag bit is 1). The response packet is a response to the request packet. For example, the communication request sender sends a request packet for obtaining 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 packet is the last packet of a complete message (0 indicates the last packet).

[0071] The destination device serial number field describes the identity information of the packet receiver. The device receiving the packet uses the serial number to conditionally match its own serial number. If the matching is successful, the packet data is processed further, otherwise the packet data is discarded.

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

[0073] The packet serial number field describes the number of the packet as a complete message packet.

[0074] The command field describes the intention of the packet, such as a request packet for obtaining sensor data, or setting open some switches, etc. In addition, the receiver also understands the packet body data according to the command field.

[0075] The random key field is used for data encryption to prevent data from being stolen. Transmitting a random key in the header of each packet has two effects. First, the communication device eliminates the cumbersome process of configuring the key, and the key required by the receiver to decrypt the packet body data can be found directly in the packet header. Second, the key is randomly generated. Even if the same packet body data uses the same encryption method, the final encrypted data will not be the same if the key is different, reducing the probability of encrypted data being cracked.

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

[0077] The length of the packet header is a fixed value. After receiving the LoRa data, the receiving device searches for the packet start symbol SOP, reads the packet header length data after finding the packet start symbol, generates a CRC16 check value from the data before the packet header check field, and compares it with the packet header check field. If they are consistent, the packet length length is reduced by 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 CRC32 check value is generated from the packet header data and the packet body data, and compared with the packet tail check data. If they are consistent, it means that the packet has no error during transmission.

[0078] Embodiment two

[0079] With reference to Figure 2 A device communication method based on the LoRa private protocol can realize three communication modes of unicast, groupcast and broadcast. The implementation method is to split the device serial number into a group number and a device ID. When a device receives a packet and checks that it is correct, the destination device serial number of the packet header is conditionally judged. If the group number part is 0xFFFF, it means that the packet is a broadcast packet and needs to be responded. If the group number part is not 0xFFFF, but the device ID part is 0xFFFFFFFF, it means that the packet is a groupcast packet, and then the group number is compared with the group number in the own device serial number. If they are consistent, a response is needed. If the group number part is not 0xFFFF and the device ID part is not 0xFFFFFFFF, it means that the packet is a unicast packet, and the own device serial number and the receiver device serial number in the packet header must be completely consistent to respond.

[0080] Embodiment three

[0081] With reference to Figure 3 A device communication method based on the LoRa private protocol can encrypt the transmitted data to prevent data from being stolen. Before sending the packet, the sending device dynamically generates a 2-byte random key random_key and fills it into the packet header random key field, and uses it to encrypt the packet body plaintext data. Before encryption, check whether the length of the packet body plaintext data to be sent is an integer multiple of the length of the random key. If not, perform zero padding processing on the end of the packet body plaintext data, that is, add 0x00 byte processing. Then, every time two bytes of the zero-padded packet body plaintext data are taken out and XOR processed with the random key to generate 2-byte ciphertext data. This is repeated until all the zero-padded packet body plaintext data are encrypted. Finally, discard the ciphertext byte data generated at the end of the packet body due to the addition of the 0x00 byte data, and only extract the original packet body length data, but fill it into the packet body as encrypted data.

[0082] After receiving the packet, the receiving device uses the random key in the packet header random key field to decrypt the packet body ciphertext data; similarly, before decryption, it is necessary to check whether the length of the packet body ciphertext data is an integer multiple of the length of the random key, and if not, to perform zero padding at the end of the packet body ciphertext data; then, every time two bytes of the zero-padded packet body ciphertext data are taken out and XORed with the random key to generate 2-byte plaintext data, and this is repeated until the zero-padded packet body ciphertext data is completely decrypted; finally, the plaintext byte data generated at the end of the packet body due to the addition of the 0x00 data is discarded, and only the data of the original packet body length is intercepted, i.e., the decrypted packet body data is obtained.

[0083] The above provides a simple data encryption and decryption method suitable for devices and systems with weak computing power; if the device has strong computing power or is equipped with a hardware AES encryption and decryption module, AES128, AES256, etc. encryption and decryption methods 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 sequence number field, etc. can be combined with the 0x00 data padding method to generate a 128-bit or 256-bit key; the actual arrangement and combination method can be determined by oneself, reducing the risk of data being cracked due to key generation method leakage.

[0084] Embodiment Four

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

[0086] S2, the communication request initiator sends all the packet packages generated in S1 from package 1 in turn until the last packet package is sent.

[0087] S3, the communication request responder receives the request packet package 1 header, checks the header; after the check passes, the package length field in the header is used to calculate the package body length, the package body ciphertext data and the package tail check data are read; the header, the package body and the package tail data are combined into a complete package, and then it is decided whether to discard the package or to receive the package and perform the next step of processing according to the receiving conditions of broadcast, multicast and unicast; if the receiving conditions are met, the whole package is checked. After the check passes, the package body ciphertext data is decrypted using the random key field in the header to obtain the package body plaintext data and cache; this is repeated until the last packet package body plaintext data is obtained and cached; finally, all the cached package body plaintext data is combined into a complete message data.

[0088] S4, the communication request responder understands and uses the complete message data generated in S3 according to the meaning of the command field in the header of any one message package, performs the corresponding operation and generates a response message.

[0089] S5, the communication request responder performs packet processing on the response message of S4, sets the ACK bit in the header to 1 to indicate that it is a response package, fills the source device sequence number in the request message into the destination device sequence number, fills the source device sequence number with the self device sequence number, and fills the remaining header fields, encrypts the package body data, and fills the package tail check value in the same way as described in S1.

[0090] S6, the communication request responder judges whether the request message is a multicast or broadcast message, if so, it returns the response message again 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 packet packages generated in S5 are sent from package 1 in turn until the last packet package is sent.

[0091] Wherein, when returning the response message according to the delay setting time T, the calculation process of the delay setting time T is as follows:

[0092] First, the total byte length L of the current request message and the predetermined initial setting time T0 are obtained;

[0093] Second, a mathematical function combination model is built, taking L and T0 as input, and the formula on which the combination model is based is as follows:

[0094]

[0095] In the formula, C represents a constant for adjusting the degree of influence of the logarithmic function on T, and the value range of C is 1-10, and the value in the embodiment is usually 10, and by selecting a suitable C value, the degree of influence of the packet length L on T can be controlled; the logarithmic function: log2(L+1) is used to introduce a nonlinear relationship, and since the logarithmic function grows slowly when the input value is large, this helps to prevent the slight change of the packet length L from causing the sharp increase of T; at the same time, L+1 ensures that the value inside the logarithmic function is always greater than zero; T0 provides a basic value of the delay, even if the total byte length is zero, there will be a non-zero delay; G represents a random factor, and the value range is 0-1; different devices take different values of the random factor; after the introduction of the random factor, even if the lengths of the broadcast or multicast packets received by multiple receivers are all L, the values of the delay setting time T calculated finally are also different, avoiding data collision;

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

[0097] S7, the communication request initiator receives all response packet data according to the method described in S3, and obtains the decrypted complete response packet data; the communication request initiator processes the response packet data further, which is not described here.

[0098] S8, the communication ends.

[0099] In the application, the several formulas involved are calculated by taking the values after dimensionless, and the establishment of the formula is obtained by collecting a large amount of data to simulate a formula of the nearest real situation, and part of the coefficients or weights in the formula is set by the person skilled in the art according to the actual situation, so it is not described here.

[0100] The above embodiments can be realized wholly or partially by software, hardware, firmware or any combination thereof. When realized by software, the above embodiments can be realized in the form of a computer program product wholly or partially. Those skilled in the art can realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized by hardware or software depends on the specific application and design constraints of the technical solutions.

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

[0102] The above merely provides the specific implementation of the present application, but the protection scope of the present application is not limited to this. Any person skilled in the art can easily think of the changes or replacements within the technical range disclosed by the present application, which should be covered in the protection scope of the present application.

Claims

1. A method for device communication based on LoRa private protocol, characterized in that, The steps of the method are as follows: The communication request initiator generates a request message, and performs message packeting when the request message size is over the limit; The message packeting includes a packet header, a packet body and a packet tail; 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 random key field is used for data encryption; the data in the packet tail is check data, which is check 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 in the transmission process; The communication request initiator sends all the message packets from the first packet to the last packet; The communication request responder receives the packet header of the first packet in the request message, and obtains the clear data of the packet body of each message packet after check and adjustment processing, and then composes complete message data; The communication request responder uses the complete message data to perform corresponding operations and generate a response message after analyzing the command field in the packet header of any message packet; The communication request responder performs packet processing on the response message; The communication request responder determines whether the request message is a multicast or broadcast message; the method for realizing broadcast is that: the device serial number is split into a group number and a device ID, and when a device receives a packet and checks that the packet is correct, the destination device serial number in the packet header is conditionally judged, and if the group number part is 0xFFFF, it is indicated that the packet is a broadcast packet, and then a response is performed; the method for realizing multicast is that: if the group number part is not 0xFFFF, but the device ID part is 0xFFFFFFFF, it is indicated that the packet is a multicast packet, and the group number is compared with the group number in the device serial number of the device itself, and if they are consistent, a response is performed; If yes, the response message is returned again after a delay setting time T, and if no, the response message is returned without delay; among them, the broadcast packet returns the response message without condition, the multicast packet judges whether it is in the group, the unicast packet returns the response message only when the entire destination device serial number dest_SN matches, and the rest of the cases do not respond; the calculation process of the delay setting time T is as follows: First, the total byte length L of the current request packet and the given initial setting time length T are acquired ; Secondly, the mathematical function combination model is built, and L and As input, the formula on which the combination model is based is as follows: ； In the formula, C represents a constant, which is used to adjust the influence of the logarithmic function on T, and the value range of C is 1-10, and G represents a random factor, and the value range is 0-1; Finally, the delay setting time T calculated is output; The communication request initiator receives all the message packets of the response message, and obtains the decrypted complete message data.

2. The device communication method based on the LoRa private protocol according to claim 1, characterized in that: The request message size over the limit indicates a condition that the request message size exceeds the maximum length limit of LoRa single packet transmission; The data in the packet body includes load data as source data.

3. The device communication method based on LoRa private protocol according to claim 2, characterized in that: The packet start flag field describes the data start position of a packet, and in combination with the packet length field, the start and end 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 auxiliary description information of the packet, which is composed of a plurality of flag bits; The packet start flag field describes the data start position of a packet, and in combination with the packet length field, the start and end positions of the data belonging to a packet are obtained; The destination device serial number field describes the identity information of the packet response party, and the device receiving the packet uses the serial number to conditionally match with the device serial number of the device itself. If the matching is successful, the device processes the packet and performs the next step. Otherwise, the device discards the packet. The source device serial number field describes the identity information of the packet initiator. If the device receiving the packet needs to return a response packet, the device obtains the device serial number of the corresponding target device to which the response packet should be returned from the source device serial number field. The packet serial number field shows the number of the packet in a complete message. The command field describes the intention of the packet. The packet header verification field is used to verify whether an error occurs in the transmission of the packet header.

4. The device communication method based on LoRa private protocol according to claim 3, characterized in that: The flag bit includes but is not limited to a response flag bit and a message end flag bit. The response flag bit describes whether the packet is a request packet or a response packet. The response flag bit is 0, indicating a request packet. The response flag bit is 1, indicating a response packet. The response packet is a response to the request packet. The message end flag bit describes whether the packet is the last packet of a complete message.

5. The device communication method based on LoRa private protocol according to claim 3, characterized in that: Before the packet is sent, the process of adding the ciphertext data is as follows: a dynamic random key with a length of 2 bytes is generated, filled into the packet header random key field, and the packet body plaintext data is encrypted. Before encryption, it is checked whether the length of the packet body plaintext data to be sent is an integer multiple of the length of the random key. If not, the packet body plaintext data is processed by zero padding at the end. Then, two bytes of the zero-padded packet body plaintext data are taken out each time and XOR processed with the random key to generate 2-byte ciphertext data. This is repeated until the zero-padded packet body plaintext data is completely encrypted. The single-byte ciphertext data generated at the end of the packet body due to zero padding is discarded, and the original packet body length data is intercepted and filled into the packet body.

6. The device communication method based on LoRa private protocol according to claim 5, characterized in that: After the packet is received, the decryption process is as follows: the receiving device uses the random key in the packet header random key field to decrypt the packet body ciphertext data. Before decryption, it is checked whether the length of the packet body ciphertext data is an integer multiple of the length of the random key. If not, the packet body ciphertext data is processed by zero padding at the end. Then, two bytes of the zero-padded packet body ciphertext data are taken out each time and XOR processed with the random key to generate 2-byte plaintext data. This is repeated until the zero-padded packet body ciphertext data is completely decrypted. The single-byte plaintext data at the end of the packet body is discarded, and the original packet body length data is intercepted to obtain the decrypted packet body data.

7. The device communication method based on LoRa private protocol according to claim 1, characterized in that: The verification process is as follows: The packet header is verified. If the verification is passed, the packet body length is calculated by the packet length field in the packet header, the packet body ciphertext data and the packet tail verification data are read, the packet header, the packet body and the packet tail data are combined into a complete packet, and then it is determined whether to discard the packet or receive the packet and perform the next step according to the receiving conditions of broadcast, multicast and unicast. If the receiving conditions are met, the complete packet is verified. If the verification is passed, the packet body ciphertext data is decrypted using the random key field in the packet header. This is repeated to obtain the packet body plaintext data of each message packet and cache it.

8. The device communication method based on LoRa private protocol according to claim 7, characterized in that: The method for realizing 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 self device serial number is consistent with the responder device serial number in the packet header, and then the response is performed.

9. The device communication method based on LoRa private protocol according to claim 1, characterized in that: The response message is processed by packet, the packet header ACK bit 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 the self device serial number.

Images