Detailed Description
The terminology used in the embodiments of the disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. As used in this disclosure and the claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein is meant to encompass any and all possible combinations of one or more of the associated listed items.
It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information in the embodiments of the present disclosure, such information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present disclosure. Depending on the context, moreover, the word "if" as used may be interpreted as "at … …" or "when … …" or "in response to a determination".
The LoRa network includes an LoRa terminal and an LoRa server, the LoRa terminal and the LoRa server communicate with each other using LoRaWAN protocol, and the modes supported by the LoRa terminal include a ClassA mode, a ClassB mode, and a ClassC mode.
Fig. 1A is a schematic diagram of message transmission in a ClassA mode. And the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the first type window RX1 is opened after the preset first time (such as DELAY1) is waited. After the first type window RX1 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the first type window RX 1. The window duration of the first type window RX1 may be less than 1 second, and when the closing condition of the first type window RX1 is reached (e.g., the end time of the window duration is reached), the first type window RX1 may be closed.
In addition, after the uplink message is successfully sent, after waiting for a preset second time (e.g., DELAY2), the LoRa terminal opens a second type window RX 2. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the second type window RX 2. The window duration of the second type window RX2 may be less than 1 second, and when the closing condition of the second type window RX2 is reached (e.g., the end time of the window duration is reached), the second type window RX2 may be closed.
The preset first time and the preset second time can be configured according to experience, and values of the preset first time and the preset second time are not limited. Referring to fig. 1A, the preset second time may be greater than the preset first time, for example, the preset second time may be the sum of the preset first time and 1 second.
The window duration of the first type window RX1 and the window duration of the second type window RX2 may be the same or different, and are not limited thereto. For example, the window duration of the first type of window RX1 is less than 1 second, and the window duration of the second type of window RX2 is less than 1 second.
The parameters (such as the message receiving rate) of the LoRa terminal in the first type window RX1 and the parameters (such as the message receiving rate) of the LoRa terminal in the second type window RX2 may be different.
For example, in the first type window RX1, the LoRa terminal may receive the downlink packet at the first packet receiving rate; in the second type window RX2, the LoRa terminal may receive the downlink packet at a second packet receiving rate, where the first packet receiving rate is different from the second packet receiving rate. Of course, the above parameters are not limited to the message receiving rate, and may also be other types of parameters, which are not limited to this.
Fig. 1B is a schematic diagram of message transmission in the ClassC mode. And the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, a second type window RX2 is opened. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the second type window RX 2. For compatibility with the ClassA mode, the window duration of the second type window RX2 may be a preset first time, and when the closing condition of the second type window RX2 is reached (e.g., the end time of the window duration is reached, the closing condition of the second type window RX2 is reached, that is, the opening condition of the first type window RX 1), the second type window RX2 may be closed.
After the uplink message is successfully transmitted and the predetermined first time (such as DELAY1) is waited, the first type window RX1 is opened, i.e. after the second type window RX2 is closed, the first type window RX1 is opened. After the first type window RX1 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the first type window RX 1. The window duration of the first type window RX1 may be less than 1 second, and when the closing condition of the first type window RX1 is reached (e.g., the end time of the window duration, i.e., the opening condition of the second type window RX2 is reached), the first type window RX1 may be closed.
After the first type window RX1 is closed, the second type window RX2 is opened. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet returned by the LoRa server for the uplink packet in the second type window RX 2. The second type window RX2 in ClassC mode is opened for a long time, and the second type window RX2 is closed until the LoRa terminal needs to send an upstream message to the LoRa server.
After closing the second type window RX2, the LoRa terminal may send an uplink message to the LoRa server, and after the uplink message is successfully sent, open the second type window RX 2. After the uplink message is successfully sent and the preset first time is waited, the second type window RX2 is closed, and the first type window RX1 is opened. When the closing condition of the first type window RX1 is reached, the first type window RX1 is closed, and the second type window RX2 is opened until an uplink message needs to be sent to the LoRa server again, and so on.
In the above embodiment, the parameters (such as the message receiving rate) of the LoRa terminal in the first type window RX1 and the parameters (such as the message receiving rate) of the LoRa terminal in the second type window RX2 may be different.
For example, in the first type window RX1, the LoRa terminal may receive the downlink packet at the first packet receiving rate; in the second type window RX2, the LoRa terminal may receive the downlink packet at a second packet receiving rate, where the first packet receiving rate is different from the second packet receiving rate.
Referring to fig. 1A, when the LoRa terminal operates in the ClassA mode, the LoRa terminal may receive, in the first type window RX1, a downlink packet returned by the LoRa server for the uplink packet. However, if the first type window RX1 needs to be closed, all contents of the downlink message are not completely received yet, that is, the LoRa terminal is receiving the downlink message in the first type window RX1, the first type window RX1 needs to be closed, so that the downlink message being received cannot be completely received, that is, the downlink message transmission fails. Thus, the LoRa server needs to send the downlink message to the LoRa terminal again, which wastes air interface resources.
Referring to fig. 1B, when the LoRa terminal operates in the ClassC mode, the LoRa terminal may receive a downlink packet returned by the LoRa server for an uplink packet within the second-type window RX2 (i.e., the first second-type window RX2 in fig. 1B). However, if the second type window RX2 needs to be closed, all contents of the downlink message are not completely received yet, that is, the LoRa terminal is receiving the downlink message in the second type window RX2, the second type window RX2 needs to be closed, so that the downlink message being received cannot be completely received, that is, the downlink message transmission fails. Therefore, the LoRa server needs to send the downlink message to the LoRa terminal again, which wastes air interface resources and results in poor reliability of downlink message transmission.
Referring to fig. 1B, when the LoRa terminal operates in the ClassC mode, the LoRa terminal may receive, in the first type window RX1, a downlink packet returned by the LoRa server for the uplink packet. However, if the first type window RX1 needs to be closed, all contents of the downlink message are not completely received yet, that is, the LoRa terminal is receiving the downlink message in the first type window RX1, the first type window RX1 needs to be closed, so that the downlink message being received cannot be completely received, that is, the downlink message transmission fails. Thus, the LoRa server needs to send the downlink message to the LoRa terminal again, which wastes air interface resources.
In view of the above problem, the present disclosure provides a message transmission method, which may be applied to a network (such as an LoRa network) including an LoRa terminal and an LoRa server, where a message sent by the LoRa terminal to the LoRa server is referred to as an uplink message, and a message sent by the LoRa server to the LoRa terminal is referred to as a downlink message.
In general, the LoRa terminal actively sends an uplink message to the LoRa server, and the LoRa server may send a downlink message (i.e., a response message of the uplink message) to the LoRa terminal after receiving the uplink message.
For example, the LoRa terminal may be a parking space sensor deployed in a parking lot, and when the LoRa terminal detects that an automobile enters a designated position, the LoRa terminal sends an uplink message to the LoRa server, where the uplink message includes information such as a license plate number and entering time. After receiving the uplink message, the LoRa server sends a downlink message to the LoRa terminal, where the downlink message includes information that the LoRa server has received the uplink message. And when the LoRa terminal detects that the automobile leaves the designated position, sending an uplink message to the LoRa server, wherein the uplink message comprises information such as license plate numbers, leaving time and the like. After receiving the uplink message, the LoRa server sends a downlink message to the LoRa terminal, where the downlink message includes information that the LoRa server has received the uplink message. In summary, the LoRa server may perform charging by using the license plate number, the entering time, the leaving time, and other information.
Of course, the application scenario of the parking space sensor is only an example, and the application scenario is not limited.
In the above application scenario, referring to fig. 2, a schematic flow chart of the message transmission method provided by the present disclosure is shown, and the method may be applied to an LoRa terminal, and the method may include the following steps:
step 201, after sending an uplink message to the LoRa server, a first downlink receiving window is started.
Referring to fig. 1A, when the LoRa terminal operates in the ClassA mode, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal starts a first type window RX1 after waiting for a preset first time, that is, the first downlink receiving window is a first type window RX 1.
Referring to fig. 1B, when the LoRa terminal operates in the ClassC mode, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal opens a second type window RX2, that is, the first downlink receiving window is a second type window RX 2. Or, after the LoRa terminal sends the uplink message to the LoRa server successfully, the LoRa terminal starts the first type window RX1 after waiting for the preset first time, that is, the first downlink receiving window is the first type window RX 1.
Step 202, if a downlink message returned by the LoRa server for the uplink message is received in the first downlink receiving window, determining whether the current time meets a closing condition of the first downlink receiving window.
If so, the LoRa terminal may perform step 203. If not, the LoRa terminal may wait until the next time, continue to determine whether the current time meets the closing condition of the first downlink receiving window, and so on until the current time meets the closing condition of the first downlink receiving window, and perform step 203.
After the first downlink receiving window is started, the LoRa terminal may determine whether the current time meets the closing condition of the first downlink receiving window at each time (e.g., each time spaced by 1 ms).
Referring to fig. 1A, the first downlink receive window is a first type window RX1, and the closing condition of the first downlink receive window is a closing condition of a first type window RX 1. For example, assuming that the window duration of the first type window RX1 is 800 msec, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1. Alternatively, from the start of the first type window RX1, it is determined that the current time satisfies the closing condition of the first type window RX1 at the 1000 th millisecond (i.e., the difference between the preset second time and the preset first time). Specifically, since the second type window RX2 needs to be started for the 1000 th millisecond and the first type window RX1 needs to be closed before the second type window RX2 is started, it is determined that the 1000 th millisecond satisfies the closing condition of the first type window RX 1.
Referring to fig. 1B, if the first downlink receive window is the second type window RX2 (i.e. the first second type window RX2 in fig. 1B), the closing condition of the first downlink receive window is the closing condition of the second type window RX 2. For example, assuming that the preset first time is 1200 ms, the timer is started from the start of the second type window RX2, and at the 1200 ms, it is determined that the closing condition of the second type window RX2 is satisfied at the current time.
Referring to fig. 1B, if the first downlink reception window is the first type window RX1, the closing condition of the first downlink reception window may be the closing condition of the first type window RX 1. For example, assuming that the window duration of the first type window RX1 is 800 msec, it may be determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1.
In one example, after receiving a downlink message in a first downlink receiving window, the LoRa terminal may obtain a preamble from the downlink message; and if the message type of the downlink message is determined to be the LoRa type according to the lead code, judging whether the downlink message comprises the address of the LoRa terminal. If the downlink message includes the address of the local LoRa terminal, the LoRa terminal determines that the downlink message is a downlink message returned by the LoRa server for the uplink message. Further, the LoRa terminal determines whether the current time satisfies the closing condition of the first downlink receiving window at each time, and if so, executes step 203.
If the LoRa terminal determines that the downlink message is not a downlink message returned by the LoRa server for the uplink message (i.e., the downlink message is an interference message), the downlink message is processed by using a conventional process. For example, if it is determined that the message type of the downlink message is not the LoRa type according to the preamble, or the downlink message does not include the address of the LoRa terminal, it is determined that the downlink message is not the downlink message returned by the LoRa server for the uplink message.
Step 203, when the current time meets the closing condition of the first downlink receiving window, it is determined whether all the contents of the downlink message are completely received. If not, step 204 may be performed.
When the LoRa server sends the downlink message to the LoRa terminal, the downlink message may include a large amount of contents, which may be referred to as data a, and it is assumed that the data a includes sub-data a1, sub-data a2, and sub-data A3. When sending the downlink message, the LoRa server first sends the downlink message carrying the subdata a1, then sends the downlink message carrying the subdata a2, and then sends the downlink message carrying the subdata A3.
When the current time meets the closing condition of the first downlink receiving window, if the LoRa terminal has received the downlink message carrying the sub-data a1, the sub-data a2, and the sub-data A3 at the current time, it is determined that all the contents of the downlink message are completely received. If the LoRa terminal does not receive the downlink message carrying the sub-data a1, the sub-data a2 or the sub-data A3 at the current time, it is determined that all the contents of the downlink message are not completely received.
Step 204, if the whole content of the downlink message is not completely received, the first downlink receiving window is prohibited from being closed until the whole content of the downlink message is completely received, that is, the downlink message is successfully transmitted.
If the whole content of the downlink message is not completely received, although the current time meets the closing condition of the first downlink receiving window, the LoRa terminal does not close the first downlink receiving window, so that the remaining content of the downlink message is continuously received until the whole content of the downlink message is completely received.
Optionally, in an example, when the LoRa terminal operates in the ClassA mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2. Based on this, after the entire content of the downlink packet is completely received, the first downlink receiving window may also be closed, and the second downlink receiving window is prohibited from being started, that is, the second downlink receiving window is not started any more.
Optionally, in an example, when the LoRa terminal operates in the ClassC mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2. Based on this, after the entire content of the downlink packet is completely received, the first downlink receiving window may also be closed, and the second downlink receiving window is started, that is, the second downlink receiving window needs to be started.
Optionally, in an example, when the LoRa terminal operates in the ClassC mode, the first downlink receive window may be the second type window RX2, and the second downlink receive window may be the first type window RX 1. Based on this, after the entire content of the downlink packet is completely received, the first downlink receiving window may be maintained, and the second downlink receiving window is prohibited from being started, that is, the first downlink receiving window does not need to be closed, the first downlink receiving window is maintained in an open state, and the second downlink receiving window is not started any more.
In one example, after determining whether all the contents of the downlink packet are completely received, if all the contents of the downlink packet are completely received, the first downlink receiving window is closed, and the second downlink receiving window is started in step 203. For example, when the LoRa terminal operates in the ClassA mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2. For another example, when the LoRa terminal operates in the ClassC mode, the first downlink receive window may be the first type window RX1, and the second downlink receive window may be the second type window RX 2; alternatively, the first downlink reception window may be the second type window RX2, and the second downlink reception window may be the first type window RX 1.
Based on the above technical scheme, in the embodiment of the present disclosure, all contents of the downlink message can be completely received, loss of the downlink message is avoided, time overhead and flow overhead caused by retransmission of the message between the LoRa terminal and the LoRa server are saved, air interface resources are saved, and reliability of message interaction between the LoRa terminal and the LoRa server is improved. The problem that the LoRa terminal cannot receive the downlink message is avoided, the packet loss problem is solved, the packet loss rate of the downlink message is reduced, the retransmission flow caused by the loss of the downlink message is reduced, and the communication reliability is improved.
The above technical solution is further described below with reference to several specific application scenarios.
Application scenario 1: the LoRa terminal operates in the ClassA mode, and the first downlink receive window may be a first type window RX1, and the second downlink receive window may be a second type window RX 2.
Referring to fig. 3A, the LoRa terminal sends an uplink packet to the LoRa server, and after the uplink packet is successfully sent, waits for a preset first time (e.g., DELAY1), and then opens a first type window RX 1. After the first type window RX1 is opened, the LoRa terminal may receive the downlink packet in the first type window RX 1.
After receiving the downlink message in the first type window RX1, the LoRa terminal determines whether the downlink message is a downlink message returned by the LoRa server for the uplink message. If so, the technical scheme of the disclosure is adopted, and if not, a traditional flow is adopted, so that the traditional flow is not limited. In order to determine whether the downlink packet is a downlink packet returned by the LoRa server for the uplink packet, the following method may be adopted:
referring to fig. 3B, which is a schematic diagram of a LoRa packet, the LoRa packet may include, but is not limited to, a Preamble, a Header, a Payload CRC (Cyclic redundancy check), and other fields. The preamble is used to indicate a message type, for example, the preamble of the LoRa message is a specific identifier, and the specific identifier indicates that the message type is the LoRa type. The Header includes NwkSKey (for data verification), AppSKey (for data encryption), DevAddr (address of LoRa terminal), and the like. Payload is the data that is actually transmitted and Payload CRC is a CRC check on Payload data. Of course, the above is only an example of the LoRa message, and the method is not limited thereto.
After receiving the downlink message in the first type window RX1, the LoRa terminal first obtains a preamble from the downlink message. If the message type of the downlink message is determined not to be the LoRa type according to the lead code, it is indicated that the downlink message is not the downlink message returned by the LoRa server for the uplink message, and a traditional flow is adopted.
And if the message type of the downlink message is determined to be the LoRa type according to the lead code, acquiring a DevAddr field from the downlink message. If the DevAddr field carries an address that is not the address of the local LoRa terminal, it indicates that the downlink message is not a downlink message returned by the LoRa server for the uplink message, and a conventional flow is adopted.
If the DevAddr field carries the address of the local LoRa terminal, it indicates that the downlink message is a downlink message returned by the LoRa server for the uplink message, and the LoRa terminal adopts the technical scheme disclosed by the present disclosure.
After determining that the downlink message is the downlink message returned by the LoRa server for the uplink message, the LoRa terminal determines whether the current time meets the closing condition of the first type window RX1 at each time. If not, waiting for the next time, continuing to judge whether the current time meets the closing condition of the first type window RX1, and so on until the current time meets the closing condition of the first type window RX 1.
Assuming that the window duration of the first type window RX1 is 800 msec, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1. Alternatively, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at the 1000 th millisecond (i.e., the difference between the preset second time and the preset first time) from the start of the first type window RX 1.
When the current time meets the closing condition of the first type window RX1, the LoRa terminal may further determine whether all the contents of the downlink packet are completely received. If so, the LoRa terminal closes the first type window RX1 and starts the second type window RX 2. If not, the LoRa terminal prohibits closing the first type window RX1 until the LoRa terminal completely receives the entire contents of the downlink packet.
After receiving the entire contents of the downlink packet completely, as shown in fig. 3A, the LoRa terminal may close the first type window RX1, but the LoRa terminal no longer starts the second type window RX 2.
In summary, in the embodiment of the present disclosure, the LoRa terminal operates in the ClassA mode, which may ensure that the LoRa terminal receives a complete downlink packet in the first type window RX1, and may not cause a packet loss problem. Through the judgment of the lead code and the DevAddr field, the influence of interference messages can be greatly reduced.
Application scenario 2: the LoRa terminal operates in the ClassC mode, and the first downlink receive window may be the second type window RX2, and the second downlink receive window may be the first type window RX 1.
Referring to fig. 3C, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal may open the second type window RX 2. After the second type window RX2 is opened, the LoRa terminal may receive the downlink packet within the second type window RX 2. Wherein, for compatibility with the ClassA mode, the window duration of the second type window RX2 may be a preset first time.
After receiving the downlink message in the second type window RX2, the LoRa terminal determines whether the downlink message is a downlink message returned by the LoRa server for the uplink message. If so, the technical scheme of the disclosure is adopted. Specifically, a preamble is obtained from the downlink message, and if the message type of the downlink message is determined to be the LoRa type according to the preamble, the DevAddr field is obtained from the downlink message. If the DevAddr field carries the address of the local LoRa terminal, it indicates that the downlink message is a downlink message returned by the LoRa server for the uplink message.
After determining that the downlink message is the downlink message returned by the LoRa server for the uplink message, the LoRa terminal determines whether the current time meets the closing condition of the second type window RX2 at each time. If not, waiting for the next time, continuing to judge whether the current time meets the closing condition of the second type window RX2, and so on until the current time meets the closing condition of the second type window RX 2.
Wherein, assuming that the preset first time is 1200 ms, the timer is started from the start of the second type window RX2, and at the 1200 ms, it is determined that the current time meets the closing condition of the second type window RX 2.
When the current time meets the closing condition of the second type window RX2, the LoRa terminal may further determine whether all the contents of the downlink packet are completely received. If so, the LoRa terminal closes the second type window RX2 and starts the first type window RX 1. If not, the LoRa terminal prohibits closing the second type window RX2 until the LoRa terminal completely receives the entire content of the downlink packet.
After receiving the entire contents of the downlink packet completely, referring to fig. 3C, the LoRa terminal does not close the second type window RX2, does not start the first type window RX1, and keeps the second type window RX 2.
In summary, in the embodiment of the present disclosure, the LoRa terminal operates in the ClassC mode, which can ensure that the LoRa terminal receives a complete downlink packet in the second type window RX2, and thus the problem of packet loss is not caused. Through the judgment of the lead code and the DevAddr field, the influence of interference messages can be greatly reduced.
Application scenario 3: the LoRa terminal operates in the ClassC mode, and the first downlink receive window may be a first type window RX1, and the second downlink receive window may be a second type window RX 2.
Referring to fig. 3D, the LoRa terminal sends an uplink message to the LoRa server, and after the uplink message is successfully sent, the LoRa terminal may open the second type window RX 2. After the second type window RX2 is opened, the LoRa terminal does not receive the downlink message in the second type window RX 2. Wherein, for compatibility with the ClassA mode, the window duration of the second type window RX2 may be a preset first time.
After the uplink message is successfully transmitted and waits for a predetermined first time (e.g., DELAY1), the LoRa terminal may close the second type window RX2 and open the first type window RX 1. After the LoRa terminal opens the first type window RX1, the LoRa terminal may receive the downlink packet in the first type window RX 1.
After receiving the downlink message in the first type window RX1, the LoRa terminal determines whether the downlink message is a downlink message returned by the LoRa server for the uplink message. If so, the technical scheme of the disclosure is adopted. Specifically, a preamble is obtained from the downlink message, and if the message type of the downlink message is determined to be the LoRa type according to the preamble, the DevAddr field is obtained from the downlink message. If the DevAddr field carries the address of the local LoRa terminal, it indicates that the downlink message is a downlink message returned by the LoRa server for the uplink message.
After determining that the downlink message is the downlink message returned by the LoRa server for the uplink message, the LoRa terminal determines whether the current time meets the closing condition of the first type window RX1 at each time. If not, waiting for the next time, continuing to judge whether the current time meets the closing condition of the first type window RX1, and so on until the current time meets the closing condition of the first type window RX 1.
Assuming that the window duration of the first type window RX1 is 800 msec, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at 800 msec, from the start of the first type window RX 1. Alternatively, it is determined that the closing condition of the first type window RX1 is satisfied at the current time at the 1000 th millisecond (i.e., the difference between the preset second time and the preset first time) from the start of the first type window RX 1.
When the current time meets the closing condition of the first type window RX1, the LoRa terminal may further determine whether all the contents of the downlink packet are completely received. If so, the LoRa terminal closes the first type window RX1 and starts the second type window RX 2. If not, the LoRa terminal prohibits closing the first type window RX1 until the LoRa terminal completely receives the entire contents of the downlink packet.
After receiving the entire contents of the downlink packet completely, as shown in fig. 3D, the LoRa terminal closes the first type window RX1 and starts the second type window RX2, that is, the second type window RX2 needs to be started.
In summary, in the embodiment of the present disclosure, the LoRa terminal operates in the ClassC mode, which can ensure that the LoRa terminal receives a complete downlink packet in the first type window RX1, and thus the problem of packet loss is not caused. Through the judgment of the lead code and the DevAddr field, the influence of interference messages can be greatly reduced.
Based on the same concept as the above method, an embodiment of the present disclosure further provides a message transmission apparatus, which may be applied to an LoRa terminal, and as shown in fig. 4, the apparatus may include:
a starting module 41, configured to start a first downlink receiving window after sending an uplink message to the LoRa server;
a determining module 42, configured to determine whether a current time meets a closing condition of a first downlink receiving window if a downlink packet returned by the LoRa server for the uplink packet is received in the first downlink receiving window; if yes, judging whether the whole content of the downlink message is completely received;
a processing module 43, configured to prohibit closing the first downlink receiving window until all the contents of the downlink packet are completely received if all the contents of the downlink packet are not completely received.
Optionally, in an example, the message transmission apparatus further includes (not shown in fig. 4):
a determining module, configured to obtain a preamble from the downlink packet if the downlink packet is received in the first downlink receiving window; if the message type of the downlink message is determined to be the LoRa type according to the lead code, judging whether the downlink message comprises the address of the LoRa terminal;
and if the downlink message comprises the address of the LoRa terminal, determining that the downlink message is the downlink message returned by the LoRa server aiming at the uplink message.
When the LoRa terminal operates in the ClassA mode, the processing module 43 is further configured to:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2.
When the LoRa terminal operates in the ClassC mode, the processing module 43 is further configured to:
after receiving all the contents of the downlink message completely, closing the first downlink receiving window and starting a second downlink receiving window; wherein the first downlink receiving window comprises a first type window RX1, and the second downlink receiving window comprises a second type window RX 2; or,
after receiving all the contents of the downlink message completely, keeping the first downlink receiving window and forbidding starting a second downlink receiving window; wherein the first downlink receiving window comprises a second type window RX2, and the second downlink receiving window comprises a first type window RX 1.
The processing module 43 is further configured to:
and after judging whether all the contents of the downlink message are completely received or not, if all the contents of the downlink message are completely received, closing the first downlink receiving window and starting a second downlink receiving window.
In terms of hardware, a schematic diagram of a hardware architecture of the LoRa terminal provided in the embodiment of the present disclosure may specifically refer to fig. 5, and may include: a machine-readable storage medium and a processor, wherein:
the machine-readable storage medium stores machine-executable instructions executable by the processor.
The processor is in communication with the machine-readable storage medium, and reads and executes the machine-executable instructions stored in the machine-readable storage medium to implement the message transmission method.
The disclosed embodiments provide a machine-readable storage medium having stored thereon machine-executable instructions that, when invoked and executed by a processor, cause the processor to implement the above-described message transmission method.
Here, a machine-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that can contain or store information such as executable instructions, data, and so forth. For example, the machine-readable storage medium may be: a RAM (random access Memory), a volatile Memory, a non-volatile Memory, a flash Memory, a storage drive (e.g., a hard drive), a solid state drive, any type of storage disk (e.g., an optical disk, a dvd, etc.), or similar storage medium, or a combination thereof.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the various elements may be implemented in the same one or more software and/or hardware implementations in practicing the disclosure.
As will be appreciated by one skilled in the art, embodiments of the present disclosure may be provided as a method, system, or computer program product. Accordingly, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the disclosed embodiments may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and so forth) having computer-usable program code embodied therein.
The present disclosure is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
Furthermore, these computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.
The above description is only an example of the present disclosure and is not intended to limit the present disclosure. Various modifications and variations of this disclosure will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure should be included in the scope of the claims of the present disclosure.