SmartAnthill DLP for IEEE 802.15.4 (SADLP-802.15.4)


NB: this document relies on certain terms and concepts introduced in SmartAnthill 2.0 Overall Architecture and SmartAnthill 2.0 Protocol Stack documents, please make sure to read them before proceeding.

SADLP-802.15.4 provides L2 datalink over IEEE 802.15.4, suitable for use by SmartAnthill protocol stack in general, and by SAMP (see SmartAnthill Mesh Protocol (SAMP) for details) in particular.

All references to IEEE 802.15.4 standard in this document, marked as [802.15.4], refer to IEEE Std 802.15.4(tm)‐2011, “IEEE Standard for Local and metropolitan area networks—Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)” (which can be obtained at ).

*NB: to be taken with a grain of salt. If there are any issues with implementing it - let’s discuss.*

NB2: current version of SADLP-802-15-4 is very basic, and doesn’t utilize some potentially useful features of IEEE 802.15.4; this is intended to be corrected in the future versions of SADLP-802-15-4. Such features include: uni-cast packets where applicable, security and ACK at 802.15.4 level.

IEEE 802.15.4 Topology, PANs, and Beacons

Current version of SADLP-802.15.4 uses peer-to-peer topology as defined in [802.15.4]. The node with the shortest SAMP distance from Root Node (TODO: define better) becomes “PAN coordinator” as defined in [802.15.4]. Normally, all the 802.15.4 Devices within one SmartAnthill network represent one single 802.15.4 PAN; however, in some cases (different channel frequencies or different collision domains) 802.15.4 Devices within the same SmartAnthill network MAY belong to different 802.15.4 PANs (therefore using different 802.15.4 PAN IDs, and having different PAN coordinators). PAN ID for this PAN (these PANs where applicable) SHOULD be chosen according to [802.15.4].

Current version of SADLP-802.15.4 doesn’t use beacons. I.e. the 802.15.4 PAN is nonbeacon-enabled, as defined in [802.15.4].

Non-paired Addressing for IEEE 802.15.4 Buses

Each IEEE 802.15.4 frequency channel on a Device represents a “wireless bus” in terms of SAMP. For “intra-bus address” as a part “non-paired addressing” (as defined in SmartAnthill Mesh Protocol (SAMP)), IEEE 802.15.4 Devices MUST use 64-bit IEEE 802.15.4 extended address as defined in [802.15.4].

Device Discovery and Pairing

For Devices with OtA Pairing (as described in SmartAnthill Pairing), “Device Discovery” procedure described in SmartAnthill Mesh Protocol (SAMP) document is used, with the following clarifications:

  • SAMP “channel scan” for SADLP-IEEE-802-15-4 is performed as follows:
    • an “active scan” as described in [802.15.4] is performed, and a list of candidate channels is obtained
    • for each of candidate channels:
      • “Association” is performed as described in [802.15.4]
      • the first packet as described in SAMP “Device Discovery” procedure is sent by Device
      • if a reply is received indicating that Root is ready to proceed with “pairing” - “pairing” is continued over this channel
        • if “pairing” fails, then the next available “candidate channel” is processed.
        • to handle the situation when “pairing” succeeds, but Device is connected to wrong Central Controller - Device MUST (a) provide a visual indication that it is “paired”, (b) provide a way (such as jumper or button) allowing to drop current “pairing” and continue processing “candidate channels”. In the latter case, Device MUST process remaining candidate channels before re-scanning.
      • if a reply is received with ERROR-CODE = ERROR_NOT_AWAITING_PAIRING, or if there is no reply within 500 msec, “Disassociation” is performed as described in [802.15.4], and the procedure is repeated for the next candidate channel
    • if the list of “candidate channels” is exhausted without “pairing”, the whole “channel scan” is repeated (indefinitely, or with a 5-or-more-minute limit - if the latter, then “not scanning anymore” state MUST be indicated on the Device itself - TODO acceptable ways of doing it, and the scanning MUST be resumed if user initiates “re-pairing” on the Device), starting from an “active scan” as described above

IEEE 802.15.4 MAC Frames

Each of SADLP-802-15-4 upper-layer-protocol packets (usually SAMP packets) is transmitted as 802.15.4 MAC frame (as described in [802.15.4] 5.2.1) with the following field values:

  • Frame Control Field:
    • Frame Type = ‘Data Frame’
    • Security Enabled = false
    • Frame Pending = <depending on more data available; when required so by [802.15.4], shall be set to zero>
    • Acknowledgment Request = false
    • PAN ID Compression = false
    • Destination Addressing Mode = 0b10 (‘16-bit’)
    • Frame Version = 0x01 (‘post-2003 802.15.4’)
    • Source Addressing Mode = 0b00 (‘not present’)
  • Sequence Number Field: current value of macDSN, as specified in [802.15.4]
  • Destination PAN Identifier: 0xffff
  • Destination Address: 0xffff
  • Source PAN Identifier/Source Address: not present
  • Auxiliary Security Header: not present
  • Frame Payload: SADLP payload (TODO: exactly or some massaging is needed?)
  • FCS: 16-bit ITU-T CRC, as specified in [802.15.4]

That is, current version of the SADLP-802-15-4 sends all the data as unacknowledged (acknowledgement is handled by SAMP) insecure (security is provided by SASP) broadcast IEEE 802.15.4 data frame.

Mapping to specific APIs

Mapping to specific APIs implementing IEEE 802.15.4, is beyond the scope of this document. Any implementation which produces MAC frames with the fields above, should be ok.