CN115334585B - RTS/CTS-based communication method for LoRa network - Google Patents
RTS/CTS-based communication method for LoRa network Download PDFInfo
- Publication number
- CN115334585B CN115334585B CN202211240414.2A CN202211240414A CN115334585B CN 115334585 B CN115334585 B CN 115334585B CN 202211240414 A CN202211240414 A CN 202211240414A CN 115334585 B CN115334585 B CN 115334585B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- data packet
- data
- lora
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
- H04W28/0221—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices power availability or consumption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W52/00—Power management, e.g. TPC [Transmission Power Control], power saving or power classes
- H04W52/02—Power saving arrangements
- H04W52/0209—Power saving arrangements in terminal devices
- H04W52/0225—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal
- H04W52/0248—Power saving arrangements in terminal devices using monitoring of external events, e.g. the presence of a signal dependent on the time of the day, e.g. according to expected transmission activity
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D30/00—Reducing energy consumption in communication networks
- Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
The application provides a communication method of a LoRa network based on RTS/CTS, which comprises the following steps: the LoRa equipment nodes adopt respective corresponding communication mechanisms according to the working modes of the LoRa equipment nodes to complete communication between the LoRa equipment nodes and the gateway nodes; the working modes of the LoRa equipment comprise a Class A mode, a Class B mode and a Class C mode; the different communication mechanisms are based on RTS packets and CTS packets. According to the scheme, under the condition that a large-scale Internet of things is guaranteed, the LoRa equipment nodes can effectively access the channel, the communication conflict is solved, and the energy consumption is reduced.
Description
Technical Field
The invention belongs to the technical field of medium access control, and particularly relates to a communication method of an LoRa network based on RTS/CTS.
Background
The LoRa is a Low Power Wide Area Network (LPWAN) communication technology, and is widely applied to the fields of intelligent meter reading, smart agriculture and the like due to Low Power consumption, long distance and large capacity. The Media Access Control (MAC) layer protocol is an important component of the LoRa wireless network, but the number of terminal nodes accessing the network is large, so how to reduce communication conflicts and power consumption is an important issue for the MAC layer protocol research.
LoRaWAN is an open network protocol standard maintained by the LoRa alliance that defines communication protocols for lpran chip-based LPWAN technology and LoRaWAN defines Medium Access Control (MAC) at the data link layer. In the existing original LoRaWAN network protocol, in order to solve the problem of communication conflict, the MAC protocol standard adopted by LoRaWAN is Aloha medium access control protocol.
The Aloha media access control protocol is a simple media access control mechanism, and the working principle of the Aloha media access control protocol is to adopt a concept of sending in time, namely that when a user has data to send, equipment sends in time without monitoring a channel and sends randomly. If no data is received within a predetermined time, retransmission is performed. The retransmission policy is: waiting for a random period of time and then retransmitting; if the collision happens again, waiting for a random time until the retransmission is successful. Although the Aloha protocol is simple to implement and can meet the low power consumption characteristic required by the LPWAN, the random retransmission does not have a monitoring property, and packet collision and retransmission possibility are easily caused. Although a time slot S-Aloha scheme is proposed subsequently, the data transmission of the users is unified by using a clock, the time is divided into discrete time slices, and the users must wait for the next time slice to start transmitting the data each time, so that the randomness of data transmission of the users is avoided, and the possibility of data collision is reduced. But still does not solve the collision problem of transmissions in the same time slot.
LoRaWAN proposes three different classes, class A, class B and Class C, for different operating modes. The Class A adopts a low power consumption mode, only two receiving windows are opened after the sending window, and the receiving windows are not opened any more in other time, so that the energy consumption is greatly saved. Class B provides a fixed period of extra receive window for receiving extra information using beacon mechanism based on Class a, so this mode has extra power consumption problem. The Class C mode mechanism consumes the most energy, and a receiving window of the Class C mode mechanism is always in an open state, so that data can be received at any time, but the energy consumption is greatly increased correspondingly.
In summary, the existing LoRaWAN network uses the Aloha protocol random access channel to cause packet collision, continuous retransmission, and excessive energy consumption.
Disclosure of Invention
An object of the embodiments of the present specification is to provide a communication method for an LoRa network based on RTS/CTS.
In order to solve the above technical problem, the embodiments of the present application are implemented as follows:
the application provides a communication method of a LoRa network based on RTS/CTS, which comprises the following steps:
the LoRa equipment nodes adopt respective corresponding communication mechanisms according to the working modes of the LoRa equipment nodes to complete the communication between the LoRa equipment nodes and the gateway nodes;
the working modes of the LoRa equipment comprise a Class A mode, a Class B mode and a Class C mode;
the different communication mechanisms are based on RTS packets and CTS packets.
In one embodiment, the operation mode of the LoRa device is a Class a mode, and the corresponding communication mechanism is:
when the detection channel of the LoRa equipment node is in an idle state, the LoRa equipment node broadcasts and sends an RTS data packet to all nodes in the range of the gateway node, and the LoRa equipment node enters a competition period;
the competition nodes enter a device sleep state according to different competition strategies; the competition nodes comprise all LoRa equipment nodes which send RTS data packets;
and the gateway node confirms a winning node from the competition nodes according to the received RTS data packet, and informs all nodes within the range of the gateway node of the winning node through a CTS data packet.
In one embodiment, the competing nodes comprise a node in a receiving window period, a node in an idle period, a node which wakes up during data transmission and a node which is in a dormant state for a long time.
In one embodiment, the contention node is a node in a receiving window period, and the contention node enters a device sleep state according to different contention policies, including:
the competition node receives and analyzes the CTS data packet to obtain the ID of the equipment node being transmitted and the time length of the data needing to be transmitted;
and the competition node judges whether the node is the self node or not according to the node ID, if the node is the self node, the competition node sends data, and if the node is not the self node, the competition node waits for the first receiving window and the second receiving window to be closed and enters a dormant state.
In one embodiment, the contention node is a wakeup node during data transmission, and the contention policy after the wakeup node is awakened during the data transmission is the same as that of the contention node which is a node in an idle period;
the competition node is a node in an idle period, and the competition strategy of the competition node comprises the following steps:
if the competitive node is in the competitive period to send the RTS data packet, adopting a gateway node to select a winning node mode;
if the competition node is positioned after the gateway node sends the CTS data packet and sends the RTS data packet at the short interframe interval stage, the gateway node sends a feedback CTS data packet to the competition node to indicate the current channel transmission condition;
if the competition node sends an RTS data packet when channel detection is carried out, data collision occurs, the gateway node does not receive correct data, analysis is failed, and data retransmission is required, so that the sending node receives a retransmission request and then retransmits the data; and the nodes in the idle period do not receive correct data and enter a dormant state.
In one embodiment, when the LoRa device node detects that the channel is in a non-idle state, the LoRa device node enters a sleep state, after a preset time, the LoRa device node enters an awake state, and after the LoRa device node is woken up, the LoRa device node detects whether the channel is in an idle state again.
In one embodiment, the operation mode of the LoRa device is a Class B mode, and the corresponding communication mechanism is as follows:
under the condition of reserving a communication mechanism in a Class A mode, a receiving window opened in a fixed time period is additionally added;
the LoRa equipment prolongs a node competition period to be a time interval between two Ping slots, and in the competition period, the gateway node does not send a CTS data packet; when the receiving window period is reached, the gateway node sends CTS data packets to all nodes in the range of the gateway node; except the winning node, other nodes open a receiving window to obtain a CTS data packet and enter a dormant state.
In one embodiment, the operation mode of the LoRa device is a Class C mode, and the corresponding communication mechanism is as follows:
when the detection channel of the LoRa equipment node is in an idle state, the LoRa equipment node broadcasts and sends an RTS data packet to all nodes in the range of the gateway node, and all nodes in the range of the gateway node enter a dormant state after receiving the RTS data packet;
and the gateway node confirms a winning node according to the received RTS data packet, informs all nodes within the range of the gateway node of the winning node through a CTS data packet, and other nodes in the gateway node enter a dormant state.
In one embodiment, the data of the RTS data packet and the CTS data packet each include the ID of the device node being transmitted and the time duration for which the data needs to be transmitted.
In one embodiment, the RTS data packet or CTS data packet received by the node is in the form of a data string;
analyzing the RTS data packet and/or the CTS data packet comprises the following steps:
matching the data string with a related symbol sequence in a dictionary to obtain the ID of the node of the equipment being transmitted and the time length of the data to be transmitted; the dictionary represents the corresponding relation between the related symbol sequence and the ID of the node of the equipment which is transmitting and the time length of data which needs to be transmitted; the sequence of correlation symbols is a pseudo-random binary sequence.
As can be seen from the technical solutions provided in the embodiments of the present specification, the solution: the LoRa equipment nodes adopt respective corresponding communication mechanisms according to the working modes of the LoRa equipment nodes, communication between the LoRa equipment nodes and the gateway nodes is completed, the fact that the LoRa equipment nodes can effectively access channels under large-scale internet of things can be guaranteed, communication conflicts are solved, and energy consumption is reduced.
Drawings
In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly introduced below, it is obvious that the drawings in the following description are only some embodiments described in the present specification, and for those skilled in the art, other drawings can be obtained according to the drawings without any creative effort.
FIG. 1 is a schematic flow chart of the application of RTS/CTS to LoRa Class A mode provided by the present application;
FIG. 2 is a schematic diagram of four classes of nodes in LoRa Class A mode and the strategy of each Class provided by the present application;
fig. 3 is a schematic diagram of a strategy for a node in idle period in the LoRa Class a mode to send an RTS packet according to the present application;
FIG. 4 is a schematic flow chart of the RTS/CTS application to LoRa Class B mode provided herein;
fig. 5 is a schematic flow chart of the RTS/CTS application to the LoRa Class C mode provided in the present application.
Detailed Description
In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only a part of the embodiments of the present specification, and not all of the embodiments. All other embodiments obtained by a person skilled in the art based on the embodiments in the present specification without any inventive step should fall within the scope of protection of the present specification.
In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular system structures, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. It will be apparent, however, to one skilled in the art that the present application may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.
It will be apparent to those skilled in the art that various modifications and variations can be made in the specific embodiments described herein without departing from the scope or spirit of the application. Other embodiments will be apparent to the skilled person from the description of the present application. The specification and examples are exemplary only.
As used herein, the terms "comprising," "including," "having," "containing," and the like are open-ended terms that mean including, but not limited to.
In the present application, "parts" are parts by mass unless otherwise specified.
The problems that data packet collision, continuous retransmission, overlarge energy consumption and the like can be caused when an Aloha protocol random access channel is used in the conventional LoRaWAN network are solved. I.e. it faces the key problem of how to reasonably control the access control of the LoRa node to the channel during the limited reception window.
In the media access control, the RTS/CTS is a handshake mechanism for solving the hidden terminal problem, and by sending RTS and CTS data packets, a sleep control mechanism is performed on surrounding sending nodes, so that the occupation of a channel is ensured, and the energy consumption problem of other sleep nodes is ensured. Therefore, the classic RTS/CTS mechanism is applied to the LoRa wireless network medium access control protocol, but the conventional RTS/CTS cannot be directly applied to the LoRa network because the receive window mechanisms of different node modes are not consistent.
Therefore, different communication mechanisms are adopted for different LoRa node modes, and the communication method of the LoRa network based on the RTS/CTS is designed for the LoRa network channel access protocol mechanism, so that the problem of communication conflict between terminals can be avoided under a large-scale internet of things, and the energy consumption problem of other competing nodes can be effectively reduced.
The present invention will be described in further detail with reference to the drawings and examples.
A communication method of an RTS/CTS-based LoRa network comprises the following steps:
the LoRa equipment nodes adopt respective corresponding communication mechanisms according to the working modes of the LoRa equipment nodes to complete the communication between the LoRa equipment nodes and the gateway nodes;
the working modes of the LoRa equipment comprise a Class A mode, a Class B mode and a Class C mode;
the different communication mechanisms are based on RTS packets and CTS packets.
Specifically, the RTS packet and the CTS packet are used for performing sleep control on surrounding transmitting nodes (i.e., competing nodes in the following embodiments). In this application, each node (including the gateway node and all LoRa device nodes) determines which node is the node occupying the channel and the time length of occupying the channel based on the RTS packet and the CTS packet, and therefore, the data actually transmitted in the RTS packet and the CTS packet may include: the device node ID and the length of time that data needs to be transmitted are being transmitted. It can be understood that the data actually transmitted in the RTS packet and the CTS packet may be obtained by parsing by each node.
In one embodiment, the operation mode of the LoRa device is a Class a mode, and the corresponding communication mechanism is:
when the detection channel of the LoRa equipment node is in an idle state, the LoRa equipment node broadcasts and sends an RTS data packet, and the LoRa equipment node enters a competition period;
the competition nodes enter a device sleep state according to different competition strategies; the competition nodes comprise all LoRa equipment nodes which send RTS data packets;
and the gateway node confirms a winning node from the competition nodes according to the received RTS data packet, and informs all nodes within the range of the gateway node of the winning node through a CTS data packet.
It can be understood that, as shown in fig. 1, before sending data, the LoRa device node first detects whether the Channel is in an idle state by using a Channel detection mechanism (CAD) function of the LoRaWAN network.
If the detection channel is in the non-idle state, the LoRa equipment node enters the sleep state, after the preset time length, the LoRa equipment node enters the awakening state, and after the LoRa equipment node is awakened, whether the detection channel is in the idle state again is detected until the detection channel is in the idle state, and the LoRa equipment node broadcasts and sends an RTS data packet. It can be understood that the preset time duration can be set according to actual requirements.
If the detection channel is in an idle state, the LoRa equipment node broadcasts and sends an RTS data packet to all nodes in the range of the gateway node, and the LoRa equipment node enters a competition period;
the competition nodes enter a device sleep state according to different competition strategies; the competition nodes comprise all LoRa equipment nodes which send RTS data packets;
and the gateway node confirms a winning node from the competition nodes according to the received RTS data packet, and informs all nodes within the range of the gateway node of the winning node through a CTS data packet.
Specifically, all the LoRa device nodes entering the contention period are contention nodes. According to the characteristics that the LoRa Class a device can be dormant at any time and a receiving window can only be opened By sending data, the competing nodes can be divided into 4 classes, as shown in fig. 2, and include a Node RNode in a receiving window period, a Node Stand-By Node in an idle period, a Node SA-Node (wake-up Node) in a data sending period, and a Node LS-Node (Long-Sleep Node) in a dormant period. It will be appreciated that different types of competing nodes correspond to different competing policies. Specifically, the RNode refers to a node at the opening stage of two receiving windows in the Class a mode, and is capable of receiving data (i.e., receiving an RTS data packet and a CTS data packet); the Stand-By Node is a Node which is always in an idle period, and the Node has no receiving window, namely cannot receive data and can only send the data, namely can only acquire a channel By competing with other nodes for trial; the SA-Node refers to a Node which is awakened during data sending, and the Node has no receiving window, namely cannot receive data and can only send data, namely can only acquire a channel through competing with other nodes for trial; the LS-Node is a Node which is always in a dormant state in the current competition period, does not participate in competition, and cannot receive data.
And the competitive nodes enter a device sleep state according to different competitive strategies, wherein the nodes which successfully send the RTS data packet to the gateway node in the competitive nodes are winning nodes.
And the gateway node analyzes the received RTS data packet to obtain the ID of the transmitting equipment node and the Duration of the data to be transmitted. And the gateway node confirms that the corresponding LoRa equipment node is the winning node according to the data obtained by analysis, specifically, the LoRa equipment node corresponding to the ID of the equipment node being transmitted is the winning node. Each node finishes the competition period and enters a time of waiting for SIFS (Short interframe space).
Then the gateway node sends CTS data packets to all competitive nodes in the range of the gateway node, all the competitive nodes analyze the received CTS data packets, judge whether the competitive nodes are winning nodes or not according to the analyzed data, and send the data if the competitive nodes are the winning nodes; if the node is not the winning node, a NAV (Network Allocation Vector) phase is entered, namely a phase in which the sleep cannot transmit any data.
With continued reference to fig. 2, the contention policies employed by the different types of contending nodes differ. For the RNode, since it can receive RTS/CTS packets during the contention period, it can determine that the channel is occupied, and then can correctly enter the NAV phase. For LS-Node, because it is in long dormancy state in current competition period, it does not participate in competition, and can enter NAV stage correctly. And for the SA-Node, the SA-Node can automatically convert into a competition strategy of the Stand-By Node because the SA-Node enters a Stand-By Node stage after being awakened. Aiming at the competition strategy of the Stand-By node, different strategies are entered according to different occasions of sending RTS data packets By the node.
In an embodiment, the contention Node is a Node in a receive window period RNode (corresponding to the receive window period Node in fig. 2), and the contention Node enters the device dormant state according to different contention policies, including:
the competition node receives and analyzes the CTS data packet to obtain the ID of the equipment node which is transmitting and the Duration of data which needs to be transmitted;
and the competition node judges whether the node is the self node or not according to the node ID, if the node is the self node, the competition node sends data, and if the node is not the self node, the competition node waits for the first receiving window and the second receiving window to be closed and enters a dormant state.
In one embodiment, the contention Node is a wake-up Node SA-Node (corresponding to the wake-up Node in fig. 2) during data transmission, and the wake-up (or wake-up) of the wake-up Node SA-Node during data transmission is the same as the contention policy of the contention Node being a Node Stand-By Node in an idle period;
as shown in fig. 2 and 3, the competing Node is a Node Stand-By Node in an idle period, and the competing policy of the competing Node includes:
if the competitive node is in the competitive period to send the RTS packet, which corresponds to a in fig. 3, the winning node is determined in a manner that the gateway node selects the winning node, and then the winning node sends data.
If the competition node is positioned after the gateway node sends the CTS data packet and sends the RTS data packet at the stage of short interframe space SIFS, corresponding to B in the figure 3, the gateway node sends a feedback CTS data packet to the competition node to indicate the current channel transmission condition;
if the competitive node sends an RTS data packet when the channel detection is performed, and data collision occurs, corresponding to C in FIG. 3, the gateway node does not receive correct data, fails to analyze, and requests to retransmit the data, so that the sending node retransmits the data after receiving the retransmission request; and the node in the idle period does not receive correct data and enters a dormant state. Specifically, a source node (i.e., a sending node) is a winning node, the source node is in an SIFS stage, another node performs CAD detection to obtain a channel idle state at this time, and then sends an RTS data packet to a gateway node, where the RTS data packet may collide with data sent By the source node, so that the gateway node does not receive correct data, and requests the source node to resend the data, and the Stand-By node does not receive correct data, and enters a sleep state.
If the contention node sends an RTS packet when the contention node is in channel detection and no data collision occurs, corresponding to D in fig. 3, the gateway node receives correct data, and the node in the idle period receives correct data, and enters the NAV stage. Specifically, the source node (i.e., the sending node) is a winning node, and the source node is in the SIFS stage, and at this time, another node performs CAD detection to obtain a channel non-idle state, and then the other node enters the NAV stage.
Because the LoRaWAN Class B mode can send data at the node of the Class A mode through an additional Beacon mechanism, an additional mechanism for opening a fixed receiving window (Ping slot) is introduced again besides a mechanism for opening only two receiving windows. We therefore take advantage of the extra receive window feature of Class B mode to change the contention period to the time interval between receive windows as shown in fig. 4. And the nodes in the Class B mode uniformly open receiving windows in the Ping slot stage, can receive a CTS data packet of a competition result after passing through the competition stage, and send data according to different strategies or enter a dormant state.
In one embodiment, the operation mode of the LoRa device is a Class B mode, and the corresponding communication mechanism is as follows:
under the condition of reserving a communication mechanism in a Class A mode, additionally adding a receiving window Ping slot opened in a fixed time period;
the LoRa equipment prolongs a node competition period to be a time interval between two Ping slots, and in the competition period, the gateway node does not send a CTS data packet; when the Ping slot receiving window period is reached, the gateway node sends CTS data packets to all nodes in the range of the gateway node; except for the winning node, other nodes open a receiving window Ping slot, acquire a CTS data packet and enter a dormant state.
Specifically, with reference to fig. 4, the node whose operating mode is the Class B mode at least includes the following four strategies to send data or enter a sleep state:
other nodes in the receive window period: at this time, although the node opens the receiving window, the gateway node sends the CTS packet only in the Ping slot receiving window period, and thus the node does not receive data in the receiving window period. And waiting for the next Ping slot to acquire the CTS data packet fed back by the gateway node.
Other nodes not in the receive window period: and when the node needs to send information, the node enters a channel competition state. And sending a CAD confirmation channel idle state, then sending an RTS data packet, and entering a competition period. And waiting for the next ping slot to acquire the CTS data packet fed back by the gateway node.
Other nodes that are sleeping and do not wake up in the course of the node: the node is in a dormant state in the whole process, and the channel occupation is not influenced.
Other nodes that are sleeping but awake halfway: after waking up, the node enters a channel competition state, sends CAD to confirm the idle state of the channel, and then sends RTS to enter a competition period. And waiting for the next ping slot to acquire CTS information fed back by the gateway node.
The receiving window is in a full receiving state in the Class C mode, so that channel competition can be realized by adopting a traditional RTS/CTS mechanism. As shown in fig. 5, the node performs CAD and broadcasts an RTS packet, and since the other nodes are in a receiving window period in the whole process, the other nodes enter a sleep state after receiving the RTS packet. And broadcasting a CTS data packet by the gateway node according to the competition period condition to publish a winning node, and enabling other nodes in the gateway node area to enter a dormant state.
In one embodiment, the operation mode of the LoRa device is a Class C mode, and the corresponding communication mechanism is:
when the detection channel of the LoRa equipment node is in an idle state, the LoRa equipment node broadcasts and sends an RTS data packet to all nodes in the range of the gateway node, and all nodes in the range of the gateway node enter a dormant state after receiving the RTS data packet;
and the gateway node confirms a winning node according to the received RTS data packet, informs all nodes within the range of the gateway node of the winning node through a CTS data packet, and other nodes in the gateway node enter a dormant state.
And based on the actually transmitted data of the RTS data packet or the CTS data packet, a detection method based on a related symbol sequence is provided for analyzing the actually transmitted data of the RTS data packet or the CTS data packet.
In one embodiment, the RTS data packet or CTS data packet received by a node is in the form of a data string;
analyzing the RTS data packet and/or the CTS data packet, which comprises the following steps:
matching the data string with a related symbol sequence in a dictionary to obtain the ID of the node of the equipment which is being transmitted and the time length of the data which needs to be transmitted; the dictionary represents the corresponding relation between the related symbol sequence and the ID of the equipment node which is transmitting and the time length of the data which needs to be transmitted; the sequence of correlation symbols is a pseudo-random binary sequence.
Specifically, the related symbol sequence refers to a string of unique pseudo-random binary sequences, which are unique in the dictionary library and can be obtained through an autocorrelation detection manner.
And matching the data string with the related symbol sequence in the dictionary, wherein a similarity detection method can be adopted for matching, namely calculating the similarity between the data string and the related symbol sequence in the dictionary, when the similarity is greater than a preset threshold value, the data string can be considered to be matched with the corresponding related symbol sequence, and according to the corresponding relation between the related symbol sequence in the dictionary and the ID of the equipment node which is being transmitted and the time length of the data which needs to be transmitted, the ID of the equipment node which is being transmitted of the RTS data packet or the CTS data packet and the time length of the data which needs to be transmitted can be obtained through analysis.
The RTS data packet and/or the CTS data packet are analyzed by adopting a relevant detection method in the embodiment, so that the analysis time and the energy consumption of the data packets can be greatly reduced.
According to the RTS/CTS-based communication method for the LoRa network, the LoRa equipment nodes adopt respective corresponding communication mechanisms according to the working modes of the LoRa equipment nodes, communication between the LoRa equipment nodes and gateway nodes is completed, and under the condition that large-scale internet of things can be guaranteed, the LoRa equipment nodes can effectively access channels, solve communication conflicts and reduce energy consumption.
It should be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrases "comprising one of 8230; \8230;" 8230; "does not exclude the presence of additional like elements in a process, method, article, or apparatus that comprises the element.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
Claims (7)
1. A communication method for an LoRa network based on RTS/CTS, the method comprising:
the LoRa equipment nodes adopt respective corresponding communication mechanisms according to the working modes of the LoRa equipment nodes to complete communication between the LoRa equipment nodes and the gateway nodes;
the working modes of the LoRa equipment comprise a Class A mode, a Class B mode and a Class C mode;
different communication mechanisms are all based on RTS data packets and CTS data packets;
the working mode of the LoRa equipment is a Class A mode, and the corresponding communication mechanism is as follows:
when the detection channel of the LoRa equipment node is in an idle state, the LoRa equipment node broadcasts and sends the RTS data packet to all nodes in the range of the gateway node, and the LoRa equipment node enters a competition period;
the competition nodes enter a device sleep state according to different competition strategies; the competition nodes comprise all the LoRa equipment nodes which send the RTS data packets;
the gateway node confirms a winning node from the competing nodes according to the received RTS data packet, and informs all nodes in the range of the gateway node of the winning node through the CTS data packet;
the working mode of the LoRa equipment is a Class B mode, and the corresponding communication mechanism is as follows:
under the condition of reserving a communication mechanism in a Class A mode, a receiving window opened in a fixed time period is additionally added;
the LoRa equipment prolongs a node competition period to be a time interval between two Ping slots, and the gateway node does not send a CTS data packet in the competition period; when the receiving window period is reached, the gateway node sends CTS data packets to all nodes in the range of the gateway node; except for the winning node, other nodes open a receiving window to obtain a CTS data packet and enter a dormant state;
the working mode of the LoRa equipment is a Class C mode, and the corresponding communication mechanism is as follows:
when the detection channel of the LoRa equipment node is in an idle state, the LoRa equipment node broadcasts and sends the RTS data packet to all nodes in a gateway node range, and all nodes in the gateway node range enter a dormant state after receiving the RTS data packet;
and the gateway node confirms a winning node according to the received RTS data packet, informs all nodes within the range of the gateway node of the winning node through the CTS data packet, and other nodes in the gateway node enter a dormant state.
2. The method of claim 1, wherein the competing nodes comprise nodes in a receiving window period, nodes in an idle period, nodes wakened up during data transmission, and nodes in a sleeping state for a long time.
3. The method of claim 2, wherein the competing node is the node in the receiving window period, and the competing node enters a device sleeping state according to different competing policies, comprising:
the competition node receives and analyzes the CTS data packet to obtain the ID of the equipment node being transmitted and the time length of the data needing to be transmitted;
and the competitive node judges whether the node is the self node or not according to the node ID, if the node is the self node, the competitive node sends data, and if the node is not the self node, the competitive node waits for the first receiving window and the second receiving window to be closed and enters a dormant state.
4. The method of claim 2, wherein the competing node is a wakeup node during the data transmission period, and a contention policy of the contending node for the node in the idle period is the same after the wakeup node is woken up during the data transmission period;
the competition node is the node in the idle period, and the competition strategy of the competition node comprises:
if the competition node is in a competition period and sends the RTS data packet, adopting a gateway node to select a winning node mode;
if the competition node is positioned after the gateway node sends the CTS data packet and the RTS data packet is sent at a short inter-frame interval stage, the gateway node sends a feedback CTS data packet to the competition node to indicate the current channel transmission condition;
if the competition node sends the RTS data packet when the channel detection is carried out, data collision occurs, the gateway node does not receive correct data, analysis fails, and data retransmission is required, so that the sending node receives a retransmission request and then retransmits the data; and the node in the idle period does not receive correct data and enters a dormant state.
5. The method of claim 1, wherein when the LoRa device node detects that the channel is in a non-idle state, the LoRa device node enters a sleep state, and after a preset time, the LoRa device node enters an awake state, and after the LoRa device node wakes up, the LoRa device node detects again whether the channel is in an idle state.
6. The method of claim 1, wherein the data of the RTS data packet and the CTS data packet each comprise a transmitting device node ID and a time duration for which data needs to be transmitted.
7. The method according to claim 3 or 6, wherein the RTS data packet or CTS data packet received by a node is in the form of a data string;
analyzing the RTS data packet and/or the CTS data packet, including:
matching the data string with a related symbol sequence in a dictionary to obtain the ID of the equipment node which is transmitting and the time length of the data which needs to be transmitted; the dictionary represents the corresponding relation between the related symbol sequence and the ID of the equipment node which is transmitting and the time length of the data which needs to be transmitted; the correlation symbol sequence is a pseudo-random binary sequence.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211240414.2A CN115334585B (en) | 2022-10-11 | 2022-10-11 | RTS/CTS-based communication method for LoRa network |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211240414.2A CN115334585B (en) | 2022-10-11 | 2022-10-11 | RTS/CTS-based communication method for LoRa network |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115334585A CN115334585A (en) | 2022-11-11 |
| CN115334585B true CN115334585B (en) | 2023-01-03 |
Family
ID=83913900
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211240414.2A Active CN115334585B (en) | 2022-10-11 | 2022-10-11 | RTS/CTS-based communication method for LoRa network |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115334585B (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103517445A (en) * | 2013-10-24 | 2014-01-15 | 重庆邮电大学 | Vehicle-mounted ad-hoc network asynchronous multichannel MAC (media access control) access method based on time division multiplexing |
| CN114650612A (en) * | 2022-04-12 | 2022-06-21 | 炬彦物联科技(江苏)有限公司 | LoRa networking method based on carrier sensing technology |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3633392B1 (en) * | 2018-10-04 | 2024-07-31 | Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. | Concept for analysis of a radio communication system |
| CN110943861B (en) * | 2019-11-22 | 2021-09-10 | 南京航空航天大学 | Multilink concurrent transmission method suitable for underwater acoustic sensor network |
| US11510078B2 (en) * | 2020-11-19 | 2022-11-22 | Charter Communications Operating, Llc | Method for enhancing network quality of service (QoS) in a wireless communication system |
| CN113207149B (en) * | 2021-04-09 | 2022-09-27 | 东北农业大学 | Data transmission rate self-adaption method based on LoRaWAN network protocol |
| CN113573272B (en) * | 2021-07-26 | 2023-03-10 | 浙江大学 | Design method of RTS (request to send) competition access control protocol for multi-hop underwater acoustic wireless sensor |
-
2022
- 2022-10-11 CN CN202211240414.2A patent/CN115334585B/en active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103517445A (en) * | 2013-10-24 | 2014-01-15 | 重庆邮电大学 | Vehicle-mounted ad-hoc network asynchronous multichannel MAC (media access control) access method based on time division multiplexing |
| CN114650612A (en) * | 2022-04-12 | 2022-06-21 | 炬彦物联科技(江苏)有限公司 | LoRa networking method based on carrier sensing technology |
Non-Patent Citations (2)
| Title |
|---|
| Online Concurrent Transmissions at LoRa Gateway;Zhe Wang，Linghe Kong，Kangjie Xu，Liang He，Kaishun Wu，Guihai;《IEEE INFOCOM 2020 - IEEE Conference on Computer Communications》;20200804;全文 * |
| 基于LoRa技术的油田事故应急疏散诱导系统;张培红等;《消防科学与技术》;20190315(第03期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115334585A (en) | 2022-11-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Moss et al. | BoX-MACs: Exploiting physical and link layer boundaries in low-power networking | |
| KR101214790B1 (en) | Apparatus and method for collision avoidance of sensor network | |
| Yin et al. | Explicit channel coordination via cross-technology communication | |
| Kuhn et al. | Initializing newly deployed ad hoc and sensor networks | |
| Buettner et al. | X-MAC: a short preamble MAC protocol for duty-cycled wireless sensor networks | |
| Dunkels | The contikimac radio duty cycling protocol | |
| Sun et al. | RI-MAC: a receiver-initiated asynchronous duty cycle MAC protocol for dynamic traffic loads in wireless sensor networks | |
| Ziouva et al. | CSMA/CA performance under high traffic conditions: throughput and delay analysis | |
| Koubaa et al. | A comprehensive simulation study of slotted CSMA/CA for IEEE 802.15. 4 wireless sensor networks | |
| RU2609068C2 (en) | Method and device for accessing channel in wireless local area network (lan) | |
| US8576876B2 (en) | Method and system for determining and optimizing throughput of short range wireless network | |
| Boano et al. | Making sensornet MAC protocols robust against interference | |
| US20110140851A1 (en) | Wakeup-on-demand apparatus and mehtod, sensor device using the same, and wakeup-on-demand method of sensor device | |
| CN105979547B (en) | A kind of communication means of wide area network, node apparatus and system | |
| Ji et al. | Walking down the stairs: Efficient collision resolution for wireless sensor networks | |
| Shiraishi et al. | Content-based wake-up for top-k query in wireless sensor networks | |
| Moscibroda et al. | Analyzing the energy-latency trade-off during the deployment of sensor networks | |
| CN104202806A (en) | Asynchronous wireless sensor network MAC protocol started at sending terminal | |
| Vlachou et al. | Analyzing and boosting the performance of power-line communication networks | |
| Zhu et al. | Performance evaluation of IEEE 802.15. 4 CSMA/CA scheme adopting a modified LIB model | |
| Heindl et al. | The impact of backoff, EIFS, and beacons on the performance of IEEE 802.11 wireless LANs | |
| CN115334585B (en) | RTS/CTS-based communication method for LoRa network | |
| Kuhn et al. | Radio network clustering from scratch | |
| US20040186907A1 (en) | Technique for optimizing backoff for a shared resource | |
| Wang et al. | On analysis of the contention access period of IEEE 802.15. 4 MAC and its improvement |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |