Cross-layer collaborative optimization of LoRa-Mesh wireless network communication method

Abstract

The present invention discloses a cross-layer collaboratively optimized LoRa-Mesh wireless network communication method, the steps of which are as follows: the edge node transmits edge data back to the aggregation node via the LoRa-Mesh network; the edge node initiates an air device pairing request to the aggregation node; the application layer performs application layer private protocol encapsulation, and the hierarchical dynamic key negotiation protocol based on the PSK mechanism realizes air activation; the network layer uses the AODV routing protocol optimized for asymmetric channels to build a mesh routing path; the MAC layer performs data collision judgment and backoff control; the RDC layer performs channel monitoring based on the asynchronous communication low duty cycle monitoring mechanism; the physical layer calls the LoRa communication driver to send and receive data; the edge node performs data parsing according to the node data type. The present invention improves the stability, efficiency and security of communication in the LoRa-Mesh network, and meets the communication needs in the randomly distributed node scenario.

Description

Technical Field

[0001] The present invention relates to the field of wireless communication technologies, and in particular to a cross-layer collaboratively optimized LoRa-Mesh wireless network communication method. Background Art

[0002] Wireless Sensor Networks (WSN) is a distributed network composed of a large number of low-power, self-organizing sensor nodes. The typical wireless sensor network architecture consists of three parts: sensor nodes, aggregation nodes (or gateways) and remote servers.

[0003] A typical application scenario of wireless sensor networks is the monitoring of environmental status and business data of distributed photovoltaic equipment under smart grids. This monitoring scenario usually involves multiple photovoltaic power generation units, which may be distributed in a wide area, with nodes separated by hundreds of meters or even more than one kilometer, forming a randomly distributed network. This layout poses huge challenges to traditional centralized monitoring methods. First, long-distance transmission leads to signal attenuation and delay, especially in complex geographical environments; second, the random distribution characteristics mean that the installation location of the equipment is difficult to predict, which may affect the coverage and reliability of the network; finally, the complexity of the channel environment, especially the presence of obstacles such as buildings and trees, may lead to multipath propagation and signal interference, further reducing the communication quality.

[0004] By combining LoRa with Mesh network, building a LoRa-Mesh network can meet the monitoring needs of distributed photovoltaic equipment under similar smart grids, but there are still a series of challenges. First, there is currently a lack of a complete LoRa-Mesh protocol stack implementation technology. Although studies have explored the separate applications of LoRa and Mesh networks, the protocol stack that effectively combines the two is not yet mature. This lack of a complete implementation method limits the promotion and application of the technology. Secondly, to realize the construction of the LoRa-Mesh network, many problems need to be solved:

[0005] (1) In the distributed photovoltaic equipment monitoring scenario, due to the influence of factors such as terrain and obstacles, the signal strength between devices is inconsistent, and the channel often presents asymmetric characteristics. In this case, the traditional AODV protocol may have problems such as unreasonable path selection and data packet loss, which seriously affects the performance and reliability of the network;

[0006] (2) The data link layer requires a low-power control method to deal with frequent timeout retransmission and data collision problems. Nodes in wireless sensor networks are usually limited by battery power, so it is necessary to reduce power consumption while ensuring communication reliability.

[0007] (3) There is currently a lack of a highly secure air pairing protocol suitable for LoRa-Mesh networks, which makes the network vulnerable to attacks and data transmission faces the risk of being eavesdropped or tampered with. For distributed photovoltaic equipment monitoring scenarios, since the equipment is widely distributed and may be unattended, it is vulnerable to external attacks. In order to ensure the security of communication, it is necessary to design an air pairing protocol with strong encryption mechanism and identity authentication. Summary of the invention

[0008] In order to overcome the defects and shortcomings of the prior art, the present invention provides a cross-layer collaboratively optimized LoRa-Mesh wireless network communication method, which can effectively build a LoRa-Mesh wireless communication network between devices and perform safe and reliable device air pairing and activation. The communication method used is optimized through a variety of cross-layer collaborative optimization strategies, which greatly improves the stability, efficiency and security of the communication system and meets the communication needs in randomly distributed node scenarios.

[0009] In order to achieve the above object, the present invention adopts the following technical solutions:

[0010] The present invention provides a cross-layer collaboratively optimized LoRa-Mesh wireless network communication method, comprising the following steps:

[0011] The edge nodes collect edge data and transmit it back to the aggregation node through the LoRa-Mesh network;

[0012] The edge node initiates an air device pairing request to the aggregation node and mounts the device on the aggregation node;

[0013] After the edge node is successfully paired, it periodically transmits node data back;

[0014] The application layer performs application layer private protocol encapsulation according to the node data type, and uses the hierarchical dynamic key negotiation protocol based on the PSK mechanism to achieve automatic air activation of the node after power-on, and obtain the node address and key;

[0015] The network layer uses the AODV routing protocol optimized for asymmetric channels to build a mesh routing path, add network layer control information to node data, initiate a routing discovery request, and call the MAC layer data sending interface;

[0016] The MAC layer adds MAC layer control information to the node data, performs data collision judgment and backoff control, and calls the RDC layer data sending interface;

[0017] The RDC layer adds RDC layer control information to the node data, monitors the channel based on the asynchronous communication low duty cycle monitoring mechanism, and calls the physical layer data sending interface;

[0018] The physical layer calls the LoRa communication driver to send and receive data;

[0019] The edge node parses the data according to the node data type and calls the corresponding control information of the physical layer, RDC layer, MAC layer, network layer and application layer.

[0020] As a preferred technical solution, the application layer performs application layer private protocol encapsulation according to the node data type, specifically including:

[0021] The node data type includes a task type and a message type. The task type is used to define the task to which the current message belongs, including a network control message and a service data message. The message type is used to define the message type under the current task.

[0022] Design a reliable over-the-air pairing protocol for devices, set the edge nodes and aggregation nodes to interact with each other to obtain the key and address, and the information carried in the valid data;

[0023] The data type and data payload of the message are encapsulated, and the encapsulation format is expressed as: service_type+msg_type+len+message, where service_type represents the task type field, msg_type represents the message type field, len represents the length field, and message represents the valid data field.

[0024] As a preferred technical solution, a hierarchical dynamic key negotiation protocol based on the PSK mechanism is used to realize automatic air activation of nodes after power-on, and obtain node addresses and keys, specifically including:

[0025] Based on the PSK mechanism, a pre-master key MASTERKEY is set for all types of nodes;

[0026] All edge nodes are equipped with dual keys, namely the network key NETSKEY and the business key APPSKEY. Network control messages are encrypted using the network key NETSKEY, and business data messages are encrypted using the business key APPSKEY.

[0027] Each edge node has its own business key APPSKEY, and the aggregation node holds the business keys APPSKEY of all nodes in the subnet.

[0028] As a preferred technical solution, a reliable air pairing protocol for devices is constructed, which specifically includes:

[0029] Set the frame structure, perform encryption based on the symmetric block encryption Rijndael algorithm, and set the length of a single encrypted data block;

