Document

TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification

Issue link: https://read.uberflip.com/i/1428395

Contents of this Issue

Navigation

Page 54 of 89

LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 55 of 90 The authors reserve the right to change specifications without notice. The LoRaWAN Class B specification does not specify means to set up such a multicast group 1733 remotely or to distribute the required multicast key material securely. This can be performed 1734 either during the end-device personalization or through the application layer. 1735 1736 Example: The document [RPD1] describes a possible application layer 1737 mechanism for over-the-air multicast key distribution. 1738 9.3.1 Unicast downlink ping frame format 1739 The MAC payload of a unicast downlink ping uses the format defined in the Class A 1740 specification. The same frame counter is incremented, whether the downlink uses a Class B 1741 ping slot or a Class A downlink slot. A downlink ping is processed by the end-device in the 1742 same way as a Class A downlink, except for MAC commands and confirmed frames. 1743 A downlink ping SHALL NOT transport any MAC command. If an end-device receives a 1744 downlink ping containing a MAC command, either in the FOpts field (if FPort is either 1745 missing or >0) or in the FRMPayload field (if FPort=0), it SHALL silently discard the entire 1746 frame. 1747 In case a confirmed downlink ping frame is received, the end-device SHALL NOT answer later 1748 than a time period equal to CLASS_B_RESP_TIMEOUT * NbTrans + RECEIVE_DELAY2 1749 * (NbTrans-1) when the end-device sets its uplink ADR bit, and CLASS_B_RESP_TIMEOUT 1750 when the end-device unsets its uplink ADR bit. The default value of 1751 CLASS_B_RESP_TIMEOUT is 8s. It can be modified in [RP002], it SHALL not be smaller 1752 than RETRANSMIT_TIMEOUT plus the maximum time on air of the uplink frame. 1753 1754 Note: The purpose of this timeout is for the Network Server to know how 1755 long to wait for a response from the end-device, before it transmits 1756 another confirmed downlink. This ensures that the Network Server can 1757 process responses without any ambiguity: there may be only a single 1758 confirmed downlink ping pending an acknowledgement. 1759 1760 The uplink frame sent in response MAY be sent up to NbTrans times, but no retransmission 1761 SHALL occur after the timeout period. It is RECOMMENDED that the end-device transmits 1762 each copy of the uplink frame at a random time within CLASS_B_RESP_TIMEOUT. 1763 As this adds a timing requirement compared to responding to Class A downlinks, the end- 1764 device may not send an uplink frame within the timeout, for instance if it has a duty cycle 1765 limitation. When such an uplink frame is not sent, the end-device SHALL act as if the uplink 1766 frame with the ACK bit set was sent. 1767 After sending a confirmed downlink frame sent over pingslot, the network server SHALL NOT 1768 send any other confirmed downlink to the end-device until this timeout expires or an uplink 1769 frame is received from that end-device. 1770 After sending a Class A confirmed downlink, a network server SHALL NOT send any other 1771 confirmed downlink to the end-device until an uplink frame is received from that end-device. 1772 1773 Note: unconfirmed downlink frames sent over ping slots may be sent 1774 without a minimum delay between them. 1775

Articles in this issue

view archives of Document - TS001-1.0.4 LoRaWAN® L2 1.0.4 Specification