CN109151904B - Lora message reassembly and retransmission method, sending end and receiving end - Google Patents
Lora message reassembly and retransmission method, sending end and receiving end Download PDFInfo
- Publication number
- CN109151904B CN109151904B CN201810958892.4A CN201810958892A CN109151904B CN 109151904 B CN109151904 B CN 109151904B CN 201810958892 A CN201810958892 A CN 201810958892A CN 109151904 B CN109151904 B CN 109151904B
- Authority
- CN
- China
- Prior art keywords
- fragment
- reassembly
- receiving
- receiving end
- sending
- 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
- 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 63
- 238000000034 method Methods 0.000 title claims abstract description 42
- 239000012634 fragment Substances 0.000 claims abstract description 195
- 230000005540 biological transmission Effects 0.000 claims abstract description 45
- 238000012790 confirmation Methods 0.000 claims abstract description 15
- 238000012857 repacking Methods 0.000 claims description 10
- 230000004044 response Effects 0.000 claims description 6
- 238000005516 engineering process Methods 0.000 abstract description 5
- 230000008569 process Effects 0.000 description 10
- 238000004891 communication Methods 0.000 description 9
- 238000010586 diagram Methods 0.000 description 6
- 238000013467 fragmentation Methods 0.000 description 4
- 238000006062 fragmentation reaction Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 210000004899 c-terminal region Anatomy 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000002457 bidirectional effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000000779 smoke Substances 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
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/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
- H04W28/065—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information using assembly or disassembly of packets
-
- 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/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/1607—Details of the supervisory signal
- H04L1/1671—Details of the supervisory signal the supervisory signal being transmitted together with control information
- H04L1/1678—Details of the supervisory signal the supervisory signal being transmitted together with control information where the control information is for timing, e.g. time stamps
-
- 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
Abstract
A method for reloading and retransmitting Lora messages, a sending end and a receiving end are provided, the method comprises the following steps: the receiving end starts to reassemble the data after receiving the last fragment or reassembly request message; if the reassembly is successful, the receiving end continuously sends a first preset number of fragment reassembly completion confirmation messages to the sending end; if the reassembly is overtime, the receiving end continuously sends a second preset number of fragment reassembly failure messages to the sending end, and deletes the stored fragments at the same time; after receiving the fragment retransmission request, the sending end retransmits the fragment requested to be retransmitted by the receiving end again; and after the fragment retransmission is finished, continuously sending fragment reassembly request messages of a third preset number of times, wherein the receiving end continuously sends the fragment retransmission request messages of a fourth preset number of times. The method realizes message reassembly and retransmission when large data is transmitted by using the Lora technology, and improves the success rate of data transmission.
Description
Technical Field
The invention relates to the technical field of Lora, in particular to a method for reloading and retransmitting Lora messages, a sending end and a receiving end.
Background
LoRaWAN is a set of communication protocols and system architecture designed for LoRa long-distance communication networks. The Lora communication system generally comprises four parts, namely a terminal, a base station, a network server and an application server. A star network topology is adopted between the base station and the terminal, and single-hop transmission is used between the base station and the terminal due to the long-distance characteristic of LoRa. The terminal node can simultaneously send to a plurality of base stations, and the base stations forward LoRaWAN protocol data between the network server and the terminal, and respectively bear the LoRaWAN data on LoRa radio frequency transmission and TCP/IP.
Terminals in the Lora communication system are classified into three categories: class A, Class B, and Class C. And the Class A terminal reports data as required by adopting an ALOHA protocol. Two short downlink receiving windows are immediately followed after each uplink, so that bidirectional transmission is realized. This operation is most power efficient. The Class a terminal must wait for the terminal to report data before issuing data to the terminal, and the application scenarios of the Class a terminal are garbage can monitoring, smoke alarm, gas monitoring and the like. For Class B terminals, in addition to the random receive window of Class a, a receive window is opened at a specified time. In order for the terminal to open a reception window at a designated time, the terminal needs to receive a time-synchronized beacon from the gateway. The terminal of Class B can issue data to the terminal when the terminal fixes a receiving window, the issuing delay is improved, and the application scene is usually a valve control water gas electric meter and the like. The Class C terminal is basically always on the receive window and only briefly off during transmission. As the terminal of Class C is in a continuous receiving state, data can be transmitted to the terminal at any time. The application scene is usually street lamp control and the like. Class C terminals will consume more power than Class a and Class B.
Fig. 1 and 2 show timing diagrams of uplink and downlink of terminals of Class a and Class C, respectively. Class C and Class a are essentially the same except that during Class a sleep, it opens the receive window RX 2.
Fig. 3 shows timing diagrams of uplink and downlink of terminals of Class B. The time slot of Class B is somewhat complex, having a synchronization time slot beacon and a fixed period of receive window ping time slots. As in the example of fig. 3, the beacon period is 128 seconds and the ping period is 32 seconds.
LoRaWAN specifies both the type of data frame, either Confirmed or Unconconfirmed, i.e., required-to-acknowledge and non-required-to-acknowledge types. The manufacturer may select the appropriate type according to the application needs. There are two packet formats for LoRa: and displaying and hiding, wherein the header of the display data packet is short and mainly comprises information such as the number of bytes, the coding rate and whether CRC is used. As shown in fig. 4, the LoRa packet includes: preamble, Header (optional type of Header), Payload (data Payload).
The application data transmitted in the environment of the internet of things of the Lora workshop mainly comprises transmission of switching values and state quantities, and the application data can be transmitted in the Lora communication system in a short message mode.
However, there are also some needs for large data transmission, and these application data cannot be transmitted through the short message of Lora at one time due to their large size, so how to transmit large data in the Lora communication system and avoid generating large interference to the transmission of normal application message when transmitting large data is a difficult problem to be solved urgently. Meanwhile, how to trigger the sending end to retransmit the message when the data transmission fails and how to reassemble the message after the receiving end receives the message are also technical problems to be solved when the Lora technology is used for transmitting big data.
Disclosure of Invention
The invention provides a method for reassembling and retransmitting Lora messages, a sending end and a receiving end aiming at the defects of the prior art. The receiving end starts to try to reassemble the fragment message after receiving the last fragment or receiving the reassembling request message, if a large number of fragments are found not to be received, the receiving end sends a fragment reassembling failure message to the sending end, and if a small number of fragments are found not to be received, the receiving end sends a fragment re-sending request message to the sending end. The method realizes message reassembly and retransmission when large data is transmitted by using the Lora technology, and improves the success rate of data transmission.
According to one aspect of the present invention, the present invention provides a method for reloading and retransmitting a Lora message, which comprises the following steps:
the receiving end starts to reassemble the data after receiving the last fragment or reassembly request message; if the reassembly is successful, the receiving end continuously sends a first preset number of fragment reassembly completion confirmation messages to the sending end; if the reassembly is overtime, the receiving end continuously sends a second preset number of fragment reassembly failure messages to the sending end, and deletes the stored fragments;
after receiving the fragment retransmission request, the sending end retransmits the fragment requested to be retransmitted by the receiving end again; and after the fragment retransmission is finished, continuously sending fragment reassembly request messages of a third preset number of times, wherein the receiving end continuously sends the fragment retransmission request messages of a fourth preset number of times.
According to another aspect of the present invention, the first predetermined number, the second predetermined number, the third predetermined number, and the fourth predetermined number are all 3.
According to one aspect of the invention, the invention provides a method for reloading and retransmitting a Lora message, which is used for a sending end and comprises the following steps:
step 1: the sending end fragments the message in a fixed length and continuously sends the message;
step 2: after the fragment sending is finished, the sending end continuously sends a first preset number of reassembly request messages;
and step 3: starting an overtime timer to wait for the response of a receiving end and judging whether the timer is overtime or not;
and 4, step 4: if the timer is not overtime and receives the fragment retransmission request of the receiving end, the timer is suspended, the requested fragments are continuously sent out, and a second preset number of reassembly request messages are continuously sent out;
and 5: resetting and starting an overtime timer again to wait for the response of the receiving end; judging whether the timer is overtime;
step 6: if the timer is not overtime and receives the repacking success confirmation message, the timer is closed, the fragments are released, and the fragment transmission is quitted.
According to another aspect of the invention, the first predetermined number and the second predetermined number are both 3.
According to another aspect of the invention, the sender sends the second chunk of big data after the transmission and reassembly of the first chunk of big data is completed or after the timer times out.
According to another aspect of the present invention, the present invention further provides a method for reloading and retransmitting a Lora packet, which is used at a receiving end, and the method comprises the following steps:
step 1: the receiving end receives the fragments;
step 2: starting an overtime timer after receiving a first fragment, and resetting the overtime timer once receiving a fragment or a reassembling request message; judging whether the timer is overtime, if so, executing the step 3, otherwise, executing the step 4;
and step 3: continuously sending reloading failure messages of a first preset number of times, releasing the fragments, exiting reloading;
and 4, step 4: when the last fragment is received or a reassembly request message is received, suspending an overtime timer and starting to try reassembly; judging whether the fragments are lost and exceed a first threshold value;
and 5: if the fragment is lost but not more than the first threshold value, continuously sending fragment retransmission request messages of a second preset number of times to the sending end, and starting an overtime timer;
step 6: if receiving the retransmission fragment, resetting the overtime timer and storing the fragment;
and 7: if receiving the repacking request message, suspending the timer and trying to repack again;
and 8: and if the reassembly is successful, continuously sending a reassembly successful message of a third preset number of times to the sending end.
According to another aspect of the present invention, the first predetermined number of times, the second predetermined number of times, and the third predetermined number of times are all 3.
According to another aspect of the present invention, if the receiving end receives two large data fragments from the same transmitting end at the same time, the receiving end discards the previous large data fragment that has not been reassembled successfully.
According to another aspect of the present invention, the present invention also provides a transmitting end including a processor configured to perform a big data reassembly and retransmission method.
According to another aspect of the present invention, there is also provided a receiving end including a processor configured to perform a big data reassembly and retransmission method.
The invention provides a method for reassembling and retransmitting Lora messages, a sending end and a receiving end, which can realize message reassembling and retransmitting when large data is transmitted by utilizing the Lora technology, and improve the success rate of data transmission.
The features and advantages of the present invention will become apparent by reference to the following drawings and detailed description of specific embodiments of the invention.
Drawings
FIGS. 1 and 2 are timing diagrams of uplink and downlink of terminals of Class A and Class C in the prior art;
FIG. 3 is a timing diagram of uplink and downlink of a Class B terminal in the prior art;
FIG. 4 is a diagram illustrating a structure of a data frame in the prior art;
FIG. 5 is a block diagram illustrating a big data reassembly and retransmission process according to an embodiment of the present invention;
fig. 6 is a schematic flow chart of large data transmission performed by the transmitting end and the receiving end in the present invention.
Detailed Description
In order to make the technical solution of the present invention clearer and more clear, the following detailed description is made with reference to the accompanying drawings, and it should be understood that the specific embodiments described herein are only for explaining the present invention and are not intended to limit the present invention.
For convenience of description, in the present invention, in addition to indicating a server side and a Lora terminal, a sending side is used to indicate one of the server side and the Lora terminal, and a receiving side is used to indicate the other, that is, if the server is the sending side, the Lora terminal is the receiving side, and if the Lora terminal is the sending side, the server is the receiving side.
In the big data transmission method in the Lora communication system, the Lora terminal fragments the big data into short messages with fixed length in the uplink direction, the short messages which can be transmitted by the Lora communication system are continuously transmitted to the server, and the server reassembles the messages after the fragments are completely received. In the downlink direction, the server side fragments the big data into short messages with fixed length and capable of being transmitted by the Lora communication system, the short messages are transmitted to the Lora terminal through the SX1301 in a continuous mode, and the terminals completely receive sub-packets from the server side and then reassemble the messages.
Specifically, the big data transmission is realized in principle at the application layer of Lora, and a uniform interface is provided for upper-layer applications.
In the uplink direction of big data transmission, the terminal equipment is required to fragment the big data into short messages with fixed length and capable of being transmitted by the Lora platform, and the short messages are continuously transmitted to the server side through the Lora terminal module as soon as possible. Continuous uplink transmission can be performed in the Lora terminal node by closing the downlink receiving window. And after the sending is finished, the server side is required to perform receiving confirmation to inform the sending end of the received sub-packet sequence. If packet loss occurs in the transmission process, retransmission must be performed by the terminal device. If the retransmission fails, the big data transmission is considered to fail. After the fragments are completely received, the message repacking operation is completed by the server.
The big data is transmitted in the downlink direction, the server side is required to fragment the big data into short messages with fixed length and capable of being transmitted by the Lora platform, and the short messages are transmitted to the Lora terminal nodes continuously and as fast as possible through the SX 1301. Considering that the Class a device must receive downlink data when there is uplink, the method for transmitting large packets in the downlink direction is not suitable for the Class a device, and is more suitable for the Class C device. It is proposed to use RX2 window of Class C for continuous transmission. After the server finishes sending, the server requires the terminal device to perform receiving confirmation, and informs the sending end of the received packet sequence. If packet loss occurs in the transmission process, retransmission must be performed by the server. If the retransmission fails, the big data transmission is considered to fail. And after the terminal equipment completely receives the sub-packets from the server, the terminal equipment is reassembled.
In principle, the system only carries out fragment transmission and reassembly work of one big data at a time. The sending end must wait for the first big data fragment transmission and reassembly to complete or overtime before sending the second big data fragment, and if the receiving end receives two big data fragments from the same sending end at the same time, the receiving end should discard the last big data fragment that has not been reassembled successfully.
As shown in fig. 5, the present invention provides a method for reloading and retransmitting a Lora packet, a transmitting end, and a receiving end, in which the transmitting end continuously transmits a predetermined number of reloading request packets after transmitting a last fragment. The receiving end starts to try to reassemble the fragment message after receiving the last fragment or receiving the reassembling request message, if a large number of fragments are found not to be received, the receiving end sends a fragment reassembling failure message to the sending end, and if a small number of fragments are found not to be received, the receiving end sends a fragment re-sending request message to the sending end. The method realizes message reassembly and retransmission when large data is transmitted by using the Lora technology, and improves the success rate of data transmission.
The method specifically comprises the following steps:
the receiving end starts to reassemble the data after receiving the last fragment or reassembly request message; if the reassembly is successful, the receiving end continuously sends a first preset number of fragment reassembly completion confirmation messages to the sending end; if the reassembly is overtime, the receiving end continuously sends a second preset number of fragment reassembly failure messages to the sending end, and deletes the stored fragments at the same time;
after receiving the fragment retransmission request, the sending end retransmits the fragment requested to be retransmitted by the receiving end again; and after the fragment retransmission is finished, continuously sending fragment reassembly request messages of a third preset number of times, wherein the receiving end continuously sends the fragment retransmission request messages of a fourth preset number of times.
Preferably, the first predetermined number, the second predetermined number, the third predetermined number, and the fourth predetermined number are all 3.
1. Fixed length of slice
In order to simplify the fragmentation and reassembly process of the big data, the length of the message fragment needs to be fixed. This fixed length is limited by the lowest data rate of LoRa (SF12) and the maximum space-time specified by the specification (5 seconds).
It has been measured that in the case of data rate SF12, 56.8ms is required for each transmission of one byte. That is, under the condition of 5 seconds of maximum empty time, 88 bytes can be sent at most, 13 bytes of Lora headers are removed, and the maximum supported application payload is 75 bytes. To reserve a certain margin while guaranteeing a multiple of 2, 64 bytes are used as a fixed payload length of the slice (defined as fragment length 64).
2. Format of fragment message
And the terminal equipment fragments the big data into a plurality of pieces according to the fragment length through the Lora application layer. Each fragmented or non-fragmented packet should contain the following information: whether the fragment is a fragment or not, whether more fragments exist later, fragment offset id, message application type and message identification. The concrete constitution is as follows:
the low 5 bits bit0-bit4 of the Byte0 indicate the message application type and the purpose of the data message. Bit5 of Byte0 indicates whether the message is last fragmented. Bit6 of Byte0 indicates whether the message is a fragment. Byte1 indicates the message id, which indicates that it is the application data sent from the sender to a specific receiver, and is used to uniquely identify an uplink and downlink application data.
If the packet is a fragment, the next two bytes are the fragment offset id. If not fragmented, there are no two bytes. The slice offset indicates the sequence number of the slice throughout the big data.
The application type of the message may be defined according to the requirement, for example, the application type of the message may represent: 1: data; 2: confirming that the fragment reassembly is completed or fails (the fragment receiving end sends the fragment to the fragment sending end), and confirming that the fragment receiving is completed or fails to the sending end; 3: a fragment retransmission request (a fragment receiving end sends a fragment sending end) for requesting the sending end to retransmit a specific fragment; 4: and requesting the receiving end to reassemble the fragments (the fragment sending end sends the fragments to the fragment receiving end).
In the uplink direction, the terminal node needs to continuously transmit a string of display character information to the server, the total amount of data needing to be uploaded is small, and the KB-level length is considered; in the downlink direction, the server needs to upgrade the terminal firmware online, and needs to transmit the terminal firmware data fragments to the terminal device and reassemble the terminal firmware data fragments on the terminal device. The firmware size is large, and the requirement of MB level data volume transmission needs to be considered.
3. Uplink message fragmentation process
The terminal device segments the big data into a plurality of pieces according to the fragmentmentlength through the Lora application layer (the length of the big data on the uplink should consider the KB level), and then transmits the big data to the Lora terminal hardware for transmission.
Assuming that 150 bytes of data need uplink transmission, the terminal device needs to divide the data into 3 short messages first, and then send the short messages to the Lora terminal hardware for transmission, and the specific fragmentation is as follows:
4. sending of uplink fragment message Lora terminal hardware
After the terminal equipment fragments the big data into a plurality of fragments, the fragmented data are sequentially delivered to the Lora terminal hardware SX1276 for sending.
And the Lora terminal node receives the data delivered by the terminal equipment, and if the data is found to be the fragment. It is necessary to try to send out the fragments continuously and quickly. This is to make the following settings for the software of the Lora terminal node:
1. the IsRxWindowsEnabled mark is closed, so that the Lora terminal node does not open a receiving window in the fragment sending process, and the fragments are conveniently and continuously sent;
2. meanwhile, the timing time of the MacStateChecktimer is shortened, so that the message can be sent as soon as possible;
3. and if the data is the last reinstallation request message or is not the fragment, reopening the IsRxWindowsEnabled mark, enabling the receiving window, and simultaneously recovering the original timing length of the MacStateDeck timer.
5. Reassembly request message
After the sending end sends the last fragment, the sending end can also continuously send 3 reassembly request messages. And the receiving end starts to try to reassemble the fragments after receiving the last fragment or the reassembling request message.
In the method, the method of continuously retransmitting 3 reassembling request messages is used, instead of continuously retransmitting the last fragment for 3 times, so that the reassembling of the receiving end is started, because the last message may be longer and longer in time consumption, and the reassembling request message can be as short as possible. Retransmitting the last packet 3 times may take a long time.
The repacking request message format is as follows:
the meanings of the Byte0 and the Byte1 are the same as the meanings in the fragmentation message format
Byte 2-3: representing the total number of fragments that need to be transmitted for this large data transmission.
Byte 4: the second round of reassembly request is used for identifying that the second round of reassembly request is the first round of reassembly request, and the receiving end is used for distinguishing the repeated reassembly request messages and performing deduplication operation.
6. Repacking of fragmented messages
The reassembling of the upper layer fragment is responsible for by a network server NS, and the NS starts to reassemble data after receiving the last fragment or reassembling request message.
And if the reassembly is successful, the NS sends a fragment reassembly completion confirmation message to the terminal equipment. In order to ensure that the sender can receive the reassembly complete acknowledgement message, the message must be sent 3 times in succession.
If the reassembly is overtime, the NS sends a fragment reassembly failure message to the terminal equipment, and deletes the stored fragments at the same time. To ensure that the sender can receive the reassembly failure message, the message must be sent 3 times in succession.
The confirmation message format is as follows:
and after receiving the fragment reassembly confirmation (success or failure) message, the fragment sending end deletes the fragment message in the cache and finishes the fragment transmission.
Similarly, in the downlink direction, the process of reloading the short message by the Lora terminal is similar to the process of reloading the received short message by the server described above, and is not described herein again.
7. Retransmission request of fragment message
The network server NS starts trying to reassemble the fragments after receiving the last fragment. And if the large number of fragments are not received, the NS sends a fragment reassembly failure message to the terminal equipment. If a small number of fragments are found not received, a fragment retransmission request message can be sent to the terminal equipment. In order to ensure that the transmitting end can receive the fragment retransmission request message, the fragment retransmission request message needs to be continuously transmitted 3 times. The format is as follows:
wherein, Byte2 indicates the request is the retransmission, which is used for de-duplication. And after receiving the fragment retransmission request, the terminal equipment retransmits the fragment requested to be retransmitted again. And after the fragment retransmission is finished, the fragment reassembly request message needs to be retransmitted for 3 times continuously. The sending of these messages must be continuous, and the process is similar to the retransmission process described in the Lora terminal sending the uplink slice message.
Similarly, in the downlink direction, the process of requesting the server to retransmit the short message by the Lora terminal is similar to the process of requesting the Lora terminal to retransmit the short message by the server described above, and is not described herein again.
8. Timeout processing mechanism for fragment reloading exception
After the terminal equipment sends the last reassembly request message, a timeout mechanism is started to wait for the fragment reassembly confirmation message of the NS. And if the fragment reassembly confirmation message is received within the overtime time, the fragment transmission is finished.
If a retransmission request of the NS uplink fragment message is received within the timeout period, the timeout timer is reset, the retransmission request message is sent again, the reassembly request message is sent again, and the timeout mechanism is restarted.
If the NS fragment reassembly confirmation message or the fragment reassembly request message is not received after timeout. And when the transmission of the current fragment fails, discarding the fragment, and returning a fragment transmission result to quit the transmission.
The NS also sets a timeout mechanism, resets a timeout time after receiving a fragment or a reassembly request message each time, and sends a fragment reassembly failure message if the fragment reassembly is not completed after a timeout period, then releases the received fragment and finishes the reassembly.
The length of the timeout period should consider the maximum transmission duration of 3 transmission fragments, plus a certain time margin.
Fig. 6 is a schematic flow chart of large data transmission performed by the transmitting end and the receiving end in the present invention. The sending end may be a server or a Lora terminal, and correspondingly, the receiving end may be a Lora terminal or a server.
The flow of the sending end for transmitting the big data is as follows:
step 1: the big data transmission starts;
step 2: the message is fragmented in a fixed length and continuously sent;
and step 3: after the fragment sending is finished, continuously sending 3 repacking request messages;
and 4, step 4: starting an overtime timer to wait for the response of a receiving end; if overtime or receiving the repacking failure message, executing the step 5, otherwise executing the step 6;
and 5: returning to failure, releasing the fragment, and exiting the fragment transmission;
step 6: receiving a fragment retransmission request of a receiving end, suspending a timer, continuously sending out requested fragments and continuously sending out 3 reassembly request messages;
and 7: starting an overtime timer to wait for the response of a receiving end; if yes, executing step 5, otherwise executing step 8;
and 8: receiving a repacking success confirmation message, and closing the timer;
and step 9: and the releasing of the fragments returns to be successful, and the fragment transmission is quitted.
The flow of the receiving end for transmitting the big data is as follows:
step 1: the receiving end receives the fragments;
step 2: starting an overtime timer after receiving a first fragment, and resetting the overtime timer once receiving a fragment or a reassembling request message; judging whether the timer is overtime, if so, executing the step 3, otherwise, executing the step 4;
and step 3: continuously sending reassembly failure messages for 3 times, releasing the fragments, exiting reassembly;
and 4, step 4: when the last fragment is received or a reassembling request message is received, suspending the overtime timer and starting to try reassembling; and judging whether the fragments are lost too much, executing the step 3, otherwise executing the step 5;
and 5: when the fragments are found to be lost but not many, continuously transmitting fragment retransmission request messages for 3 times to a transmitting end, and starting an overtime timer;
step 6: receiving the retransmission fragments, and resetting the timeout timer once each fragment or reassembly request message is received;
and 7: receiving and storing the fragments, receiving a reassembling request message, suspending the timer, and attempting to reassemble again;
and 8: if the reassembly is successful, continuously sending a reassembly successful message to the sending end for 3 times;
and step 9: and releasing the fragments, returning the reassembled data, and exiting the reassembly.
The above description is only a preferred embodiment of the present invention, and is not intended to limit the scope of the present invention, and all modifications and equivalents of the present invention, which are made by the contents of the present specification and the accompanying drawings, or directly/indirectly applied to other related technical fields, are included in the scope of the present invention.
Claims (10)
1. A method for reloading and retransmitting Lora messages is characterized by comprising the following steps:
the receiving end starts to reassemble the data after receiving the last fragment or reassembly request message; if the reassembly is successful, the receiving end continuously sends a first preset number of fragment reassembly completion confirmation messages to the sending end; if the reassembly is overtime, the receiving end continuously sends a second preset number of fragment reassembly failure messages to the sending end, and deletes the stored fragments at the same time;
after receiving the fragment retransmission request, the sending end retransmits the fragment requested to be retransmitted by the receiving end again; and after the fragment retransmission is finished, continuously sending fragment reassembly request messages of a third preset number of times, wherein if a small number of fragments are found not to be received, the receiving end continuously sends the fragment retransmission request messages of a fourth preset number of times.
2. The method of claim 1, wherein the first predetermined number, the second predetermined number, the third predetermined number, and the fourth predetermined number are all 3.
3. A method for reloading and retransmitting Lora messages is used for a sending end and is characterized by comprising the following steps:
step 1: the sending end fragments the message in a fixed length and continuously sends the message;
step 2: after the fragment sending is finished, the sending end continuously sends a first preset number of reassembly request messages;
and step 3: starting an overtime timer to wait for the response of a receiving end and judging whether the timer is overtime or not;
and 4, step 4: if the timer is not overtime and receives the fragment retransmission request of the receiving end, the timer is suspended, the requested fragments are continuously sent out, and a second preset number of reassembly request messages are continuously sent out;
and 5: resetting and starting an overtime timer again to wait for the response of the receiving end; judging whether the timer is overtime;
step 6: if the timer is not overtime and receives the repacking success confirmation message, the timer is closed, the fragments are released, and the fragment transmission is quitted.
4. The method of claim 3, wherein the first predetermined number and the second predetermined number are both 3.
5. The method according to claim 3 or 4, characterized in that the sending end sends the second big data fragment after the transmission and reassembly of the first big data fragment is completed or after the timer is over time.
6. A method for reloading and retransmitting Lora messages is used for a receiving end and is characterized by comprising the following steps:
step 1: the receiving end receives the fragments;
step 2: starting an overtime timer after receiving a first fragment, and resetting the overtime timer once receiving a fragment or a reassembling request message; judging whether the timer is overtime, if so, executing the step 3, otherwise, executing the step 4;
and step 3: continuously sending reloading failure messages of a first preset number of times, releasing the fragments, exiting reloading;
and 4, step 4: when the last fragment is received or a reassembling request message is received, suspending the overtime timer and starting to try reassembling; judging whether the fragments are lost and exceed a first threshold value;
and 5: if the fragment is lost but not more than the first threshold value, continuously sending fragment retransmission request messages of a second preset number of times to the sending end, and starting an overtime timer;
step 6: if receiving the retransmission fragment, resetting the overtime timer and storing the fragment;
and 7: if receiving the repacking request message, suspending the timer and trying to repack again;
and 8: and if the reassembly is successful, continuously sending a reassembly successful message of a third preset number of times to the sending end.
7. The method of claim 6, wherein the first predetermined number of times, the second predetermined number of times, and the third predetermined number of times are all 3.
8. The method according to claim 6 or 7, wherein if the receiving end receives two large data fragments from the same transmitting end at the same time, the receiving end discards the last large data fragment that has not been successfully reassembled.
9. A sender, characterized in that the sender comprises a processor configured to perform the reassembly and retransmission method according to any one of claims 3-5.
10. A receiving end, characterized in that the receiving end comprises a processor configured to perform the reassembly and retransmission method according to any one of claims 6-8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810958892.4A CN109151904B (en) | 2018-08-22 | 2018-08-22 | Lora message reassembly and retransmission method, sending end and receiving end |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201810958892.4A CN109151904B (en) | 2018-08-22 | 2018-08-22 | Lora message reassembly and retransmission method, sending end and receiving end |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109151904A CN109151904A (en) | 2019-01-04 |
| CN109151904B true CN109151904B (en) | 2022-08-16 |
Family
ID=64790607
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201810958892.4A Active CN109151904B (en) | 2018-08-22 | 2018-08-22 | Lora message reassembly and retransmission method, sending end and receiving end |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109151904B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112305458B (en) * | 2020-12-30 | 2021-04-16 | 南京斯泰恩智慧能源技术有限公司 | Wave recording type platform area residual current detection terminal and early warning system |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103973421A (en) * | 2013-02-06 | 2014-08-06 | 腾讯科技（深圳）有限公司 | File transmitting method and device |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8553721B2 (en) * | 2008-08-22 | 2013-10-08 | Lantiq Deutschland Gmbh | Channel bonding and packet fragment retransmission method and apparatus |
| US8761204B2 (en) * | 2010-05-18 | 2014-06-24 | Lsi Corporation | Packet assembly module for multi-core, multi-thread network processors |
| CN107707640A (en) * | 2017-09-25 | 2018-02-16 | 深圳市盛路物联通讯技术有限公司 | A kind of Point-to-Point Data Transmission method and apparatus |
-
2018
- 2018-08-22 CN CN201810958892.4A patent/CN109151904B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103973421A (en) * | 2013-02-06 | 2014-08-06 | 腾讯科技（深圳）有限公司 | File transmitting method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109151904A (en) | 2019-01-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6005710B2 (en) | Status information transmission method and receiver for wireless communication system | |
| EP2811681B1 (en) | Method for moving a receive window in a radio access network | |
| EP3410623B1 (en) | Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications | |
| KR101577451B1 (en) | Method of detecting and handling an endless rlc retransmission | |
| WO2008040725A1 (en) | Efficient tcp ack prioritization in wireless networks | |
| WO2008140222A1 (en) | Method and apparatus for layer 2 arq for packets | |
| RU2460214C2 (en) | Status message initiation in wireless communication system | |
| JP2010541397A (en) | Status reporting method in wireless communication system | |
| CN109067892A (en) | Big data transmission method, terminal and server in a kind of Lora communication system | |
| JP2002135357A (en) | Control method for data flow in communication system | |
| KR101024461B1 (en) | Optimised packet data transmission protocol in a communication system employing a transmission window | |
| KR20090087773A (en) | Apparatus and method for retransmittion packet data unit and reporting status in a mobile communication system | |
| EP1770893A2 (en) | Method and apparatus for initiating a storage window in a wireless communications system | |
| CN109151904B (en) | Lora message reassembly and retransmission method, sending end and receiving end | |
| KR20170126808A (en) | User equipment and communication method of the same | |
| CN116963175A (en) | Data transmission method, device and system | |
| CN114143834A (en) | Wireless link control polling method and device | |
| CN113424578B (en) | Acceleration method and device for transmission control protocol | |
| CN114629599B (en) | Method for confirming message of real-time transmission protocol | |
| CN108933645B (en) | Efficient active polling method for terminal | |
| Winbjörk | TCP Optimized for Wireless Access | |
| TW202220402A (en) | Communication device, and communication method | |
| CN112134832A (en) | TCP wireless retransmission |
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 | ||
| PE01 | Entry into force of the registration of the contract for pledge of patent right |
Denomination of invention: A Lora message reassembly and retransmission method, sender and receiver Effective date of registration: 20221215 Granted publication date: 20220816 Pledgee: Bank of China Limited Suzhou Yangtze River Delta integration Demonstration Zone Branch Pledgor: SUZHOU LINGXI IOT TECHNOLOGY CO.,LTD. Registration number: Y2022980027271 |
|
| PE01 | Entry into force of the registration of the contract for pledge of patent right | ||
| PC01 | Cancellation of the registration of the contract for pledge of patent right |
Granted publication date: 20220816 Pledgee: Bank of China Limited Suzhou Yangtze River Delta integration Demonstration Zone Branch Pledgor: SUZHOU LINGXI IOT TECHNOLOGY CO.,LTD. Registration number: Y2022980027271 |
|
| PC01 | Cancellation of the registration of the contract for pledge of patent right |