[0030] Set the nodes in the same sub-network to have the same initial network number, set the device address and available address space;

[0031] The aggregation node performs initialization operations, initializes its own node address, initializes the network key random value, obtains the network key by encrypting the network key random value based on the pre-master key MASTERKEY, and initializes the node information list and the node addresses in the list;

[0032] The edge node performs initialization operations, obtains the device's unique ID and calculates its own random initial address, and initializes the destination subnet aggregation node address;

[0033] The edge node encrypts the network access application string based on the pre-master key MASTERKEY and sends the network access application to the aggregation node address;

[0034] The aggregation node receives the message type field information, decrypts and verifies the network application string using the pre-master key MASTERKEY, obtains the address in the node information list with the address allocation status of 0, generates a random value Devnonce, encrypts the random value Devnonce based on the pre-master key MASTERKEY, obtains the business key APPSKEY of the node, stores it in the node information list, and changes the address allocation status;

[0035] Based on the pre-master key, the transmission field is encrypted and the network request response is transmitted to the edge node. The transmission field is represented as: Node_addr + Devnonce + NETNONCE, where Node_addr represents the address field of the allocated edge node and NETNONCE represents a random value used to generate the network key.

[0036] The edge node receives the message type field information, parses the transmission field, sets the Node_addr field to the local address of the edge node, encrypts the random value and NETNONCE field based on the pre-master key MASTERKEY to obtain the business key APPSKEY and the network key NETSKEY, encrypts the fixed verification string based on the network key and sends it, and sends the network access confirmation information to the aggregation node;

[0037] The aggregation node receives the message type field information, verifies the fixed verification string based on the network key NETSKEY, encrypts and sends the fixed network access success string after the verification is successful, and changes the address allocation status of the node in the node information list;

[0038] If it is determined that the address allocation status information of the receiving node of the aggregation node has timed out or the fixed verification string verification fails, the address allocation status in the node information list is reset, and the random value Devnonce and business key APPSKEY information are reset, and the application process ends;

[0039] The edge node receives the message type field information and the over-the-air activation process ends.

[0040] As a preferred technical solution, the network layer uses the AODV routing protocol optimized for asymmetric channels to build a mesh routing path, specifically including:

[0041] When there is a data transmission request and there is no valid route, a route establishment request is initiated, a request-response mechanism is used to discover the route and maintain the route between nodes. Each node maintains a routing table.

[0042] When the source node needs to send data, if it determines that there is no valid route, it generates a route request message RREQ and initiates data flooding to flood the data into the sub-network;

[0043] Each node that receives the route request message RREQ checks the signal-to-noise ratio value and signal strength value of the received route request message RREQ packet;

[0044] If the node itself is the destination node or has a valid path to the destination node in the routing table, update its routing table and generate a routing reply message RREP to return to the source node. If no valid path is detected, update the routing table, add a reverse path to the source of the routing request message RREQ, increase the forwarding count of the routing request message RREQ, and continue to flood the routing request message RREQ to other adjacent nodes.

[0045] If it is determined that the intermediate node or the target node has received the route request message RREQ, a route reply message RREP is sent to specify the next jump node in the return path, and is returned to the source node along the reverse path of the route request message RREQ. Each node that receives the route reply message RREP establishes a forward path to the route reply message RREP node. After receiving the route reply message RREP, the source node updates its routing table and records the route to the target node.

[0046] As a preferred technical solution, data collision judgment and backoff control are performed, specifically including:

[0047] Set the maximum backoff window index and perform channel monitoring at the RDC layer. If the channel is determined to be idle, send data directly. If the channel is determined to be busy, enter the collision avoidance phase. The backoff time is:

[0048] delay = random() %( (2MIN(collisions, CSMA_MAX_BE) -1)*backoff_period());

[0049] Among them, random() represents a random number, collisions represents the number of collisions that have occurred, CSMA_MAX_BE represents the maximum backoff window index, and backoff_period() represents the length of the backoff unit time slice;

[0050] Based on the set working time slice length, if a conflict occurs again after each backoff retransmission, the backoff window is expanded until it reaches (2 CSMA_MAX_BE -1)*backoff_period() window length.

[0051] As a preferred technical solution, channel monitoring is performed based on an asynchronous communication low duty cycle monitoring mechanism, specifically including:

[0052] The working time slice of the node is divided into the listening time slice and the sleeping time slice, and the listening time slice and the sleeping time slice are executed alternately. The number of LoRa preamble symbols is set, and the air propagation duration of the LoRa preamble under the corresponding RF parameters is used as the length of the working time slice, and the following conditions are met: t c >t r +t s ; where t c Indicates the length of the preamble time, t r Indicates the length of the monitoring time slice, t s Indicates the length of the sleep time slice;

[0053] The node performs the channel monitoring task after a fixed sleep time slice. If the preamble of the transmitted data packet is detected, the node receives the entire data packet and reports the data packet to the MAC layer. If not detected, the node returns to sleep until the sleep time slice ends and enters the next monitoring time slice.

[0054] As a preferred technical solution, channel monitoring is performed based on the asynchronous communication low duty cycle monitoring mechanism, and the physical layer data transmission interface is called. The data packet transmission step specifically includes:

[0055] The working time slice is divided into several time slots according to the length of the listening time slice, and a random number of time slots are added before data transmission to disrupt the transmission time of the node;

[0056] Before sending data each time, a configurable number of channel monitoring operations are performed to detect whether the current channel is idle;

[0057] A monitoring time slice is added at the end of the working time slice, and the data transmission of the hidden node is monitored in the channel monitoring at the end of the working time slice. Each channel monitoring executes a cycle of a monitoring time slice, a sleep time slice, and a monitoring time slice. Channel monitoring is performed based on the LoRa CAD mode to monitor whether there are other LoRa preamble codes in the monitoring channel;

[0058] If the channel is determined to be busy, the channel busy status is returned to the MAC layer for collision avoidance control.

[0059] As a preferred technical solution, the edge node performs data parsing according to the node data type and calls the control information corresponding to the physical layer, RDC layer, MAC layer, network layer and application layer, specifically including:

[0060] If the RDC layer detects that the current channel contains valid data during periodic channel monitoring, the physical layer data receiving interface is called;

[0061] The LoRa physical layer driver is optimized based on the fast ack method of the physical layer. After receiving a valid data packet, the physical layer immediately returns an ACK frame and calls the RDC layer data receiving interface.

[0062] The RDC layer parses the RDC layer control information in the data packet and calls the MAC layer data receiving interface;

[0063] The MAC layer parses the MAC layer control information in the data packet and calls the network layer data receiving interface;

[0064] The network layer parses the network layer control information in the data packet and calls the application layer data receiving interface;

[0065] The application layer performs application layer private protocol analysis based on the node data type;

[0066] After receiving the node data, the aggregation node performs data encapsulation and data transmission.

[0067] As a preferred technical solution, the fast ack method based on the physical layer fast short response optimizes the LoRa physical layer driver, specifically including:

