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 50 of 89

LoRaWAN ® L2 1.0.4 Specification © 2020 LoRa Alliance ® Page 51 of 90 The authors reserve the right to change specifications without notice. 8 Introduction to Class B 1603 This section describes the LoRaWAN Class B layer, which is optimized for battery-powered 1604 end-devices that may be either mobile or mounted at a fixed location. 1605 End-devices SHOULD implement Class B operation when there is a requirement to open 1606 receive windows at fixed time intervals for the purpose of enabling network-initiated downlink 1607 frames. Class B-capable end-devices SHALL NOT enable Class B and Class C operation 1608 concurrently. 1609 LoRaWAN Class B option adds a synchronized reception window on the end-device. 1610 One of the limitations of LoRaWAN Class A is the ALOHA method of sending data from the 1611 end-device; it does not allow for a known reaction time when the customer application or the 1612 server wants to address the end-device. The purpose of Class B is to have an end-device 1613 available for reception at a predictable time, in addition to the reception windows that follows 1614 the random uplink transmission from the end-device of Class A. Class B is achieved by having 1615 the gateway send a beacon on a regular basis to synchronize all end-devices in the network 1616 so that the end-device can open a short additional reception window (called a ping slot) at a 1617 predictable time during a periodic time slot. 1618 1619 Note: The decision to switch from Class A to Class B comes from the 1620 application layer of the end-device. If this switch from Class A to Class 1621 B has to be controlled from the network side, the customer application 1622 must use one of the end-device's Class A uplinks to send back a 1623 downlink to the application layer, and it needs the application layer on 1624 the end-device to recognize this request—this process is not managed 1625 at the LoRaWAN level. 1626 8.1 Principle of Synchronous Network-initiated Class B Downlinks 1627 For a network to support end-devices of Class B, the Network SHALL broadcast a beacon that 1628 provides a timing reference to end-devices. Based on this timing reference, the Class B- 1629 enabled end-devices SHALL periodically open receive windows, hereafter called ping slots, 1630 which can be used by the Network to initiate a downlink communication. A Network-initiated 1631 downlink using one of these ping slots is called a ping. The gateway chosen to initiate this 1632 downlink communication is selected by the Network Server. For this reason, if an end-device 1633 moves and detects a change in the identity advertised in the received beacon, it SHALL send 1634 an uplink to the Network Server so that the server can update the downlink routing path 1635 database. 1636 When enabling Class B mode, an end-device SHALL use the defined values for the following 1637 parameters: 1638 Default ping-slot periodicity 1639 Default ping-slot data rate 1640 Default ping-slot channel. 1641 These parameters have default values defined in the "Regional Parameters Specification" 1642 [RP002] and MAY be updated via Class B MAC commands (cf. Section 12). 1643 All end-devices start and join the network as Class A end-devices with Class B disabled. The 1644 end-device application can then decide to enable Class B. Class B-capable end-devices still 1645 implement all functionalities of Class A end-devices. In particular, Class B-enabled end- 1646 devices SHALL respect the Class A RX1 and RX2 receive window definition following every 1647 uplink (cf. Section 3.3). 1648

Articles in this issue

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