本申请公开了一种快速确认的LoRaWAN系统的实现方法，包括：步骤S302：将最近一次向节点A转发下行数据的网关作为节点A的主网关；步骤S304：节点A向服务器发送上行数据；步骤S306：节点A的主网关收到上行数据后就立即给节点A回复LACK帧，并将所述上行数据转发给服务器；步骤S308：如果节点A在预定时间内收到主网关回复的所述LACK帧，则判断所述LACK帧是否对应于之前发送的所述上行数据；如果否，则进入步骤S310；如果节点A在预定时间内未收到所述LACK帧，则进入步骤S310；步骤S310：节点A延迟一段时间后向服务器重发所述上行数据，回到步骤S306。本申请使得节点能够快速确认之前发送的上行数据是否已被其主网关正确接收，使数据传输更加可靠。
1.一种快速确认的LoRaWAN系统的实现方法，其特征是，包括如下步骤：
步骤S302：将最近一次向节点A转发下行数据的网关作为节点A的主网关；
步骤S306：节点A的主网关收到上行数据后就立即给节点A回复LACK帧，并将所述上行数据转发给服务器；所述LACK帧是指网关应答信息；
步骤S308：如果节点A在预定时间内收到主网关回复的所述LACK帧，则判断所述LACK帧是否对应于之前发送的所述上行数据；如果是，则节点A继续后续流程；如果否，则进入步骤S310；
所述后续流程是指在随后的RX1和RX2下行接收窗口中等待接收服务器回复的ACK帧；
所述ACK帧是指应答信息；如果节点A在预定时间内收到服务器回复的所述ACK帧，则继续向服务器发送上行数据；
如果节点A在预定时间内未收到所述LACK帧，则进入步骤S310；
步骤S310：节点A延迟一段时间后向服务器重发所述上行数据，回到步骤S306。
2.根据权利要求1所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S306中，所述LACK帧中包含节点A的DevAddr、所述上行数据的FCnt和应答标识。
3.根据权利要求2所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S308中，当所述LACK帧中的DevAddr与节点A的DevAddr匹配、且所述LACK帧中的FCnt与节点A之前发送的所述上行数据的FCnt匹配、且应答标识正确，则节点A判断所述LACK帧对应于之前发送的所述上行数据；否则节点A判断所述LACK帧不对应于之前发送的所述上行数据。
4.根据权利要求1所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S310中，所述延迟一段时间的长度是随机的。
5. 根据权利要求1所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S304中，所述上行数据是Confirmed Data Up消息；所述步骤S306中，服务器收到所述Confirmed Data Up消息后，向节点A回复ACK帧；节点A的主网关收到所述ACK帧后，转发给节点A。
6.根据权利要求1所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S308中，节点A在发送上行数据结束后立即打开一个新增的下行接收窗口RX0，用于接收节点A的主网关回复的LACK帧；所述RX0起始于上行数据发送结束的时间点，终止于RX1的起始时间点之前。
7.根据权利要求6所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S308中，节点A在新增的下行接收窗口RX0中先接收LACK帧的下行前导头；如果节点A收到LACK帧的下行前导头，则节点A在所述下行接收窗口RX0中继续接收LACK帧的剩余部分并进行LACK帧验证，验证成功则认为收到LACK帧；否则认为未收到LACK帧。
8.根据权利要求1所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S302中，某一个网关成为节点A的主网关的过程包括如下步骤：步骤S502：节点A向服务器发送上行数据；
步骤S504：网关D收到所述上行数据后，将其转发给服务器；
步骤S506：服务器通过网关D向节点A发送下行数据，此时网关D成为节点A的主网关。
9.根据权利要求1所述的快速确认的LoRaWAN系统的实现方法，其特征是，所述步骤S302中，节点A的主网关丧失主网关身份的过程包括如下步骤：步骤S602：节点A向服务器发送上行数据一；
步骤S604：节点A的主网关E收到上行数据一后，记录所述上行数据一由节点A上报至网关E的上报时间，并立即给节点A回复LACK帧，并将所述上行数据一转发给服务器；
步骤S606：服务器使用网关F转发下行数据给节点A，此时网关F成为节点A的新的主网关；
步骤S610：网关E收到上行数据二后，记录所述上行数据二由节点A上报至网关E的上报时间，发现本次上行数据二的上报时间已超过上次上行数据一的下行确认时间，且在此期间内服务器并未通过网关E转发下行数据，则网关E知道自己已丧失节点A的主网关身份。
10.根据权利要求9所述的快速确认的LoRaWAN系统的实现方法，其特征是，与所述步骤S610同时地，节点A此时的主网关F收到上行数据二后，记录所述上行数据二由节点A上报至网关F的上报时间，并立即给节点A回复LACK帧，并将所述上行数据二转发给服务器。
11.一种快速确认的LoRaWAN系统，其特征是，包括节点A、节点A的主网关、服务器；
所述节点A在发送上行数据结束后立即打开一个新增的下行接收窗口，用于接收节点A的主网关回复的LACK帧；所述LACK帧是指网关应答信息；所述节点A还用来判断在预定时间内是否收到主网关回复的所述LACK帧，如果是则继续判断所述LACK帧是否对应于之前发送的所述上行数据；如果任一为否，则节点A延迟一段时间后向服务器重发所述上行数据；
所述节点A的主网关是指向节点A转发下行数据的网关中最近一次进行转发的网关，其用于收到节点A发送的上行数据后就立即给节点A回复LACK帧，并将所述上行数据转发给服务器。
一种快速确认的LoRaWAN系统及其实现方法
技术领域
[0001] 本申请涉及一种LoRaWAN系统，特别是涉及LoRaWAN系统中对于确认上行帧进行快速确认的方案。
背景技术
[0002] LoRaWAN（Long Range Wide Area Network，长距离广域网）系统是一种长距离、低功耗的广域网。其网络架构中包含节点（End Nodes）、网关（Gateway）和服务器，服务器又分为直接与网关进行通讯的网络服务器以及位于网络服务器后端的应用服务器。节点与网关之间采用LoRa（Long Range，长距离）技术进行无线通信。网关与服务器之间采用TCP/IP协议进行通信。网关对节点和服务器之间的LoRaWAN协议数据做转发处理。
[0003] 在LoRaWAN系统中，节点经过一个或多个网关中转向服务器发送数据称为上行，服务器只通过一个网关中转向唯一确定的节点发送数据称为下行。
[0004] LoRaWAN协议中定义了多种MAC消息类型，至少包括Join Request（入网请求）、Join Accept（入网许可）、Unconfirmed Data Up（非确认上行帧）、Unconfirmed Data Down（非确认下行帧）、Confirmed Data Up（确认上行帧）、Confirmed Data Down（确认下行帧）。其中，确认帧（Confirmed data）需要由接收方向发送方回复应答（Ack）信息，而非确认帧（Unconfirmed data）不需要由接收方向发送方回复应答信息。
[0005] LoRaWAN协议根据应用场景制定了三种类型（Classes），规范节点与服务器之间的通讯命令和消息格式等，这三种类型分别是Class A、Class B和Class C。Class A是节点先进行上行发送，在上行发送后开启一段时间的下行接收窗口，节点只有在上行发送后才进行下行接收。Class B是在Class A的基础上增加节点和服务器协商好下行接收窗口的开启时间，然后在约定的时间进行下行接收。Class C是节点在除上行发送以外的其他时间都开启下行接收窗口。
[0006] 请参阅图1，这是LoRaWAN Class A应用场景下的下行接收窗口示意图。由于所有的LoRaWan设备都必须实现Class A，所以该下行接收窗口亦适用于Class B和Class C应用场景，这一点不再赘述。某节点向服务器发送上行数据结束后，等待RECEIVE_DELAY1（接收延时1）的时间后打开RX1（下行接收窗口1）；同样以发送上行数据结束为起点等待RECEIVE_DELAY2（接收延时2）的时间后打开RX2（下行接收窗口2）。如果上行数据是确认帧，由于现有的LoRaWAN系统没有网关的确认信息，需要等待服务器回复的应答信息进行确认。而在Class A应用场景下，节点只能在发送上行数据之后的两个下行接收窗口RX1和RX2接收服务器回复的应答信息，这个下行接收窗口的限制导致节点收到服务器回复的应答信息的确认过程异常漫长。为了缩减确认时间，通常会修改LoRaWAN系统的RECEIVE_DELAY1和/或RECEIVE_DELAY2的时长。但因为服务器通常需要留200至400ms的时间来进行数据去重，过度缩短RECEIVE_DELAY1和/或RECEIVE_DELAY2的时间，会影响服务器的数据去重功能。
[0007] 请参阅图2，同样在Class A应用场景下，某节点向服务器发送确认帧0结束后，等待RECEIVE_DELAY2加上ACK_TIMEOUT（应答超时）的总时间仍未收到服务器回复的应答信息，则节点向服务器重复发送确认帧0。这个RECEIVE_DELAY2加上ACK_TIMEOUT的总时间大约4s，这对于时间敏感的应用是很难接受的。
发明内容
[0008] 本申请所要解决的技术问题是提供一种快速确认的LoRaWAN系统的实现方法，使得节点能够迅速了解之前发送的上行数据是否已被网关正确接收，便于节点进行重发等后续操作。为此，本申请还要提供一种快速确认的LoRaWAN系统。
[0009] 为解决上述技术问题，本申请提供了一种快速确认的LoRaWAN系统的实现方法，包括如下步骤：步骤S302：将最近一次向节点A转发下行数据的网关作为节点A的主网关。步骤S304：节点A向服务器发送上行数据。步骤S306：节点A的主网关收到上行数据后就立即给节点A回复LACK帧，并将所述上行数据转发给服务器。所述LACK帧是指网关应答信息。步骤S308：如果节点A在预定时间内收到主网关回复的所述LACK帧，则判断所述LACK帧是否对应于之前发送的所述上行数据；如果是，则节点A继续后续流程；如果否，则进入步骤S310。所述后续流程是指在随后的RX1和RX2下行接收窗口中等待接收服务器回复的ACK帧；所述ACK帧是指应答信息；如果节点A在预定时间内收到服务器回复的所述ACK帧，则继续向服务器发送上行数据。如果节点A在预定时间内未收到所述LACK帧，则进入步骤S310。步骤S310：节点A延迟一段时间后向服务器重发所述上行数据，回到步骤S306。
[0010] 传统的LoRaWAN系统中，网关并不会向节点发送确认信息。本申请提供的快速确认的LoRaWAN系统的实现方法中，为每个节点确定了在任意时刻唯一的主网关，并由主网关为相应节点的上行数据发送确认信息即LACK帧，从而为该节点提供了快速确认其发送的上行数据已被其主网关成功接收的便利。
[0011] 进一步地，所述步骤S306中，所述LACK帧中包含节点A的DevAddr、所述上行数据的FCnt和应答标识。这些信息用于判断所述LACK帧与之前传输的上行数据是否对应。其中的DevAddr用于判断节点身份是否正确，FCnt用于判断上行数据与LACK帧是否对应，应答标识用于判断格式是否准确。
[0012] 进一步地，所述步骤S308中，当所述LACK帧中的DevAddr与节点A的DevAddr匹配、且所述LACK帧中的FCnt与节点A之前发送的所述上行数据的FCnt匹配、且应答标识正确，则节点A判断所述LACK帧对应于之前发送的所述上行数据；否则节点A判断所述LACK帧不对应于之前发送的所述上行数据。这为判断所述LACK帧与之前传输的上行数据是否对应提供了一种具体的实现方式。
[0013] 进一步地，所述步骤S310中，所述延迟一段时间的长度是随机的。这是一种优选的实现方式，避免多个节点同时重发上行数据产生网络拥塞。
[0014] 进一步地，所述步骤S304中，所述上行数据是Confirmed Data Up消息。所述步骤S306中，服务器收到所述Confirmed Data Up消息后，向节点A回复ACK帧；节点A的主网关收到所述ACK帧后，转发给节点A。这是一种优选的实现方式，表明本申请特别适用于Confirmed Data Up消息的快速确认。
[0015] 进一步地，所述步骤S308中，节点A在发送上行数据结束后立即打开一个新增的下行接收窗口RX0，用于接收节点A的主网关回复的LACK帧；所述RX0起始于上行数据发送结束的时间点，终止于RX1的起始时间点之前。这是为新增的网关回复的确认信息增加一个专属的下行接收窗口，通常不会延续到RX1的起始时间点。
[0016] 进一步地，所述步骤S308中，节点A在新增的下行接收窗口RX0中先接收LACK帧的下行前导头。如果节点A收到LACK帧的下行前导头，则节点A在所述下行接收窗口RX0中继续接收LACK帧的剩余部分并进行LACK帧验证，验证成功则认为收到LACK帧；否则认为未收到LACK帧。这是节点A如何接收LACK帧的一种优选实现方式。
[0017] 进一步地，所述步骤S302中，某一个网关成为节点A的主网关的过程包括如下步骤：步骤S502：节点A向服务器发送上行数据。步骤S504：网关D收到所述上行数据后，将其转发给服务器。步骤S506：服务器通过网关D向节点A发送下行数据，此时网关D成为节点A的主网关。这表明每个节点的主网关的身份是如何得到的。
[0018] 进一步地，所述步骤S302中，节点A的主网关丧失主网关身份的过程包括如下步骤：步骤S602：节点A向服务器发送上行数据一。步骤S604：节点A的主网关E收到上行数据一后，记录所述上行数据一由节点A上报至网关E的上报时间，并立即给节点A回复LACK帧，并将所述上行数据一转发给服务器。步骤S606：服务器使用网关F转发下行数据给节点A，此时网关F成为节点A的新的主网关。步骤S608：节点A再次向服务器发送上行数据二。步骤S610：网关E收到上行数据二后，记录所述上行数据二由节点A上报至网关E的上报时间，发现本次上行数据二的上报时间已超过上次上行数据一的下行确认时间，且在此期间内服务器并未通过网关E转发下行数据，则网关E知道自己已丧失节点A的主网关身份。这表明每个节点的主网关的身份是如何丧失的，并且在某个节点的主网关身份丧失的同时或之前其新的主网关已经被确定下来。
[0019] 进一步地，与所述步骤S610同时地，节点A此时的主网关F收到上行数据二后，记录所述上行数据二由节点A上报至网关F的上报时间，并立即给节点A回复LACK帧，并将所述上行数据二转发给服务器。这是某个节点的主网关发生更替以后的实现方式。
[0020] 本申请还提供了一种快速确认的LoRaWAN系统，包括节点A、节点A的主网关、服务器；所述节点A在发送上行数据结束后立即打开一个新增的下行接收窗口，用于接收节点A的主网关回复的LACK帧；所述LACK帧是指网关应答信息；所述节点A还用来判断在预定时间内是否收到主网关回复的所述LACK帧，如果是则继续判断所述LACK帧是否对应于之前发送的所述上行数据；如果任一为否，则节点A延迟一段时间后向服务器重发所述上行数据。所述节点A的主网关是指向节点A转发下行数据的网关中最近一次进行转发的网关，其用于收到节点A发送的上行数据后就立即给节点A回复LACK帧，并将所述上行数据转发给服务器。
[0021] 传统的LoRaWAN系统中，网关并不会向节点发送确认信息。本申请提供的快速确认的LoRaWAN系统中，为每个节点确定了在任意时刻唯一的主网关，并由主网关为相应节点的上行数据发送确认信息即LACK帧，从而为该节点提供了快速确认其发送的上行数据已被其主网关成功接收的便利。
[0022] 本申请取得的技术效果是由每个节点在任意时刻唯一的主网关直接给节点发送LACK帧，加快确认过程，缩短数据确认时间。整个方案不改动服务器的操作，使得节点能够快速确认之前发送的上行数据是否已被其主网关正确接收，使数据传输更加可靠。
附图说明
[0023] 图1是LoRaWAN Class A应用场景下的下行接收窗口示意图。
[0024] 图2是LoRaWAN Class A应用场景下的重发上行数据的耗时示意图。
[0025] 图3是本申请快速确认的LoRaWAN系统的实现方法的流程图。
[0026] 图4是本申请新增下行接收窗口的示意图。
[0027] 图5是某一个网关成为节点A的主网关的过程的流程图。
[0028] 图6是节点A的主网关丧失主网关身份的过程的流程图。
[0029] 图7是本申请快速确认的LoRaWAN系统的结构示意图。
[0030] 图中附图标记说明：10为节点A；20为节点A的主网关；30为服务器。
具体实施方式
[0031] 请参阅图3，这是本申请快速确认的LoRaWAN系统的实现方法，其包括如下步骤。
[0032] 步骤S302：将最近一次向节点A转发下行数据的网关作为节点A的主网关。所述下行数据是由服务器发送给节点A的，需要由仅一个网关进行中转。
[0033] 例如，节点A通过一个或多个网关向服务器发送Join Request消息，服务器通过网关B向节点A发送Join Accept消息。此时网关B就是节点A的主网关。
[0034] 又如，节点A通过一个或多个网关向服务器发送Confirmed Data Up消息，服务器通过网关C向节点A发送应答信息。此时网关C就是节点A的主网关。
[0035] 步骤S304：节点A向服务器发送上行数据。
[0036] 步骤S306：节点A的主网关收到上行数据后就立即给节点A回复LACK帧（网关应答信息），并将所述上行数据转发给服务器。
[0037] 这一步中，如果是除节点A的主网关以外的其他网关收到上行数据后就将所述上行数据转发给服务器，不需要给节点A回复LACK帧。
[0038] 优选地，所述LACK帧中包含节点A的DevAddr（设备地址）、所述上行数据的FCnt（帧计数器）、应答（Ack）标识等信息。
[0039] 步骤S308：如果节点A在预定时间内收到主网关回复的所述LACK帧，则判断所述LACK帧是否对应于之前发送的所述上行数据。如果是，则表明节点A的主网关已接收到之前发送的所述上行数据，继续后续流程。如果否，则表明节点A的主网关未收到之前发送的所述上行数据，进入步骤S310。
[0040] 优选地，节点A根据所述LACK帧中的DevAddr与自身的DevAddr是否匹配、所述LACK帧中的FCnt与之前发送的所述上行数据的FCnt是否匹配、应答标识是否正确来判断所述LACK帧是否对应于之前发送的所述上行数据。只有前两者均匹配且应答标识正确，才表明所述LACK帧对应于之前发送的所述上行数据。
[0041] 如果节点A在预定时间内未收到所述LACK帧，则表明节点A的主网关未收到之前发送的所述上行数据，进入步骤S310。
[0042] 步骤S310：节点A延迟一段时间后向服务器重发所述上行数据，回到步骤S306。优选地，所述延迟一段时间的长度是随机的。
[0043] 上述快速确认的LoRaWAN系统的实现方法中，优选地，步骤S304中的所述上行数据是Confirmed Data Up消息。相应地，步骤S306中，服务器收到所述Confirmed Data Up消息后，向节点A回复ACK帧。节点A的主网关收到所述ACK帧后，转发给节点A。相应地，步骤S308中，所述后续流程是指在随后的RX1和RX2下行接收窗口中等待接收服务器回复的ACK帧；如果节点A在预定时间内收到服务器回复的所述ACK帧，则继续向服务器发送上行数据。
[0044] 仍以所述上行数据是Confirmed Data Up消息为例，请参阅图4，所述步骤S308中，节点A在发送上行数据结束后立即打开一个新增的下行接收窗口RX0（下行接收窗口0），用于接收节点A的主网关回复的LACK帧。所述RX0起始于上行数据发送结束的时间点，通常不会延续到RX1的起始时间点，而是终止于RX1的起始时间点之前。
[0045] 优选地，节点A在新增的下行接收窗口RX0中先接收LACK帧的下行前导头。如果节点A收到LACK帧的下行前导头，则节点A在所述下行接收窗口RX0中继续接收LACK帧的剩余部分并进行LACK帧验证，验证成功则认为收到LACK帧。如果节点A未收到LACK帧的下行前导头、或者验证LACK帧失败，则认为未收到LACK帧。
[0046] 所述步骤S302中，根据LoRaWAN系统的特性，服务器通常会选择当前信号最好的网关发送下行数据，因此主网关就是当前对节点A而言信号最好的网关。需要注意的是，节点A的主网关并不是固定不变的，可以发生变动。
[0047] 请参阅图5，某一个网关成为节点A的主网关的过程包括如下步骤。
[0048] 步骤S502：节点A向服务器发送上行数据。所述上行数据例如是Join Request消息或Confirmed Data Up消息。
[0049] 步骤S504：网关D收到所述上行数据后，将其转发给服务器。
[0050] 步骤S506：服务器通过网关D向节点A发送下行数据，此时网关D成为节点A的主网关。所述下行数据例如是Join Accept消息或者是针对Confirmed Data Up消息的应答信息。
[0051] 请参阅图6，节点A的主网关丧失主网关身份的过程包括如下步骤。
[0052] 步骤S602：节点A向服务器发送上行数据一。所述上行数据一例如是Confirmed Data Up消息。
[0053] 步骤S604：节点A的主网关E收到上行数据一后，记录所述上行数据一由节点A上报至网关E的上报时间，并立即给节点A回复LACK帧，并将所述上行数据一转发给服务器。
[0054] 步骤S606：服务器发现网关F对于节点A而言信号强度更高，使用网关F转发下行数据给节点A，此时网关F成为节点A的新的主网关，但是网关E并不知道自己已丧失节点A的主网关身份。所述下行数据例如是针对Confirmed Data Up消息（上行数据一）的应答信息。
[0055] 步骤S608：节点A再次向服务器发送上行数据二。所述上行数据二例如是Confirmed Data Up消息。
[0056] 步骤S610：网关E收到上行数据二后，记录所述上行数据二由节点A上报至网关E的上报时间，发现本次上行数据二的上报时间已超过上次上行数据一的下行确认时间，且在此期间内服务器并未通过网关E转发下行数据，则网关E知道自己已丧失节点A的主网关身份。所述下行确认时间是指节点A发送上行数据一结束后，应该收到下行数据的预定时间。
[0057] 与步骤S610同时地，此时节点A的主网关F收到上行数据二后，记录所述上行数据二由节点A上报至网关F的上报时间，并立即给节点A回复LACK帧，并将所述上行数据二转发给服务器。
[0058] 与图3所示的快速确认的LoRaWAN系统的实现方法相对应，本申请还提供了一种快速确认的LoRaWAN系统。请参阅图7，所述快速确认的LoRaWAN系统包括节点A 10、节点A的主网关20、服务器30。
[0059] 所述节点A 10在向服务器30发送上行数据结束后立即打开一个新增的下行接收窗口RX0，用于接收节点A的主网关20回复的LACK帧。这用来表示节点A的主网关20是否已收到之前发送的所述上行数据。所述节点A 10还用来判断在预定时间内是否收到主网关20回复的所述LACK帧，如果是，则继续判断所述LACK帧是否对应于之前发送的所述上行数据。如果两者均为是，则表明节点A的主网关20已收到之前发送的所述上行数据。如果任一为否，则表明节点A的主网关20未收到之前发送的所述上行数据，节点A 10延迟一段时间后向服务器30重发所述上行数据。
[0060] 所述节点A的主网关20是指向节点A 10转发下行数据的网关中最近一次进行转发的网关，其身份可以发生变化，如图5和图6所示。其用于收到节点A 10发送的上行数据后就立即给节点A回复LACK帧，并将所述上行数据转发给服务器30。
[0061] 以上仅为本申请的优选实施例，并不用于限定本申请。对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。