[0068] After sending a message, the sending node enters the ack waiting state, sets the receiving window length, and waits for the ack frame message from the receiving node;

[0069] After receiving the valid data packet, the receiving node uses the RDC layer format to parse the point-to-point sender address and the point-to-point receiver address, and immediately returns a short response, which includes a short response identification header, a receiving address, and a sending address;

[0070] After receiving the short response message, the sending node ends the receiving state and returns to the sending success state;

[0071] If the sending node does not receive a short response within the set ack waiting window, it determines that the transmission has failed and reports it to the MAC layer for data retransmission.

[0072] Compared with the prior art, the present invention has the following advantages and beneficial effects:

[0073] (1) The present invention implements the LoRa-Mesh communication protocol stack and communication firmware design. Based on the standard five-layer architecture design, it can realize the construction of a safe, reliable, stable and efficient LoRa-Mesh private self-organizing communication network. It has portability and scalability in different business scenarios and has great practical application value for applications that require the deployment of large-scale randomly distributed nodes in wireless sensor networks.

[0074] (2) The AODV protocol optimization method of the present invention using a cross-layer collaborative strategy to deal with asymmetric channel scenarios can effectively improve the route construction success rate of the AODV routing protocol in actual application scenarios, reduce unreasonable route selection caused by asymmetric channel environments, reduce the probability of packet loss, and thus greatly improve the reliability of LoRa-Mesh communication network routing.

[0075] (3) The present invention controls the data link layer of LoRa based on the physical layer fast short response (fast ack), which can effectively solve the problem of sending and receiving control under the LoRa communication mode. It greatly reduces the node communication energy consumption through the asynchronous communication mechanism, and realizes the collision detection and backoff control of the device based on the CSMA / CA mechanism, which greatly reduces the probability of data collision, thereby improving the communication efficiency.

[0076] (4) The present invention adopts an optimized asynchronous communication low-duty cycle monitoring mechanism. By introducing a two-end channel monitoring method and a random time slot jitter mechanism, it can effectively solve the hidden node problem encountered by adjacent nodes when sending data packets and reduce the probability of data collision caused by nearly simultaneous transmission of nodes.

[0077] (5) The hierarchical dynamic key negotiation protocol based on the PSK mechanism and the reliable air pairing protocol of the device implemented on this basis have strong encryption mechanism and identity authentication mechanism. Through the hierarchical encryption and dynamic key negotiation mechanism, the air activation of legally authorized device nodes can be safely and reliably realized, and the access of illegal devices can be effectively prevented, so that the designed LoRa-Mesh communication system has a high degree of security. BRIEF DESCRIPTION OF THE DRAWINGS

[0078] Figure 1 This is a schematic diagram of the information flow of the LoRa-Mesh wireless network communication of the present invention;

[0079] Figure 2This is a task flow chart of the LoRa-Mesh wireless network communication of the present invention after the device is powered on;

[0080] Figure 3 This is a schematic diagram of the LoRa-Mesh wireless network communication protocol stack frame encapsulation process of the present invention;

[0081] Figure 4 It is a schematic diagram of the receiving and sending process of the physical layer LoRa driven by the LoRa-Mesh communication protocol stack of the present invention;

[0082] Figure 5 The figure is a timing diagram of the fast ack method based on the physical layer fast short response of the present invention;

[0083] Figure 6 A timing diagram of a low-power monitoring mechanism for asynchronous communication of the present invention;

[0084] FIG7 (a) is a schematic diagram of a dual-end channel monitoring method of the present invention;

[0085] FIG. 7( b ) is a schematic diagram of the random time slot jitter mechanism of the present invention

[0086] FIG8 (a) is a schematic diagram of the process of optimizing the AODV protocol No. 2 node (relay node) for asymmetric channels according to the present invention;

[0087] FIG8 (b) is a schematic diagram of the flow of the AODV protocol No. 1 (initiating node) and No. 3 (destination node) optimized for asymmetric channels according to the present invention;

[0088] Fig. 9 It is a schematic diagram of the two-level design of the private type message type of the application layer of the LoRa-Mesh communication protocol stack of the present invention;

[0089] Fig.10 It is a schematic diagram of the air pairing protocol of the application layer device of the LoRa-Mesh communication protocol stack of the present invention. DETAILED DESCRIPTION

[0090] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0091] like Figure 1 As shown, this embodiment provides a cross-layer collaboratively optimized LoRa-Mesh wireless network communication method, comprising the following steps:

[0092] S1: After the edge node and the aggregation node are powered on, they first perform an initialization operation. The edge node of this embodiment is connected to a sensor or other acquisition device, deployed at a location where business data needs to be collected, collects edge data and transmits it back to the aggregation node through the LoRa-Mesh network. The aggregation node is used to aggregate the edge nodes in the mounted subnet and upload it through Ethernet; Figure 2 As shown, initialization includes two operations: system parameter initialization and business process initialization. Among them, system parameter initialization includes: serial port communication initialization, initializing serial port driver parameters according to the transmission rate required by the business; timer and system time base initialization, initializing system clock according to hardware; protocol stack and SX1278 radio frequency initialization, determining communication related parameters according to the communication scenario and initializing them; PROCESS process management and private communication protocol initialization, initializing device process management and related parameters of air pairing protocol; process initialization operation is determined by the device node type. If it is a data aggregation node, initialize the data polling process, topology polling process and Ethernet transceiver process. If it is an edge collection node, initialize the air device pairing process and data transceiver process. The data polling process is used to collect sensor data collected by nodes in the mounted subnet, the topology polling process is used to collect routing paths constructed by nodes in the mounted subnet, and the Ethernet transceiver process initializes TCP / IP protocol stack parameters and platform-server transmission protocol parameters. The air device pairing process is used for air activation of edge collection nodes to obtain their own network address, session key and other node information; the data transceiver process is used for the management of LoRa transceivers;

[0093] S2: After completing the initialization operation, the edge node will initiate an air device pairing request to the aggregation node, obtain the edge node address and key, and mount the device on the aggregation node;

[0094] S3: After the edge node is paired successfully, the timer is started to periodically transmit node data. This embodiment constructs a cross-layer collaboratively optimized LoRa-Mesh wireless network communication protocol stack. The specific steps of controlling the next data transmission in the protocol stack include:

[0095] S31: Figure 3 As shown, the application layer initiates a data sending request, performs application layer private protocol encapsulation according to the data type (business data or control data), and then calls the network layer data sending interface;

