Issue link: https://read.uberflip.com/i/1428383
LoRaWAN 1.0.3 Specification ©2018 LoRa™ Alliance Page 56 of 72 The authors reserve the right to change specifications without notice. 15.5 Network downlink route update requirements 1489 When the network attempts to communicate with an end-device using a Class B downlink slot, 1490 it transmits the downlink from the gateway which was closest to the end-device when the last 1491 uplink was received. Therefore the Network Server needs to keep track of the rough position 1492 of every Class B device. 1493 Whenever a Class B device moves and changes cell, it needs to communicate with the 1494 Network Server in order to update its downlink route. This update can be performed simply 1495 by sending a "confirmed" or "unconfirmed" uplink, possibly without applicative payload. 1496 The end-device has the choice between 2 basic strategies: 1497 • Systematic periodic uplink: simplest method that doesn't require demodulation of the 1498 "gateway specific" field of the beacon. Only applicable to slowly moving or stationery 1499 end-devices. There are no requirements on those periodic uplinks. 1500 • Uplink on cell change: The end-device demodulates the optional "gateway specific" 1501 field of the beacon, detects that the ID of the gateway broadcasting the beacon it 1502 demodulates has changed, and sends an uplink. In that case the device SHALL 1503 respect a pseudo random delay in the [0:120] seconds range between the beacon 1504 demodulation and the uplink transmission. This is required to insure that the uplinks 1505 of multiple Class B devices entering or leaving a cell during the same beacon period 1506 will not systematically occur at the same time immediately after the beacon 1507 broadcast. 1508 Failure to report cell change will result in Class B downlink being temporary not operational. 1509 The Network Server may have to wait for the next end-device uplink to transmit downlink 1510 traffic. 1511 1512 1513