13.2 Slot randomization
- To avoid systematic collisions or over-hearing problems the slot index is randomized and
- changed at every beacon period.
- The following parameters are used:
5
| DevAddr | Device 32 bit network unicast or multicast address |
|---|---|
| pingNb | Number of ping slots per beacon period. This must be a power of 2 |
| integer: pingNb = 2k where 1 <= k <=7 | |
| pingPeriod | Period of the device receiver wake-up expressed in number of slots: |
| pingPeriod = 212/ pingNb | |
| pingOffset | Randomized offset computed at each beacon period start. Values |
| can range from 0 to (pingPeriod-1) | |
| beaconTime | The time carried in the field BCNPayload.Time of the immediately |
| preceding beacon frame | |
| slotLen | Length of a unit ping slot = 30 ms |
6
- At each beacon period the end-device and the server compute a new pseudo-random offset
- to align the reception slots. An AES encryption with a fixed key of all zeros is used to
- randomize:
- Key = 16 x 0x00
- Rand = aes128_encrypt(Key, beaconTime | DevAddr | pad16)
- pingOffset = (Rand[0] + Rand[1]x 256) modulo pingPeriod
- The slots used for this beacon period will be:
- pingOffset + N x pingPeriod with N=[0:pingNb-1]
- The node therefore opens receive slots starting at :
| First slot | Beacon_reserved + pingOffset x slotLen |
|---|---|
| Slot 2 | Beacon_reserved + (pingOffset + pingPeriod) x slotLen |
| Slot 3 | Beacon_reserved + (pingOffset + 2 x pingPeriod) x slotLen |
| … | … |
- If the end-device serves simultaneously a unicast and one or more multicast slots this
- computation is performed multiple times at the beginning of a new beacon period. Once for
- the unicast address (the node network address) and once for each multicast group address.
- In the case where a multicast ping slot and a unicast ping slot collide and cannot be served
- by the end-device receiver then the end-device should preferentially listen to the multicast
- slot. If there is a collision between multicast reception slots the FPending bit of the previous
- multicast frame can be used to set a preference.
- The randomization scheme prevents a systematic collision between unicast and multicast
- slots. If collisions happen during a beacon period then it is unlikely to occur again during the
- next beacon period.
©2016 LoRa™ Alliance Page 46 of 70
The authors reserve the right to change specifications without notice.
| LoRaWAN Specification | ||||||||
|---|---|---|---|---|---|---|---|---|