[0096] In this embodiment, the application layer protocol is used to implement end-to-end air device pairing, business data collection and control tasks. The application layer divides messages into business data and control information, constructs a hierarchical dynamic key negotiation protocol based on the PSK mechanism, and a reliable air pairing protocol for devices implemented on top of it. After the device is successfully paired, it can send the business data collected by its own device to the data aggregation node. The reliable air pairing protocol for the application layer device provides the application layer with a node air activation function. The hierarchical dynamic key negotiation protocol based on the PSK mechanism realizes automatic air activation of the node after power-on, and can securely and reliably obtain the node address, key and other network information, including: (1) Based on the PSK mechanism, all types of nodes hold a pre-master key (hereinafter referred to as MASTERKEY) (16 bytes), which is written synchronously when the firmware is written and is not transmitted on the network. It has strong confidentiality. The edge node can securely verify its identity and exchange information with the gateway node to obtain the address required for communication and the dual key used for the session. (2) All edge nodes hold dual keys, namely the network key (hereinafter referred to as NETSKEY) and the business key (hereinafter referred to as APPSKEY). The network key NETSKEY is used by the application layer to control the network layer. All nodes in the subnet are kept unified. The network control information is encrypted with the network key NETSKEY: including topology collection / topology update / link quality collection protocol related information; the business key APPSKEY is used to encrypt the business data of the application layer. The related data is encrypted with the business key APPSKEY. Each edge node holds its own business key APPSKEY, and the aggregation node holds the business key APPSKEY of all nodes in the subnet, ensuring end-to-end encryption of data transmission. Only data production nodes and aggregation nodes can decrypt data. Other relay nodes cannot obtain actual business data, which enhances data privacy. (3) Build a private protocol at the application layer to support flexible expansion of multiple businesses. The data type is defined at two levels, such as Fig. 9As shown, it includes task type service_type and message type msg_type. The task type defines the task to which the current message belongs, which can be divided into two parts: network control message and business data message. The message type defines the message type under the current task. For example, the task type of the device network pairing task is NETWORK_CONFIG, which includes 4 message types: edge node network access application message NODE_ACCESS_REQUEST, aggregation node network access response message ROOT_ACCESS_RESPONSE, edge node network access confirmation message NODE_CHECK, aggregation node confirmation reply message ROOT_CHECK_RESPONSE. Through the flexibly defined service_type and msg_type headers of the application layer private protocol, the definition of a variety of business data exclusive protocols can be realized, and the customization of the business data frame format can be supported, which has strong scalability in business types.

[0097] like Fig.10As shown in FIG. 1 , the application layer device air pairing protocol specifically includes: (1) the application layer frame structure is defined as: service_type (1 byte) + msg_type (1 byte) + len (1 byte) + message (len bytes), the length len field records the length of the valid data message field carried by the current message, encryption uses the symmetric block encryption Rijndael algorithm, and the length of a single encrypted data block is set to 16 bytes, so the KEY length used is 16 bytes; (2) the nodes in the same subnet that need to be deployed have the same initial network number NET_ID (4 bytes, the value is (0x0000-0x000f) << 4), the device address is a 16-bit value, the available address space is 0x0000–0xFFFF, the first 4 bits of the address are used to identify the network number, 0x0000 is the reserved broadcast address, 0x0001 is the reserved aggregation node address, NODE_FIRST_AVALIABLE_ADDR It refers to the starting node address that the current aggregation node can allocate in the subnet, such as 0x0091, 0x0002-(NODE_FIRST_AVALIABLE_ADDR-1) (such as 0x0090) is the reserved initial random address space that the edge node can choose when initializing the node random address. All these addresses must be ORed with NET_ID to obtain the real subnet address or address space; (3) The aggregation node performs the initialization operation: initialize its own node address = NET_ID || 0x0001, fill 0 to 128 bits according to the device unique ID (96 bits) to initialize the network key random value NETNONCE (16 bytes), use MASTERKEY to encrypt NETNONCE to obtain the network key NETSKEY (16 bytes), the aggregation node initializes a node information list Mount_Node_Info_list with a size of MAX_Mount_NODE_NUM (maximum number of mounted nodes), a node information structure includes: node address (16 bits), node random value (16 bytes), node APPSKEY (16 bytes), address usage status ( 1 byte), the initialization will initialize the node addresses in the list, starting from NODE_FIRST_AVALIABLE_ADDR, the node random value and node APPSKEY are set to 0, the address usage status is set to the unassigned state NODE_NOT_ASSIGNED, and the remaining address usage states include: NODE_ASSIGNING (address allocation), NODE_ONLINE (address online), NODE_OFFLINE (address offline); (4) The edge node performs the initialization operation, the specific steps are: Get the device unique ID (96 bits), expressed as: DEVICE_ID=(ID 95 ,ID94 ,……,ID 0 ); Divide this ID into 6 16-bit parts, each part is represented by ID i (i=0, 1, 2, 3, 4, 5, 6); perform a cyclic XOR operation on each 16 bits to obtain an initial random value (16 bits), expressed as: DEVICE_ID=ID 0 ⊕ID 1 ⊕ID 2 ⊕ID 3 ⊕ID 4 ⊕ID 5; Calculate its own random initial address = NET_ID||(DEVICE_ID)% (NODE_FIRST_AVALIABLE_ADDR - 1), and initialize the destination subnet aggregation node address = NET_ID || 0x0001. (5) The edge node uses the MASTERKEY to encrypt the network access application string REQUEST_MESSAGE (16 bytes), service_type is NETWORK_CONFIG, msg_type is NODE_ACCESS_REQUEST, and sends the network access application to the aggregation node address; (6) The aggregation node receives the NODE_ACCESS_REQUEST message, decrypts and verifies the REQUEST_MESSAGE using the MASTERKEY, and retrieves and obtains an address in the Mount_Node_Info_list with an address allocation status of 0, generates a random value Devnonce, which is used to generate the network key NETSKEY, encrypts Devnonce with the MASTERKEY, obtains the APPSKEY of the node and stores it in the Mount_Node_Info_list, and changes the address allocation status to NODE_ASSIGNING; encrypts Node_addr (2 bytes) + Devnonce (16 bytes) with the MASTERKEY +NETNONCE (16 bytes) transmission, service_type is NETWORK_CONFIG, msg_type is ROOT_ACCESS_RESPONSE, and transmits the network access request response to the edge node. (7) Assuming that the sink node does not receive the NODE_ACCESS_REQUEST message or the REQUEST_MESSAGE verification fails, the sink node will not respond to the message. (8) After the edge node receives the ROOT_ACCESS_RESPONSE message timeout, it will directly reset the state, reinitialize and initiate a network access application. (9) When the edge node receives the ROOT_ACCESS_RESPONSE message, it will parse out Node_addr (2 bytes), Devnonce (16 bytes), and NETNONCE (16 bytes), use Node_addr to set the local address of the edge node, use MASTERKEY to encrypt Devnonce (16 bytes) and NETNONCE (16 bytes) respectively to obtain APPSKEY and NETSKEY, use NETSKEY to encrypt a fixed verification string CHECK_MESSAGE and send it, with service_type as NETWORK_CONFIG and msg_type as NODE_CHECK, and send the network access confirmation information to the aggregation node.(10) When the aggregation node receives the NODE_CHECK message, it will use NETSKEY to verify the CHECK_MESSAGE. If the verification is successful, it will use NETSKEY to encrypt and send a fixed string of successful network access, CHECK_RESPONSE_MESSAGE, with service_type as NETWORK_CONFIG and msg_type as ROOT_CHECK_RESPONSE. The address allocation status of the node in the Mount_Node_Info_list list will be changed to NODE_ONLINE. (11) When the aggregation node receives the NODE_CHECK message and times out, or the CHECK_MESSAGE message verification fails, the address allocation status in the Mount_Node_Info_list will be reset to NODE_NOT_ASSIGNED, and the Devnonce and APPSKEY information will be reset, ending the application process. (12) When the edge node receives the ROOT_CHECK_RESPONSE message, the over-the-air activation process ends.

