CN108306711B - A LoRa-based data frame fast and continuous transmission method - Google Patents
A LoRa-based data frame fast and continuous transmission method Download PDFInfo
- Publication number
- CN108306711B CN108306711B CN201810000597.8A CN201810000597A CN108306711B CN 108306711 B CN108306711 B CN 108306711B CN 201810000597 A CN201810000597 A CN 201810000597A CN 108306711 B CN108306711 B CN 108306711B
- Authority
- CN
- China
- Prior art keywords
- data frame
- frame
- data
- confirmed
- data frames
- 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
- 230000005540 biological transmission Effects 0.000 title claims abstract description 49
- QVFWZNCVPCJQOP-UHFFFAOYSA-N chloralodol Chemical compound CC(O)(C)CC(C)OC(O)C(Cl)(Cl)Cl QVFWZNCVPCJQOP-UHFFFAOYSA-N 0.000 title claims abstract description 43
- 238000000034 method Methods 0.000 title claims abstract description 26
- 238000012790 confirmation Methods 0.000 claims abstract description 58
- 230000007246 mechanism Effects 0.000 claims description 20
- 230000008569 process Effects 0.000 claims description 4
- 238000005516 engineering process Methods 0.000 abstract description 23
- 238000004891 communication Methods 0.000 abstract description 14
- 230000003044 adaptive effect Effects 0.000 abstract description 4
- 108010003272 Hyaluronate lyase Proteins 0.000 description 8
- 230000000694 effects Effects 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000035945 sensitivity Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 2
- 238000011156 evaluation Methods 0.000 description 2
- 230000010076 replication Effects 0.000 description 2
- 230000007480 spreading Effects 0.000 description 2
- 230000007723 transport mechanism Effects 0.000 description 2
- 241000404883 Pisa Species 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005265 energy consumption Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- PCHJSUWPFVWCPO-UHFFFAOYSA-N gold Chemical compound [Au] PCHJSUWPFVWCPO-UHFFFAOYSA-N 0.000 description 1
- 239000010931 gold Substances 0.000 description 1
- 229910052737 gold Inorganic materials 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000010921 in-depth analysis Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000001228 spectrum Methods 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/324—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the data link layer [OSI layer 2], e.g. HDLC
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0006—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format
- H04L1/0007—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission format by modifying the frame length
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Quality & Reliability (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
本发明提出一种基于LoRa的数据帧快速连续传输方法，主要解决现有基于LoRa的数据帧连续传输方法用时偏多和控制开销偏大的问题。其实现方案是：通过对数据帧头部保留位的充分利用，使节点可以一次连续发送最多8个需确认数据帧和不限数量的无需确认数据帧，并且可以用一个自适应可变长确认帧对最多8个需确认数据帧进行回复，从而不仅能够加快数据帧的发送，减小数据帧延迟，而且还能够在总体上减少确认帧的数量，降低控制开销；可用于使用LoRa技术的无线通信系统或网络。
The present invention proposes a LoRa-based fast and continuous transmission method of data frames, which mainly solves the problems that the existing LoRa-based continuous transmission methods of data frames take too much time and control overhead. The implementation scheme is: by making full use of the reserved bits of the data frame header, the node can continuously send up to 8 data frames that need to be confirmed and an unlimited number of data frames that do not need to be confirmed, and can use an adaptive variable-length confirmation. The frame replies to a maximum of 8 data frames that need to be confirmed, which can not only speed up the transmission of data frames, reduce the delay of data frames, but also reduce the number of confirmation frames in general and reduce control overhead; it can be used for wireless wireless devices using LoRa technology. communication system or network.
Description
Technical Field
The invention belongs to the technical field of Low-Power Wide-Area Internet of Things (Low-Power Wide-Area Internet of Things) technology and ultra-Long-distance ultra-Low-Power data transmission (Long Range, LoRa for short), and particularly relates to a wireless Wide-Area Internet of Things occasion adopting a LoRaWAN access mode on a network MAC layer.
Background
With the development of the internet of things, more and more feasible applications are emerging in the industry. Short-range wireless connection technologies (e.g., Bluetooth and ZigBee) that are currently in widespread use are not well suited for many low-bandwidth long-range application scenarios. The cellular based M2M solution provides long distance communication at the cost of power consumption, but this solution is not environmentally friendly, and other 3GPP based solutions (e.g. GSM/GPRS,3G/4G/5G) all suffer from the same drawbacks. The technology of the internet of things provides a better solution for handling communication among a large number of devices and can better balance the relationship among reliability, distance, delay and energy consumption. As an efficient and reliable technical support of the internet of things technology, a low-power wide area technology becomes one of the most rapidly developed technologies in the field.
The low-power wide area technologies are classified into authorized (such as LTE-M, NB-IoT) and unauthorized (such as SigFox and LoRa), and the NB-IoT and the LoRa dominate in various low-power wide area technologies. The LoRa technology is supported by many researchers and manufacturers worldwide due to its long distance, low power consumption, ultra-long life and its mature theory.
LoRa is an emerging low power consumption long distance communication technology based on unlicensed bands below 1GHz (see document [1 ]: IoT connectivity map area with STM32MCUs and LoRa. Semtech Corporation, Presention & Transmission Material [ EB/OL ]. http:// www.st.com/content/ccc/resource/samples _ and _ mark/presentation/product _ presentation/group0/b5/72/c 6/c 8/e3/4a/8 c/IoTagmented _ STM 7-lrwan/files/IoTaugated _ STM32-lrwan.pdf/jcr: translation/payload _ Tagment _ m _ 5631-lrwan.3568: Japd _ m-26. 7). The physical layer of LoRa adopts an enhanced CSS-based spread spectrum modulation technology, which remarkably improves the sensitivity of data transmission and can normally communicate with-137 dBm sensitivity in 868MHz frequency band and-148 dBm sensitivity in 433MHz frequency band.
The LoRa base station employs a multi-channel modulation transmitter with an adaptive mechanism for receiving frames in multiple different channels. The frequency spreading modulation mechanism enables signals after frequency spreading to form an orthogonal relation through a specific spreading factor of each signal, and the anti-interference capability of the communication node is enhanced. In the LoRa modulation technique, throughput and communication distance depend on three important parameters of LoRa: BW (bandwidth), CR (coding rate), SF (spreading factor). BW represents the physical bandwidth of the rf modulation (e.g., 125KHz), and the larger the bandwidth, the higher the effective data transmission rate, and the shorter the transmission time. The relationship between bit rate and chirp rate and symbol rate is as follows:
as can be seen from the equation, the data rate RbAnd SF in a linear relationship. SF represents a spreading factor, the effective range of which is generally 6-12, and the effective range of the settable spreading factor is different for different chip supports. The smaller the spreading factor, the higher the data transmission rate, but the interference resistanceThe worse the communication distance will also become shorter.
In the LoRa communication system, a gateway transparently transmits frames between terminal equipment and a network server, the terminal equipment is not associated with a specific gateway, one data packet is sent to a core server through a plurality of gateways, the data packets are identical in content and are different in other performance indexes (such as signal strength and data integrity), and therefore the core server is required to have the capability of filtering the data packet and the security verification capability and can send ACKs response gateways; and after receiving the data packet, the core server selects the packet with the best overall performance and sends the packet to a specific gateway.
For different application scenarios and relevant characteristics of LoRa, solutions have been recently proposed, where the LoRa alliance elaborates the transmission mechanism of the LoRa technology, and the LoRa alliance divides the device operation mode into three classes, which respectively correspond to three MAC protocols at different levels: class a, Class B, Class C (see Document [2 ]: Sornin N, Luis M, Eirich T, et al, loran Specification [ EB/OL ]. https:// port, lora-identity, org/desktop modules/inventers _ Document/filedown, aspxcontent id ═ 1398, July 2016.), and the continuous transmission mechanism of frames is also designed as follows:
(1) mechanism for continuously transmitting downlink data
In the LoRa access technology, continuous transmission of downlink data frames ("downlink" refers to from a gateway to a terminal) employs the fpenting mechanism, and the mechanism is used only in the downlink. The basic idea of the Fpending mechanism is as follows: setting a 'Fending' bit at the head of the data frame to indicate whether a gateway needs to send a subsequent frame to a terminal; if the position 1 indicates that there is a subsequent frame to be transmitted, setting 0 indicates no. After receiving the frame at the Fending position 1, the terminal sends a data frame or a null frame (the null frame is sent without the data frame; the null frame is a frame with only a head part and a tail part) to the gateway so as to open a next receiving window to receive the downlink frame and prompt the gateway to send the data frame; the gateway needs to receive the data frame sent by the terminal before sending the frame each time.
(2) Continuous transmission of uplink data frames
In the LoRa access technology, continuous transmission of uplink data frames ("downlink" refers to transmission from a terminal to a gateway) is not specifically designed, as is single transmission. The specific transmission mode is as follows: if the terminal has a plurality of data frames to be sent to the gateway, the terminal firstly takes out a first data frame from the MAC layer sending buffer and sends the first data frame to the gateway, and then waits for the time of one or two receiving windows; then taking out the second data frame, sending the second data frame to the gateway, and waiting for the time of one or two receiving windows; similar operation is carried out until all data frames are sent.
Some studies have been recently conducted on the LoRa technique. Grandman et al have conducted an in-depth analysis of the three transmission modes Class a, Class B and Class C of the LoRa technology (see document [3 ]: grandman, zhuge, gold legislation, etc.. MAC layer protocol studies based on the LoRa standard [ J ]. television technology, 2016,40(10):77-81.), and have indicated that the terminal device of Class a consumes the lowest power in the application and allows two-way communication. The communication of the two equal acknowledgement messages is described here in relation to each other, but no improvement of the transport mechanism is considered, which still uses the relevant transport mechanism adopted by the LoRaWAN authority.
Sanfratello A proposed a TDMA-based LoRa Transmission scheme in the text of engineering release-based communication in LoRa networks for the Internet of Things that will be lost, replication and experimental evaluation (see document [4 ]: Sanfratello A. engineering release-based communication in LoRa networks for the Internet of Things that will be lost, replication and experimental evaluation [ D ]. Italy: Universal a di Pisa.2016). The time slots are divided into two Phase and Transmission Phase. In the Bind Phase stage, the terminal searches and authenticates the relay, and the Transmission Phase stage carries out information interaction. However, the TDMA-based transmission method has relatively strict requirements on the terminal equipment, and the terminal needs to open a Bind slot window for synchronization. This transmission is obviously not suitable in the scenario of relatively low traffic, because in the scenario of low traffic, the terminal is mostly in sleep mode to reduce the extra power consumption, but the transmission proposed herein increases in its power consumption.
In summary, LoRa is an emerging technology, which has received great attention from academia and manufacturers due to its advantages of ultra-long distance and low power consumption, and has been rapidly developed in recent years. However, as a result of intensive research, the following problems exist in the conventional data frame continuous transmission method of the LoRa related technology:
(1) whether the uplink data frame or the downlink data frame is continuously transmitted, after a data frame is sent by a data frame sending node, the data frame sending node needs to wait for a period of time to send the next data frame; moreover, when the downlink data frame is continuously transmitted, the gateway needs to receive the uplink frame sent by the terminal to send the next data frame; this approach not only results in increased data frame delay, but also increases control overhead.
(2) In the aspect of replying acknowledgement information after receiving a data frame, for an uplink or downlink data frame, the existing related method replies acknowledgement information for each frame individually, each reply operation can only confirm that one data frame is successfully received, and when a plurality of data frames can be successfully received by one reply, certain redundancy control overhead and data frame delay can be shown.
The above problems may cause large data frame delay and control overhead, which are not favorable for improving the data transmission performance of the MAC layer, and thus the problems need to be solved.
Disclosure of Invention
In order to solve the problems of the existing LoRa related technology in the data frame continuous transmission method, the invention provides a data frame rapid continuous transmission method based on LoRa; the method comprises two new mechanisms of 'continuously sending frames by batch numbers' and 'adaptively replying acknowledgement information', and in the transmission process of data frames, a node can continuously send at most 8 data frames needing to be acknowledged and unlimited number of data frames needing not to be acknowledged at one time, and reply at most 8 data frames needing to be acknowledged by using one adaptive variable-length acknowledgement frame, so that the sending of the data frames can be accelerated, the delay of the data frames can be reduced, the number of the acknowledgement frames can be reduced on the whole, and the control overhead can be reduced.
First, the basic idea and main operation of the new mechanism proposed by the present invention
The basic ideas and main operations of the two new mechanisms of 'batch number continuous frame' and 'adaptive acknowledgement message reply' proposed by the present invention are specifically described below.
1. Batch number continuous transmission frame
The new mechanism of 'continuously sending frames by batch numbers' is designed to enable a data frame sending node to send a plurality of frames at one time, so that the sending rate of the data frames is increased, and the data frame delay is reduced. The basic idea is as follows: continuously sending data frames to be sent to be confirmed in batches, numbering the data frames to be confirmed in each batch by using 3 reserved bits (shown in figure 1) of the frame head, and thus being beneficial to identifying the receiving condition of the data frames when replying confirmation information; for the data frames which do not need to be confirmed, the data frames are sequentially sent according to the positions of the packets packaged by the data frames in the MAC layer cache, are not numbered, and do not reply confirmation information for the data frames; each batch of data frames corresponds to one continuous transmission process, and at most 8 data frames to be confirmed and an unlimited number of data frames to be not confirmed can be transmitted in one continuous transmission process. The following three ways to stop the continuous transmission of the data frames of the current batch are available: sending all the packets to be sent; sending the 8 th data frame needing to be confirmed; the current data frame is a data frame that needs immediate acknowledgement. No matter the gateway node or the terminal node, the opposite node is not required to trigger in the process of continuously sending the data frame.
The flow of the new mechanism of 'batch number continuous frame transmission' is shown in the attached figure 2, and the main operations are as follows:
s1_ 1: each node is provided with a data frame buffer to be confirmed with the capacity of 8 maximum length data frames on an MAC layer, and the data frame buffer is used for storing data frames which are sent but have not received corresponding confirmation information and need to be confirmed; setting an integer parameter of a data frame number; meanwhile, a parameter of waiting for receiving the acknowledgement frame (indicated by wait) is set, which is used for indicating whether the acknowledgement frame corresponding to the sent data frame is waiting for receiving, the value of which is 0 indicates that the acknowledgement frame is not waiting, the value of which is 0 indicates that a new data frame cannot be sent in the waiting time, and the default initial value is 0; in addition, a parameter of "current destination MAC address" (denoted by "MAC _ a") is set to indicate the destination MAC address of the data frames currently occurring, and the default initial value is-1.
S1_ 2: one node judges: wait 1? If yes, executing the next step; if not, MAC _ a is set to-1, and then go to step S1_ 4.
S1_ 3: the current node performs data frame confirmation and retransmission operation, and after completion, the current node sets: wait is 0 and MAC _ a is-1. The main contents of the data frame acknowledgement and retransmission operations include: deleting the corresponding data frame in the data frame buffer to be confirmed according to the received data frame confirmation information; and setting a time threshold, and retransmitting the data frame in the data frame buffer to be confirmed if the data frame confirmation information is not received after the time threshold is exceeded.
S1_ 4: judging the current node: is there a pending packet in its MAC layer send buffer? If yes, executing the next step; if not, go to step S1_ 2.
S1_ 5: judging the current node: MAC _ a? If yes, setting MAC _ A as the destination MAC address of the first packet to be sent in the cache sent by the MAC layer, and then turning to step S1_ 8; if not, the next step is executed.
S1_ 6: judging the current node: MAC layer sends the destination MAC address of the first packet to be sent in the buffer? If yes, go to step S1_ 8; if not, the next step is executed.
S1_ 7: judging the current node: the number of frames to confirm caching > 0? If yes, setting wait to 1, and then turning to step S1_ 3; if not, setting wait 0 and MAC _ A to MAC address of the first packet to be sent in the buffer, and then executing the next step.
S1_ 8: the current node takes out the first packet to be sent from the MAC layer sending cache, adds a frame head and a frame tail, and assembles the first packet into a data frame.
S1_ 9: judging the current node: is the data frame to be transmitted require acknowledgement? If so, making the number of the data frame equal to the frame number of the data frame buffer to be confirmed, sequentially writing the number into a 3-bit reserved bit at the head of the data frame in a 3-bit binary number form, copying the data frame to the tail of the buffer to be confirmed, and then executing the next step; if not, the frame type is set to "no acknowledgement required" type in the type field of the frame header, and then go to step S1_ 12.
S1_ 10: judging the current node: is the data frame to be transmitted require immediate acknowledgement? If yes, setting the frame type field of the frame header as a type needing immediate confirmation, and then turning to step S1_ 15; if not, setting the frame type field of the frame head as the type needing to be confirmed, and then executing the next step.
S1_ 11: judging the current node: is the number of frames in the buffer to be confirmed greater than or equal to 8? If yes, go to step S1_ 15; if not, the next step is performed.
S1_ 12: judging the current node: is the first pending packet present in the transmit buffer (i.e., has a packet pending) and has its destination address? If yes, go to step S1_ 14; if not, the next step is executed.
S1_ 13: judging the current node: number of frames in buffer to be confirmed > 0? If yes, go to step S1_ 15; if not, setting: the Fpending position of the header of the data frame is 0, wait is 0, and MAC _ a is-1, the data frame is transmitted, and then step S1_4 is performed.
S1_ 14: setting a current node: the Fpending position of the header of the data frame is 0, wait is 0, and then the data frame is sent, and then go to step S1_ 8.
S1_ 15: setting a current node: the Fpending position of the header of the data frame is 0, wait is 1, and then the data frame is sent, and then go to step S1_ 3.
2. Adaptively replying to acknowledgement messages
The design purpose of the new mechanism of 'self-adaptive acknowledgement information reply' is to reply acknowledgement information for data frames to be acknowledged by using various forms flexibly and self-adaptively, so as to achieve the effect of reducing control overhead. The basic idea is as follows: replying a plurality of data frames to be confirmed by using a confirmation frame, and expressing whether each data frame is successfully received by using a one-dimensional binary vector with variable length; 1 new type of acknowledgement frame without frame body is used to indicate that the data frame to be acknowledged is received successfully; when the number of the data frames to be confirmed is not more than 3, the reserved bits of the frame head are borrowed to piggyback the confirmation information, and the data frame head can be used to piggyback the confirmation information. Through the application of the thought, the effects of reducing the number of the confirmation frames and reducing the control overhead on the whole can be achieved.
The flow of the new mechanism of "replying acknowledgement information adaptively" is shown in fig. 3, and the main operations are as follows:
s2_ 1: each node sets a 2-bit vector, namely a data frame receiving vector (represented by 'WV'), with the length of 8 bits on the MAC layer, and is used for recording the condition of successfully receiving the data frame to be confirmed, the position of each bit element in the vector corresponds to the number of the data frame to be confirmed, the value of the element is '1' which indicates that the data frame to be confirmed corresponding to the position of the element is successfully received, the value of '0' indicates that the data frame to be confirmed is not received, and the default value is '0'.
S2_ 2: one node judges: is a data frame sent to itself by the peer node received? If yes, taking out the content of the data frame body, uploading the content to the upper layer of the node, extracting the value of the MType field of the frame head, and then executing the next step; if not, the step is executed circularly.
S2_ 3: the current node judges according to the field value of 'MType': is the data frame in need of acknowledgement? If yes, go to step S2_ 7; if not, the next step is performed.
S2_ 4: judging the current node: is the value of the "fppending" bit of the header of the received data frame 0? If so, indicating that the sending node does not send frames any more subsequently, and executing the next step; if not, the step S2_2 is passed to indicate that the sending node will send frames later.
S2_ 5: judging the current node: WV? If yes, the step S2_2 is switched to if no confirmation information needing to be replied is available; if not, the confirmation information needing to be replied is shown, and the next step is executed.
S2_ 6: the current node generates a new type (the value of an MType field is 110, as shown in figure 5) of acknowledgement frame with the frame body length capable of self-adapting dynamic change between 0-5 bits; then, starting from 3 reserved bits of the head of the confirmation frame, filling elements of a data frame receiving vector to be confirmed in sequence, filling 1 bit of the confirmation frame with 1 element of the vector, and increasing the number of bits in the frame body if the head of the confirmation frame is not filled with the elements completely; if the data frame receiving vector needs to be confirmed to start from a certain bit and the values of the elements behind the bit are all 0, only the elements before the bit are loaded in the confirmation frame, the elements behind the bit are not loaded any more, and the number of bits of the frame body is not increased any more; then, the confirmation frame is sent to the opposite node (namely the sending node needing to confirm the data frame); if all the data frames to be confirmed are successfully received, another confirmation frame (the value of the MType field is 111, as shown in figure 5) with a new type and no frame body is generated, and then the frame is sent to the opposite node; if only the element value of No. 0 in the data frame receiving vector needing to be confirmed is 1 and the current node is about to send the data frame to the opposite node, the current node does not send the confirmation frame, but sends the ACK position 1 of the head of the data frame to be sent, and then sends the data frame to the opposite node; finally, set WV equal to 0 and go to step S2_ 2.
S2_ 7: the current node takes out values from 3 reserved bits of the head of the received data frame, combines the values in sequence to form the number of the data frame, and then sets the element corresponding to the number in the receiving vector of the data frame to be confirmed as 1.
S2_ 8: the current node inquires the MType field of the received data frame head, and judges: is the data frame required to be immediately acknowledged? If yes, go to step S2_ 6; if not, the next step is performed.
S2_ 9: judging the current node: is the value of the "fppending" bit of the header of the received data frame 0? If yes, the sending node is explained to not send frames any more subsequently, and then the step is switched to step S2_ 6; if not, the step S2_2 is passed to indicate that the sending node will send frames later.
Secondly, the main operation of the data frame rapid continuous transmission method based on LoRa provided by the invention
The data frame rapid continuous transmission method based on the LoRa provided by the invention is operated on the nodes of the wireless network adopting the LoRa technology, can be used by both a gateway and a terminal, and is suitable for transmitting downlink data frames from the gateway to the terminal and transmitting uplink data frames from the terminal to the gateway. When one node needs to send any type of data frame to another node, the LoRa-based data frame fast continuous transmission method provided by the invention can be used.
The invention provides a data frame rapid continuous transmission method based on LoRa, which mainly comprises the following operation steps:
s _ 1: each node is arranged at the MAC layer: (1) a data frame buffer to be confirmed with capacity of 8 maximum length data frames, which is used for storing data frames which are sent but have not received corresponding confirmation information and need to be confirmed; meanwhile, a "wait for reception of an acknowledgement frame" parameter (denoted by "wait") is set to indicate whether an acknowledgement frame corresponding to a sent data frame is waiting to be received, a value of 0 indicates that no waiting is performed, a value of 0 indicates that a new data frame cannot be transmitted during the waiting time, and a default value is 0. (2) A 2-bit vector with the length of 8 bits, namely a data frame receiving vector (represented by 'WV'), which is used for recording the condition of successfully receiving the data frame to be confirmed, wherein the position of each bit element in the vector corresponds to the number of the data frame to be confirmed, the value of the element is '1' to indicate that the data frame to be confirmed corresponding to the position of the element is successfully received, the value of '0' to indicate that the data frame to be confirmed is not received, and the default value of '0'. (3) A "current destination MAC address" parameter (denoted "MAC _ a") for indicating the destination MAC address of the current data frame, with a default initial value of-1
S _ 2: one node judges: wait is 0? If yes, turning to step S _ 4; if not, the next step is executed.
S _ 3: the current node performs data frame confirmation and retransmission related operations, and after completion, the current node sets: wait is 0 and MAC _ a is-1.
S _ 4: judging the current node: is there a pending packet in its MAC layer send buffer? If yes, executing the next step; if not, go to step S _ 8.
S _ 5: judging the current node: is the data frame batch currently being transmitted sent completed (the determination condition is: "MAC _ a ═ -1")? If yes, sending a first packet to be sent in the MAC layer sending cache in a new continuous sending data frame batch, and then turning to the step S _ 8; if not, the next step is performed.
S _ 6: judging the current node: can the first packet to be sent in the MAC layer transmission buffer be sent in the data frame batch currently being sent (the determination conditions are: "wait ═ 0" and "destination MAC address corresponding to the first packet ═ MAC _ a" and "number of frames in the data frame buffer to be confirmed < 8")? If so, executing the next step; if not, go to step S _ 8.
S _ 7: the current node puts the first packet to be sent in the MAC layer sending buffer in the data frame batch currently being sent, and then goes to step S _ 8.
S _ 8: judging the current node: is a data frame sent to itself by the peer node received? If so, taking out the content of the data frame body, uploading the content to the upper layer of the node, and then executing the next step; if not, go to step S _ 2.
S _ 9: the current node inquires the MType field of the received data frame head, and judges: is the data frame not acknowledged? If yes, executing the next step; if not, go to step S _ 13.
S _ 10: judging the current node: is the value of the "fppending" bit of the header of the received data frame 0? If so, indicating that the sending node does not send frames any more subsequently, and executing the next step; if not, the sending node will send frames later, and the step S _2 is switched to.
S _ 11: judging the current node: WV vector is 0? If yes, indicating that no confirmation information needing to be replied exists, turning to step S _ 2; if not, the confirmation information needing to be replied is shown, and the next step is executed.
S _ 12: the current node generates a new type of confirmation frame with the frame body length capable of self-adapting dynamic change between 0-5 bits; then, starting from 3 reserved bits of the head of the confirmation frame, filling elements of a data frame receiving vector to be confirmed in sequence, filling 1 bit of the confirmation frame with 1 element of the vector, and increasing the number of bits in the frame body if the head of the confirmation frame is not filled with the elements completely; if the data frame receiving vector needs to be confirmed to start from a certain bit and the values of the elements behind the bit are all 0, only the elements before the bit are loaded in the confirmation frame, the elements behind the bit are not loaded any more, and the number of bits of the frame body is not increased any more; then, the confirmation frame is sent to the opposite node (namely the sending node needing to confirm the data frame); if all the data frames to be confirmed are successfully received, generating another confirmation frame with a new type and without a frame body, and then sending the frame to the opposite node; if only the element value of No. 1 in the data frame receiving vector needing to be confirmed is 1 and the current node is about to send the data frame to the opposite node, the current node does not send the confirmation frame, but sends the ACK position 1 of the head of the data frame to be sent, and then sends the data frame to the opposite node; finally, go to step S _ 2.
S _ 13: the current node takes out values from 3 reserved bits of the head of the received data frame, combines the values in sequence to form the number of the data frame, and then sets the element corresponding to the number in the receiving vector of the data frame to be confirmed as 1.
S _ 14: the current node inquires the MType field of the received data frame head, and judges: is the data frame required to be immediately acknowledged? If yes, go to step S _ 12; if not, the next step is performed.
S _ 15: judging the current node: is the value of the "fppending" bit of the header of the received data frame 0? If yes, indicating that the sending node does not send frames any more subsequently, turning to step S _ 12; if not, the sending node will send frames later, and the step S _2 is switched to.
(III) advantageous effects of the invention
The beneficial effects of the invention are mainly as follows: in the data frame transmission process of the wireless network using the LoRa access technology, at most 8 data frames which need to be confirmed and unlimited number of data frames which need not to be confirmed can be continuously transmitted at one time, so that the transmission of the data frames can be accelerated, the data frame delay is reduced, the number of the confirmed frames can be reduced on the whole, and the control overhead is reduced.
The beneficial effects of the invention of reducing data frame delay and reducing control overhead generally mainly come from the following two aspects:
(1) after a new mechanism of 'continuously sending frames in batch number' is adopted, a data frame sending node can continuously send at most 8 data frames needing to be confirmed and unlimited number of data frames needing not to be confirmed at one time, the data frame sending node does not need to send frames to trigger in the continuous frame sending process (the frame sending operation of a gateway in the existing related method needs the frame sending of a terminal to trigger), and waiting time does not need to be arranged, so that the sending of the data frames can be accelerated, and the delay of the data frames is reduced.
(2) After adopting a new mechanism of 'self-adaptive acknowledgement information reply', the data frame receiving node can reply a plurality of data frames to be acknowledged by using one acknowledgement frame, 1 new type of acknowledgement frame without frame body is used for indicating that the data frames to be acknowledged are all successfully received, when the number of the data frames to be acknowledged is not more than 3, the reserved bit of the frame head is borrowed to piggyback the acknowledgement information, and the data frame head can be used to piggyback the acknowledgement information; therefore, the effects of reducing the number of the confirmation frames and reducing the control overhead on the whole can be achieved.
Drawings
Fig. 1 is a schematic diagram of reserved bits and key flag bits of a data frame header.
The new method provided by the invention uses 3 reserved bits of n1, n2 and n3 in the header of the data frame, and also uses the original 'Fpending' bit.
Fig. 2 is a flow chart of a new mechanism of 'batch number continuous frame'.
Fig. 3 is a flow chart of a new mechanism for adaptively replying acknowledgement messages.
Fig. 4 is a diagram illustrating a data frame reception vector to be confirmed.
FIG. 5 is a frame type description represented by the "MType" field value. Where "110" represents a variable length acknowledgement frame and "111" represents a data frame in which all data frames were successfully received.
Detailed Description
The data frame rapid continuous transmission method based on the LoRa is suitable for being used in a wireless communication system or a network adopting the LoRa technology; in a wireless communication system composed of an LoRa gateway node and an LoRa terminal node, both the gateway node and the terminal node can use the continuous transmission method provided by the present invention, and the specific implementation mode is as follows:
CS _ 1: the gateway node and the terminal node are respectively arranged on respective MAC layers: (1) a data frame buffer to be confirmed with capacity of 8 maximum length data frames, which is used for storing data frames which are sent but have not received corresponding confirmation information and need to be confirmed; meanwhile, a "wait for reception of an acknowledgement frame" parameter (denoted by "wait") is set to indicate whether an acknowledgement frame corresponding to a sent data frame is waiting to be received, a value of 0 indicates that no waiting is performed, a value of 0 indicates that a new data frame cannot be transmitted during the waiting time, and a default value is 0. (2) A 2-bit vector with the length of 8 bits, namely a data frame receiving vector (represented by 'WV'), which is used for recording the condition of successfully receiving the data frame to be confirmed, wherein the position of each bit element in the vector corresponds to the number of the data frame to be confirmed, the value of the element is '1' to indicate that the data frame to be confirmed corresponding to the position of the element is successfully received, the value of '0' to indicate that the data frame to be confirmed is not received, and the default value of '0'. (3) A "current destination MAC address" parameter (denoted "MAC _ a") for indicating the destination MAC address of the current data frame, with a default initial value of-1
CS _ 2: one node judges: wait is 0? If yes, turning to step CS _ 4; if not, the next step is executed.
CS _ 3: the current node performs data frame confirmation and retransmission related operations, and after completion, the current node sets: wait is 0 and MAC _ a is-1. The main contents of the data frame acknowledgement and retransmission operations include: deleting the corresponding data frame in the data frame buffer to be confirmed according to the received data frame confirmation information; and setting a time threshold of 0.5s, and retransmitting the data frame in the data frame buffer to be confirmed if the data frame confirmation information is not received beyond the threshold.
CS _ 4: judging the current node: is there a pending packet in its MAC layer send buffer? If yes, executing the next step; if not, go to step CS _ 8.
CS _ 5: judging the current node: is the data frame batch currently being transmitted sent completed (the determination condition is: "MAC _ a ═ -1")? If yes, sending a first packet to be sent in the MAC layer sending cache in a new continuous sending data frame batch, and then turning to the step CS _ 8; if not, the next step is performed.
CS _ 6: judging the current node: can the first packet to be sent in the MAC layer transmission buffer be sent in the data frame batch currently being sent (the determination conditions are: "wait ═ 0" and "destination MAC address corresponding to the first packet ═ MAC _ a" and "number of frames in the data frame buffer to be confirmed < 8")? If so, executing the next step; if not, go to step CS _ 8.
CS _ 7: the current node puts the first packet to be sent in the MAC layer sending buffer in the data frame batch currently being sent, and then goes to step CS _ 8.
CS _ 8: judging the current node: is a data frame sent to itself by the peer node received? If so, taking out the content of the data frame body, uploading the content to the upper layer of the node, and then executing the next step; if not, go to step CS _ 2.
CS _ 9: the current node inquires the MType field of the received data frame head, and judges: is the data frame not acknowledged? If yes, executing the next step; if not, go to step CS _ 13.
CS _ 10: judging the current node: is the value of the "fppending" bit of the header of the received data frame 0? If so, indicating that the sending node does not send frames any more subsequently, and executing the next step; if not, the sending node sends frames later, and the step is switched to the step CS _ 2.
CS _ 11: judging the current node: WV vector is 0? If yes, indicating that no confirmation information needing to be replied exists, turning to a step CS _ 2; if not, the confirmation information needing to be replied is shown, and the next step is executed.
CS _ 12: the current node generates a new type confirmation frame with the frame body length capable of self-adapting dynamic change between 0-5 bits, and the value of an MType field is set as 110; then, starting from 3 reserved bits of the head of the confirmation frame, filling elements of a data frame receiving vector to be confirmed in sequence, filling 1 bit of the confirmation frame with 1 element of the vector, and increasing the number of bits in the frame body if the head of the confirmation frame is not filled with the elements completely; if the data frame receiving vector needs to be confirmed to start from a certain bit and the values of the elements behind the bit are all 0, only the elements before the bit are loaded in the confirmation frame, the elements behind the bit are not loaded any more, and the number of bits of the frame body is not increased any more; then, the confirmation frame is sent to the opposite node (namely the sending node needing to confirm the data frame); if all the data frames to be confirmed are successfully received, another confirmation frame with a new type and without a frame body is generated, the value of an MType field is 111, and then the frame is sent to the opposite node; if only the element value of No. 1 in the data frame receiving vector needing to be confirmed is 1 and the current node is about to send the data frame to the opposite node, the current node does not send the confirmation frame, but sends the ACK position 1 of the head of the data frame to be sent, and then sends the data frame to the opposite node; finally, go to step CS _ 2.
CS _ 13: the current node takes out values from 3 reserved bits of the head of the received data frame, combines the values in sequence to form the number of the data frame, and then sets the element corresponding to the number in the receiving vector of the data frame to be confirmed as 1.
CS _ 14: the current node inquires the MType field of the received data frame head, and judges: is the data frame required to be immediately acknowledged? If yes, go to step CS _ 12; if not, the next step is performed.
CS _ 15: judging the current node: is the value of the "fppending" bit of the header of the received data frame 0? If yes, the sending node is explained to not send frames any more subsequently, and the step is switched to CS _ 12; if not, the sending node sends frames later, and the step is switched to the step CS _ 2.
Claims (1)
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810000597.8A CN108306711B (en) | 2018-01-02 | 2018-01-02 | A LoRa-based data frame fast and continuous transmission method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810000597.8A CN108306711B (en) | 2018-01-02 | 2018-01-02 | A LoRa-based data frame fast and continuous transmission method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108306711A CN108306711A (en) | 2018-07-20 |
| CN108306711B true CN108306711B (en) | 2021-05-14 |
Family
ID=62868119
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810000597.8A Active CN108306711B (en) | 2018-01-02 | 2018-01-02 | A LoRa-based data frame fast and continuous transmission method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN108306711B (en) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107612668A (en) * | 2017-09-06 | 2018-01-19 | 深圳天珑无线科技有限公司 | Communication means, device, terminal, server and storage medium based on LoRa |
| CN109067892A (en) * | 2018-08-22 | 2018-12-21 | 苏州凌犀物联网技术有限公司 | Big data transmission method, terminal and server in a kind of Lora communication system |
| CN109787924B (en) * | 2019-03-13 | 2021-06-15 | 重庆邮电大学 | A LoRa Channel Estimation Method Based on Compressed Sensing |
| CN110492978B (en) * | 2019-08-13 | 2020-04-24 | 翱捷科技(深圳)有限公司 | LoRaWAN system capable of achieving rapid confirmation and implementation method thereof |
| CN113497679A (en) * | 2021-06-05 | 2021-10-12 | 南京一步智能科技有限公司 | Efficient feedback confirmation method suitable for LoRa transmission |
| CN114301572B (en) * | 2021-11-15 | 2024-01-26 | 北京智芯微电子科技有限公司 | Transmitting terminal, receiving terminal, data frame transmission method thereof and storage medium |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1665195A (en) * | 2004-03-05 | 2005-09-07 | 株式会社东芝 | Communication device, communication method and communication system |
| CN104378184A (en) * | 2011-06-21 | 2015-02-25 | 华为技术有限公司 | Error recovery method, access point equipment, site equipment and site system |
| CN107204826A (en) * | 2017-03-30 | 2017-09-26 | 南京航空航天大学 | Towards the ADAPTIVE MIXED repeating method and device of deep space communication |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3002884B1 (en) * | 2014-09-30 | 2018-04-18 | Semtech Corporation | Wireless communication method |
-
2018
- 2018-01-02 CN CN201810000597.8A patent/CN108306711B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1665195A (en) * | 2004-03-05 | 2005-09-07 | 株式会社东芝 | Communication device, communication method and communication system |
| CN104378184A (en) * | 2011-06-21 | 2015-02-25 | 华为技术有限公司 | Error recovery method, access point equipment, site equipment and site system |
| CN107204826A (en) * | 2017-03-30 | 2017-09-26 | 南京航空航天大学 | Towards the ADAPTIVE MIXED repeating method and device of deep space communication |
Non-Patent Citations (1)
| Title |
|---|
| "低功耗广域LoRa技术分析与应用建议";刘琛等;《电信技术》;20160805;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN108306711A (en) | 2018-07-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108306711B (en) | A LoRa-based data frame fast and continuous transmission method | |
| US11219057B2 (en) | Method and apparatus for transmitting and receiving data in wireless communication system | |
| JP5876025B2 (en) | System and method for parallel communication with legacy WLAN receivers | |
| CN102859924B (en) | Sequential ACK for multi-user transmissions | |
| CN108401303A (en) | Terminal, the network equipment and communication means | |
| Wang et al. | Transmitting IPv6 packets over Bluetooth low energy based on BlueZ | |
| CN105409153A (en) | Uplink control information (UCI) transmission with bundling considerations | |
| KR20220089708A (en) | Implementation of multipath communication | |
| US20240073998A1 (en) | Method and apparatus for controlling packet duplication transmission in wireless communication system | |
| CN114651409B (en) | Method and apparatus for transmitting and receiving HARQ response in communication system | |
| KR102774668B1 (en) | Method and device for transmitting and receiving control information | |
| WO2021203850A1 (en) | Negotiation method for operation mode, initiating end, receiving end, chip system, and medium | |
| EP3425965B1 (en) | Wake-up-radio link adaptation | |
| JP6776428B2 (en) | Extended processing time for high bandwidth wireless communication | |
| CN103220069A (en) | Method and device for feeding back channel state information | |
| CN104995950A (en) | Data transmission method and apparatus | |
| CN110099448A (en) | The method and apparatus of communication | |
| CN111149340A (en) | User Equipment (UE) assisted local caching | |
| CN114402637B (en) | Communication method and communication device | |
| CN102404078B (en) | Method for realizing network encoding in LTE-A (Long Term Evolution-Advanced) | |
| EP4351054A1 (en) | Multi-link communication method and communication apparatus | |
| CN106304102B (en) | A Channel Multiplexing Method Based on Receiver Buffer of Wireless Network | |
| CN116547926A (en) | Network coding with dynamic redundancy overhead | |
| WO2019193664A1 (en) | Base station device, terminal device, communication method, and communication system | |
| CN109068394B (en) | Channel Access Method Based on Queue Length and Collision Risk |
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 |