[0098] S32: The network layer adds network layer control information to the data. The network layer is responsible for tasks such as route discovery, route maintenance, and route query. If there is no valid route stored locally, a route discovery request will be initiated to call the media access control layer (hereinafter referred to as the MAC layer) data sending interface;

[0099] In this embodiment, the network layer implements the network layer protocol based on the open source Rime protocol stack and Chameleon architecture, providing communication functions, routing construction, channel management and other functions for the upper application layer. The Rime protocol stack is an open source lightweight network protocol stack, which consists of multiple modules at different levels, each module providing different communication functions. Chameleon is a flexible protocol header conversion architecture designed for seamless integration of protocol stacks and message formats. It provides protocol header construction and parsing management for the Rime protocol stack, and also integrates several key components. Each component is responsible for different tasks and jointly supports the communication function of the Rime protocol stack. The network layer protocol is used for end-to-end routing discovery, routing maintenance and the implementation of various network functions. The network layer is based on the Rime protocol stack and Chameleon. The architecture and improved AODV protocol realize communication functions such as unicast, multicast, broadcast, flood, and mesh communication. This embodiment uses the AODV routing protocol optimized for asymmetric channels to build a mesh routing path to realize the core mesh communication function in the LoRa-Mesh network. The asymmetric channel scenario means that due to the strong anti-interference ability of LoRa, the effective communication distance of LoRa communication can reach the kilometer level. Therefore, the communication environment between devices is relatively unstable, the channel environment changes rapidly, and other wireless signals and noise sources in the communication environment are relatively complex. At the same time, LoRa modules of different models and brands also have different sensitivities and anti-interference capabilities. Therefore, when node A and node B communicate point-to-point, it is easy to Node B can receive the data packet sent by node A normally, but node A cannot receive the data packet sent by node B at the next moment. This may be due to packet loss caused by changes in the channel environment, or demodulation errors caused by noise and interference in the signal. This asymmetric channel will cause the protocol stack to frequently fail to build routes when building a mesh routing path. Therefore, an early routing reply mechanism and a cross-layer collaborative path selection strategy are introduced to optimize the AODV routing protocol in an asymmetric scenario, as shown in Figure 8 (a) and Figure 8 (b). The specific steps are as follows: (1) Initiate a route establishment request when there is a data transmission request and there is no valid route, and use the request-response mechanism to discover routes and maintain these routes between nodes. Each node maintains a routing table, which contains the following information: destination address, next hop address, sequence number, and number of hops, where the next hop address refers to the next hop node to reach the target node. (2) When the source node needs to send data, if there is no valid route, it will generate a route request (RREQ) message containing the source address, destination address and serial number of the source node, and initiate data flooding to the sub-network.(3) Each node that receives the RREQ will first check the signal-to-noise ratio (SNR) and signal strength (RSSI) of the received RREQ packet. If the SNR and RSSI values ​​are lower than the set threshold, the RREQ packet will be directly discarded without processing, indicating that the RREQ packet comes from an unstable channel, which may lead to an asymmetric channel. If the SNR and RSSI values ​​are higher than the set threshold, the routing table will be checked. (4) If it is the destination node or has a valid path to the destination node in the routing table, it will update its routing table, generate a routing response (hereinafter referred to as RREP) and return it to the source node; if it does not know, it will update its routing table, add the reverse path to the RREQ source, increase the forwarding count of the RREQ, and continue to flood the RREQ to other neighboring nodes. (5) Once the intermediate node or the target node receives the RREQ, it will send a RREP message, specifying the next jump node in the return path, and return to the source node along the reverse path of the RREQ. Each node that receives the RREP will establish a forward path to the RREP node. After receiving the RREP, the source node will update its routing table and record the route to the target node.

[0100] In this embodiment, the data link layer protocol is responsible for tasks such as collision detection, backoff control, and energy-saving control of nodes in the LoRa-Mesh network to ensure the reliability of point-to-point communication. The data link layer suitable for LoRa communication includes the RDC layer and the MAC layer. The RDC layer designs an asynchronous communication protocol based on the Contikimac protocol and the LoRa preamble mechanism, and the MAC layer implements channel detection and collision avoidance mechanism based on the CSMA / CA method.

[0101] S33: The MAC layer adds MAC layer control information to the data. The MAC layer is responsible for collision detection and backoff control tasks. If the data encounters data collision or the channel is busy, the backoff control will be performed at the MAC layer, and then the data sending interface of the radio power saving control layer (hereinafter referred to as the RDC layer) will be called;

[0102] In this embodiment, the MAC layer uses the CSMA / CA protocol to perform a collision avoidance control process, which specifically includes: first setting the maximum backoff window index CSMA_MAX_BE. Assuming that node A needs to send a data packet, the node first performs channel monitoring at the RDC layer. If the channel is idle, node A directly sends data; if the channel is busy, node A enters the collision avoidance phase, and the backoff time is: delay = random() %( (2 MIN(collisions, CSMA_MAX_BE)-1)*backoff_period()), where random() is a random number, collisions is the number of collisions that have occurred so far, and collisions will increase if the channel is busy or if node A does not receive an ACK frame after sending data. backoff_period() refers to the length of the backoff unit time slice, which uses the length of the working time slice set by the RDC layer. If a conflict is sent again after each backoff retransmission, node A will continue to expand the backoff window until it reaches (2 CSMA_MAX_BE -1)* backoff_period() window length. By dynamically increasing the size of the contention window each time a conflict occurs, the probability of multiple nodes sending data at the same time is effectively reduced. In this way, the system can better adapt to changes in network load, maintain fast response at low loads, and reduce collisions through an exponential backoff mechanism at high loads, thereby improving the overall efficiency of the network.

[0103] S34: The RDC layer adds RDC layer control information to the data. The RDC layer is responsible for tasks such as channel monitoring and energy-saving control. When sending data, the RDC layer first monitors the channel. If it detects that the channel is busy or the data packet has collided after being sent, it will prompt the MAC layer for data collision and notify the MAC layer to perform backoff processing. If it detects that the channel is idle, it will call the physical layer data sending interface.

[0104] In this embodiment, the RDC layer combines the improved Contikimac protocol and the LoRa mechanism (LoRa preamble and CAD mode) to construct an RDC layer control method suitable for LoRa communication, including a low-power monitoring mechanism for asynchronous communication, such as Figure 6 As shown in the figure, the node executes a low duty cycle monitoring mechanism (duty-cycle). Low duty cycle means that the working time slice of the node is divided into monitoring time slice and sleeping time slice. The monitoring time slice accounts for a lower proportion of the working time slice. The monitoring time slice and the sleeping time slice are executed alternately. In order to ensure the reliability of asynchronous communication, the air duration of the data packet to be sent must be greater than the sum of the sleeping time slice and the monitoring time slice to basically ensure that the sleeping node can be awakened, that is: t c >t r +t s (t c Refers to the length of the preamble time, t r is the length of the monitoring time slice, t s is the length of the sleep time slice), take t c =2*t r +t s, which is achieved by controlling the LoRa preamble. The LoRa preamble is a series of fixed-format symbol sequences sent before actual data transmission to help the receiver detect the start of the signal, synchronize time and frequency, and prepare to receive subsequent data packets. The number of LoRa preamble symbols is set, and the duration of the LoRa preamble's air propagation under the corresponding RF parameters is used as the length of the working time slice to ensure reliability. At the same time, since LoRa uses linear frequency modulation spread spectrum (CSS) technology for transmission, it has very strong robustness in low signal-to-noise ratio environments. Although the signal strength is very weak, it uses the characteristics of spread spectrum signals to enable the receiver to recover the original signal through a matching filter or other related algorithms. This capability makes the LoRa signal appear "invisible" in the noise, and it is difficult to effectively distinguish it through signal strength detection. Therefore, it is necessary to use LoRa's CAD mode. CAD mode is a method of detecting the LoRa preamble code on the wireless channel with the highest possible power efficiency. In CAD mode, the chip will quickly scan the frequency band to detect whether there is a LoRa preamble code. Specifically, the RDC layer control steps applicable to LoRa are as follows: (1) The node executes the initialization method to initialize the LoRa RF parameters, initialize the LoRa preamble code length, initialize the RDC layer working time slice, sleep time slice, monitoring time slice length and other parameters; the node wakes up briefly after a fixed sleep time slice (usually a few hundred milliseconds) to perform the channel monitoring task to check whether there is a LoRa preamble code on the channel. Communication activity; (2) If communication activity is detected on the channel (such as the preamble of a data packet), the node will remain awake, receive the entire data packet, and report the data packet to the MAC layer, reporting it layer by layer for data parsing; (3) If no communication activity is detected, the node will immediately return to sleep until the sleep time slice ends and enter the next listening time slice; (4) If the application layer initiates a data sending request at this time, it will call the RDC layer data sending interface layer by layer. If there is currently data being received, it will wait for the data to be received before re-initiating the data sending request. If there is currently no data being received, it will interrupt the current working time slice and enter the data sending state. Before each transmission, it will first monitor the channel, and finally realize the optimized asynchronous communication low duty cycle monitoring mechanism.

[0105] In this embodiment, the parameters related to the low duty cycle monitoring mechanism of the RDC sublayer are calculated. The specific steps are as follows: first, the air transmission time of the LoRa symbol is calculated. The calculation formula is: T sym =2 SF / BW, substitute the preset RF parameters: frequency band: 435 MHz, spreading factor: 7, bandwidth: 125 kHz, preamble length: 400 symbols; T sym =2 7 / 125000 =1.024 ms. Calculate the air transmission time of the preamble: The duration formula of the LoRa preamble is: T preamble =(N preamble +4.25)*T sym , where 4.25 is the number of extra symbols reserved in the LoRa protocol for synchronization and other control information. Substituting the values: T preamble =(400+4.25)*1.024ms =413.76 ms, so the length of a working time slice of the RDC sublayer is set to 400ms, the length of a CAD monitoring is 25ms-50ms, and the sleep time is 350ms-375ms. A set of practical application parameters is set to t c Set to 400ms, t r Set to 15ms-25ms, t s Set to 350ms, at this time the LoRa preamble is set to 400 symbols. The periodic node sleep method can greatly reduce the power consumption of the node and extend the life cycle of the node.

[0106] In this embodiment, the optimized asynchronous communication low duty cycle monitoring mechanism specifically includes: adjacent nodes will encounter a hidden node problem when sending data packets, that is, if a method of alternating a monitoring time slice and a sleep time slice in a normal receiving state is adopted, if the interval between the adjacent node initiating the sending time point is greater than a working time slice, the neighbor node can be monitored to be sending data to avoid collision, but if the interval between the adjacent node initiating the sending time point is less than a working time slice, the collision cannot be avoided. Taking the case of performing three channel monitoring before each transmission, at this time, node 1 and node 2 are hidden nodes for node 3, and node 3 cannot know that node 1 and node 2 are sending data at this time, so that normal data transmission leads to data packet collision, as shown in Figure 7 (a) and Figure 7 (b). The present invention solves this problem by introducing a two-end channel monitoring method and a random time slot jitter mechanism. The optimized data packet sending process is specifically as follows: (1) adding time slot jitter before sending, the specific steps are: dividing the above working time slice into a number of time slots according to the length of the monitoring time slice, and disrupting the transmission time of the node by adding a random number of time slots before data transmission, which can effectively avoid the adjacent sending nodes being in a completely synchronized state. (2) Before each data transmission, a configurable number of channel monitoring operations will be performed to detect whether the current channel is idle. Different from the channel monitoring in the normal receiving state, the channel monitoring at this time adopts a two-end channel monitoring method. The specific steps are: add a monitoring time slice at the end of the working time slice, so that the data transmission of the hidden node can be monitored in the channel monitoring at the end of the working time slice. Each channel monitoring will execute a monitoring time slice, a sleep time slice, and a monitoring time slice cycle, and execute a configurable number of channel monitoring cycles before transmission. The channel monitoring method is to use the above-mentioned LoRaCAD mode for channel monitoring to monitor whether there are other LoRa preamble codes in the channel. (3) If the channel is busy, the channel busy status will be returned to the MAC layer, and the MAC layer will be returned for collision avoidance control;

[0107] S35: The physical layer will call the data transmission interface driven by the LoRa communication to send data. The physical layer is responsible for the RF parameter setting, buffer management, ack mechanism and communication status control of the LoRa communication;

[0108] In this embodiment, the physical layer interface is responsible for sending and receiving LoRa data packets, as well as monitoring the LoRa channel. The physical layer drives the LoRa communication based on the state machine. After detecting that the channel is active, the received LoRa signal is modulated and demodulated to realize the conversion from analog signal to digital signal, and then the binary code stream is converted to ASCII code stream to obtain the data packet content that can be processed by the protocol stack.

[0109] In this embodiment, the physical layer uses a finite state machine model to design the LoRa driver to send and receive data, such as Figure 4 As shown in the figure, the drive system control based on the finite state machine switches the mode according to the event triggering conditions and the current state. The specific steps of the state machine switching are: the state machine starts from the standby mode, at which time the device is in a low power consumption state, waiting for external event triggering; when receiving an external event (such as receiving timer timeout or data packet of other devices), the state machine switches to the receiving mode; when the application needs to send a data packet, the state machine switches to the sending mode; in some cases, such as before the device needs to enter the receiving mode, the state machine switches to the CAD mode for channel activity detection. In the CAD mode, the driver uses the low signal-to-noise ratio detection capability unique to the LoRa modem to efficiently detect the LoRa preamble in the channel to determine whether the channel is occupied. If the channel is detected to be idle, the device can enter the sleep mode; if activity is detected, it enters the receiving mode to prepare to receive the data packet. When the sending or receiving operation is completed, the state machine will make corresponding decisions according to the application requirements. For example, you can switch back to the standby mode to save energy, or directly re-enter the receiving mode to prepare to handle the next data communication demand. When the device has no operation for a long time or needs to save energy, the state machine switches to the sleep mode.

[0110] S4: After receiving the valid data, the edge node parses it, calls different processing methods according to the service type and performs corresponding operations. The specific steps of the next data reception under the control of the protocol stack are as follows:

[0111] S41: The RDC layer detects that the current channel contains valid data during periodic channel monitoring, and thus calls the physical layer data receiving interface;

[0112] S42: After receiving a valid data packet, the physical layer will immediately return an ACK frame, and then call the RDC layer data receiving interface; the existing method will wait for the data packet to be parsed through the RDC layer, MAC layer, network layer, and application layer before performing an ack response. If the application layer business data parsing processing time is long, it may cause the sending node to time out waiting for the ack, and then the sending node will think that the transmission has failed and retransmit. This retransmission will waste channel resources. This embodiment optimizes the LoRa physical layer driver based on the fast ack method of the physical layer fast short response, and directly performs an ack response to the received data packet at the physical layer, thereby improving the efficiency of the ack response, and can avoid timeout retransmission caused by too long upper layer data processing time, thereby improving the network throughput.

[0113] like Figure 5As shown, the ack mechanism is optimized using a cross-layer collaborative strategy, and a fast short response is performed directly at the physical layer. The specific steps include: (1) After sending a message, the sending node immediately enters the ack waiting receiving state, and the receiving window length is 1s (the length can be set), waiting for the ack frame message from the receiving node; (2) After receiving a valid data packet, the receiving node uses the known RDC layer format to parse the point-to-point sender address and the point-to-point receiver address in advance, and then immediately returns a 6-byte short response ack. The short response consists of a 2-byte short response identification header (0XF0F0), a 2-byte receiving address, and a 2-byte sending address; (3) After receiving the short response message, the sending node immediately ends the receiving state and returns to the sending success state; (4) If the sending node does not receive the short response within the set ack waiting window, it is considered that the transmission has failed, and it will be reported to the RDC layer, and then reported to the MAC layer for data retransmission; in this embodiment, the physical layer fast The ack method can detect frame loss or damage in advance, and immediately confirm (or fail to confirm) the received frame through the physical layer. It can identify transmission errors hop by hop instead of waiting for higher layers (such as the network layer or application layer) to time out and retransmit. It can greatly improve network throughput and reduce the delay caused by upper-layer processing.

[0114] S43: The RDC layer parses the RDC layer control information in the data packet, such as the point-to-point sender address, the point-to-point receiver address, the sequence number, etc., and then calls the MAC layer data receiving interface;

[0115] S44: The MAC layer parses the MAC layer control information in the data packet, and then calls the network layer data receiving interface;

[0116] S45: The network layer parses the network layer control information in the data packet, such as the end-to-end sender address, the end-to-end receiver address, the number of hops, etc., performs tasks such as routing maintenance and routing updates, and then calls the application layer data receiving interface;

[0117] S46: The application layer performs application layer private protocol analysis according to the data type (business data or control data), and then executes the corresponding task;

[0118] S5: When the aggregation node receives the business data, it will encapsulate the data through the aggregation node-platform communication protocol and report it to the platform. After the platform receives the data, it will update it in the database;

[0119] S6: The platform can also send node polling commands to poll node data through the aggregation-platform communication protocol. After receiving the node polling command, the aggregation node will send business data requests to the mounted nodes in turn. After receiving the data request, the edge node immediately returns the business data, and the aggregation node repeats step S5.

[0120] The above embodiments are preferred implementation modes of the present invention, but the implementation modes of the present invention are not limited to the above embodiments. Any other changes, modifications, substitutions, combinations, and simplifications that do not deviate from the spirit and principles of the present invention should be equivalent replacement methods and are included in the protection scope of the present invention.

Claims

1. A cross-layer collaborative optimization LoRa-Mesh wireless network communication method, characterized in that: The steps include: The edge nodes collect edge data and transmit it back to the aggregation node through the LoRa-Mesh network; The edge node initiates an air device pairing request to the aggregation node and mounts the device on the aggregation node; After the edge node is successfully paired, it periodically transmits node data back; The application layer performs application layer private protocol encapsulation according to the node data type, and uses the hierarchical dynamic key negotiation protocol based on the PSK mechanism to achieve automatic air activation of the node after power-on, and obtain the node address and key; The network layer uses the AODV routing protocol optimized for asymmetric channels to build a mesh routing path, add network layer control information to node data, initiate a routing discovery request, and call the MAC layer data sending interface; The MAC layer adds MAC layer control information to the node data, performs data collision judgment and backoff control, and calls the RDC layer data sending interface; Perform data collision judgment and backoff control, including: Set the maximum backoff window index and perform channel monitoring at the RDC layer. If the channel is determined to be idle, send data directly. If the channel is determined to be busy, enter the collision avoidance phase. The backoff time is: delay = random() %( (2 MIN(collisions, CSMA_MAX_BE) -1)* backoff_period()); Among them, random() represents a random number, collisions represents the number of collisions that have occurred, CSMA_MAX_BE represents the maximum backoff window index, and backoff_period() represents the length of the backoff unit time slice; Based on the set working time slice length, if a conflict occurs again after each backoff retransmission, the backoff window is expanded until it reaches (2 CSMA_MAX_BE -1)* backoff_period() window length; The RDC layer adds RDC layer control information to the node data, monitors the channel based on the asynchronous communication low duty cycle monitoring mechanism, and calls the physical layer data sending interface; Channel monitoring is performed based on the asynchronous communication low duty cycle monitoring mechanism, including: The working time slice of the node is divided into the listening time slice and the sleeping time slice, and the listening time slice and the sleeping time slice are executed alternately. The number of LoRa preamble symbols is set, and the air propagation duration of the LoRa preamble under the corresponding RF parameters is used as the length of the working time slice, and the following conditions are met: t c >t r +t s ; Among them, t c Indicates the length of the preamble time, t r Indicates the length of the monitoring time slice, t s Indicates the length of the sleep time slice; The node performs the channel monitoring task after a fixed sleep time slice. If the preamble of the transmitted data packet is detected, the node receives the entire data packet and reports the data packet to the MAC layer. If not detected, the node returns to sleep until the sleep time slice ends and enters the next monitoring time slice. The physical layer calls the LoRa communication driver to send and receive data; The edge node parses the data according to the node data type and calls the corresponding control information of the physical layer, RDC layer, MAC layer, network layer and application layer.

2. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 1, characterized in that: The application layer performs application layer private protocol encapsulation according to the node data type, including: The node data type includes a task type and a message type. The task type is used to define the task to which the current message belongs, including a network control message and a service data message. The message type is used to define the message type under the current task. Design a reliable over-the-air pairing protocol for devices, set the edge nodes and aggregation nodes to interact with each other to obtain the key and address, and the information carried in the valid data; Encapsulate the data type and data payload of the message. The encapsulation format is as follows: service_type+msg_type+len+message; Among them, service_type represents the task type field, msg_type represents the message type field, len represents the length field, and message represents the valid data field.

3. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 1, characterized in that: The hierarchical dynamic key negotiation protocol based on the PSK mechanism realizes automatic air activation after the node is powered on, and obtains the node address and key, including: Based on the PSK mechanism, a pre-master key MASTERKEY is set for all types of nodes; All edge nodes are equipped with dual keys, namely the network key NETSKEY and the business key APPSKEY. Network control messages are encrypted using the network key NETSKEY, and business data messages are encrypted using the business key APPSKEY. Each edge node has its own business key APPSKEY, and the aggregation node holds the business keys APPSKEY of all nodes in the subnet.

4. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 3, characterized in that: Build a reliable over-the-air pairing protocol for devices, including: Set the frame structure, perform encryption based on the symmetric block encryption Rijndael algorithm, and set the length of a single encrypted data block; Set the nodes in the same sub-network to have the same initial network number, set the device address and available address space; The aggregation node performs initialization operations, initializes its own node address, initializes the network key random value, obtains the network key by encrypting the network key random value based on the pre-master key MASTERKEY, and initializes the node information list and the node addresses in the list; The edge node performs initialization operations, obtains the device's unique ID and calculates its own random initial address, and initializes the destination subnet aggregation node address; The edge node encrypts the network access application string based on the pre-master key MASTERKEY and sends the network access application to the aggregation node address; The aggregation node receives the message type field information, decrypts and verifies the network application string using the pre-master key MASTERKEY, obtains the address in the node information list with the address allocation status of 0, generates a random value Devnonce, encrypts the random value Devnonce based on the pre-master key MASTERKEY, obtains the business key APPSKEY of the node, stores it in the node information list, and changes the address allocation status; The transmission field is encrypted based on the pre-master key and the network input request response is transmitted to the edge node. The transmission field is represented as: Node_addr + Devnonce + NETNONCE; Among them, Node_addr represents the address field of the allocated edge node, and NETNONCE represents a random value used to generate a network key; The edge node receives the message type field information, parses the transmission field, sets the Node_addr field to the local address of the edge node, encrypts the random value and NETNONCE field based on the pre-master key MASTERKEY to obtain the business key APPSKEY and the network key NETSKEY, encrypts the fixed verification string based on the network key and sends it, and sends the network access confirmation information to the aggregation node; The aggregation node receives the message type field information, verifies the fixed verification string based on the network key NETSKEY, encrypts and sends the fixed network access success string after the verification is successful, and changes the address allocation status of the node in the node information list; If it is determined that the address allocation status information of the receiving node of the aggregation node has timed out or the fixed verification string verification fails, the address allocation status in the node information list is reset, and the random value Devnonce and business key APPSKEY information are reset, and the application process ends; The edge node receives the message type field information and the over-the-air activation process ends.

5. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 1, characterized in that: The network layer uses the AODV routing protocol optimized for asymmetric channels to build a mesh routing path, including: When there is a data transmission request and there is no valid route, a route establishment request is initiated, a request-response mechanism is used to discover the route and maintain the route between nodes. Each node maintains a routing table. When the source node needs to send data, if it determines that there is no valid route, it generates a route request message RREQ and initiates data flooding to flood the data into the sub-network; Each node that receives the route request message RREQ checks the signal-to-noise ratio value and signal strength value of the received route request message RREQ packet; If the node itself is the destination node or has a valid path to the destination node in the routing table, update its routing table and generate a routing reply message RREP to return to the source node. If no valid path is detected, update the routing table, add a reverse path to the source of the routing request message RREQ, increase the forwarding count of the routing request message RREQ, and continue to flood the routing request message RREQ to other adjacent nodes. If it is determined that the intermediate node or the target node has received the route request message RREQ, a route reply message RREP is sent to specify the next jump node in the return path, and is returned to the source node along the reverse path of the route request message RREQ. Each node that receives the route reply message RREP establishes a forward path to the route reply message RREP node. After receiving the route reply message RREP, the source node updates its routing table and records the route to the target node.

6. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 1, characterized in that: Based on the asynchronous communication low duty cycle monitoring mechanism, the channel is monitored and the physical layer data transmission interface is called. The data packet transmission steps specifically include: The working time slice is divided into several time slots according to the length of the listening time slice, and a random number of time slots are added before data transmission to disrupt the transmission time of the node; Before sending data each time, a configurable number of channel monitoring operations are performed to detect whether the current channel is idle; A monitoring time slice is added at the end of the working time slice, and the data transmission of the hidden node is monitored in the channel monitoring at the end of the working time slice. Each channel monitoring executes a cycle of a monitoring time slice, a sleep time slice, and a monitoring time slice. Channel monitoring is performed based on the LoRa CAD mode to monitor whether there are other LoRa preamble codes in the monitoring channel; If the channel is determined to be busy, the channel busy status is returned to the MAC layer for collision avoidance control.

7. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 1, characterized in that: The edge node performs data analysis based on the node data type and calls the control information corresponding to the physical layer, RDC layer, MAC layer, network layer and application layer, including: If the RDC layer detects that the current channel contains valid data during periodic channel monitoring, the physical layer data receiving interface is called; The LoRa physical layer driver is optimized based on the fast ack method of the physical layer. After receiving a valid data packet, the physical layer immediately returns an ACK frame and calls the RDC layer data receiving interface. The RDC layer parses the RDC layer control information in the data packet and calls the MAC layer data receiving interface; The MAC layer parses the MAC layer control information in the data packet and calls the network layer data receiving interface; The network layer parses the network layer control information in the data packet and calls the application layer data receiving interface; The application layer performs application layer private protocol analysis based on the node data type; After receiving the node data, the aggregation node performs data encapsulation and data transmission.

8. The cross-layer collaboratively optimized LoRa-Mesh wireless network communication method according to claim 1, characterized in that: The fast ack method based on the physical layer fast short response optimizes the LoRa physical layer driver, including: After sending a message, the sending node enters the ack waiting state, sets the receiving window length, and waits for the ack frame message from the receiving node; After receiving the valid data packet, the receiving node uses the RDC layer format to parse the point-to-point sender address and the point-to-point receiver address, and immediately returns a short response, which includes a short response identification header, a receiving address, and a sending address; After receiving the short response message, the sending node ends the receiving state and returns to the sending success state; If the sending node does not receive a short response within the set ack waiting window, it determines that the transmission has failed and reports it to the MAC layer for data retransmission.

Images