More details on implementing broadcast/multicast messaging in IoT networking running Haystack + DASH7 networking software. Also implementing CBOR to enable queries over MQTT.

1. More DASH7 with MQTT
Patrick Burns
pat@haystacktechnologies.com

2. DASH7istheOppositeofTCP
DASH7’s networking technology is different than TCP/IP.
DASH7 is designed to handle small data, but lots of devices at the same time.
TCP/IP handles large data, but only between two devices.
2

3. MQTT Handles Connections “One at a Time”
3
• Client connects to MQTT server
(called a “Broker”)
• Client subscribes to some MQTT
“Topics” (these are like feeds).
• When Broker is supplied new
data on a given Topic, it forwards
to all subscribers, one at a time.
Broker
Unsubscribed
Client(s) Subscribed
Client(s)
1. Client publishes on
topic “X” to broker
1
2
3
4
2, 3, 4. Broker forwards Pub (1)
to all clients subscribed to “X”,
… one at a time.

4. DASH7 Handles Connections in Groups
4
• DASH7 devices can do peer-to-
peer, multicast publishing
without a broker.
• QoS is dictated by the manner in
which devices acknowledge
(ACK) the Publisher.
• It’s a lot like peer-to-peer MQTT.
1. Multicast
Publish
2, 3, 4. Synchronized ACKs
2
3
4

5. DASH7 is Like Peer-to-Peer MQTT on a LAN
5
Broker
Unsubscribed
Client(s) Subscribed
Client(s)
1. Client publishes on
topic “X” to broker
1
2
3
4
2, 3, 4. Broker forwards Pub (1)
to all clients subscribed to “X”,
… one at a time.
1. Multicast
Publish
2, 3, 4. Synchronized ACKs
2
3
4

6. A Proxy Can Integrate it with Cloud MQTT
6
Broker
Unsubscribed
Client(s) Subscribed
Client(s)
1. Client publishes on
topic “X” to broker
1
2
3
4
2, 3, 4. Broker forwards Pub (1)
to all clients subscribed to “X”,
… one at a time.
DASH7 WAN/LAN
Prox
• A DASH7-MQTT Proxy can be just an MQTT Client
that has a second interface on a DASH7 WAN or LAN.
• It forwards pub and sub messages.
• Additional sophistication can make it more efficient,
although Topic naming best practices makes a big
improvement with minimal sophistication.

7. DASH7+MQTT Topic Naming Best Practices
7
Keep topic names below 16 chars.
‣ e.g. topic/this_is_too_long
‣ e.g. topic/titl — (ok)
DASH7 devices have limited communication
bandwidth and memory. Queries work fastest on
strings 16 characters or less.
Use Path separators to define hierarchies
based on data latency requirements.
‣ e.g. rt/temp
‣ e.g. noncrit/temp
Here, we have real-time and “non-critical” groups of
temperature sensors. This structure allows the
proxy to be more intelligent.
Wildcards are cool.
‣ e.g. rt/#
‣ e.g. #/temp — (not advisable for std MQTT)
DASH7 querying supports wildcards and other
search features. The second topic will bog down a
normal MQTT network, but a DASH7-MQTT proxy
can actually handle it without problems.
The “ID/“ topic can be used for addressing
‣ e.g. ID/# — (broadcast)
‣ e.g. ID/0790 — (16bit LAN address)
‣ e.g. ID/DA5701A976B31F54 — (MAC)
This is a way to tunnel direct device addressing
through an MQTT proxy. (And yes, wildcards can
be used with partial addressing)

8. Example of MQTT-Tunneled DASH7 Query
8
1. Define topic that will address all the
endpoints you want to query. This example
looks for devices containing real-time
temperature data.
(note: we can set topics any way we want when we write
the system specification).
2. Put a MQTT response params in the
payload, with JSON or CBOR. The
endpoints will publish-back their data on
this topic & QoS.
3. Endpoints with rt/temp data available will
publish it back. Data format is CBOR.
rt/temp
{
“topic”:”hub/rt/temp”,
“qos”:1
}
CBOR examples:
http://cbor.io/tools.html

9. UDP Data Exchange Within MQTT
9
• DASH7 can Publish (and receive) data
over MQTT in a variety of formats.
‣ ALP/NDEF
‣ CBOR
‣ Proprietary Application data
• In all cases, data is binary format.
• ALP is the normal way to frame data.
‣ An ALP frame is shown to the right
‣ More info on specifics:
http://www.indigresso.com/wiki/doku.php?
id=opentag:alpapi
ALP frames are very simple:
‣ Flags (for message fragmentation)
‣ Payload Length (size of data in bytes)
‣ ALP-ID (maps to a UDP destination port)
‣ ALP-CMD (application dependent usage)
‣ Payload is UDP application data
DASH7 supports UDP applications as well as some
UDP-like applications optimized for DASH7.
DASH7-optimized UDP protocols use ALP-CMD to
define protocol functions. Native UDP protocols use
ALP-CMD as the UDP source port number.

10. UDP Data Exchange Within MQTT
10
• Some common UDP Apps
‣ Trivial File Transfer Protocol (TFTP)
‣ Network Time Protocol (NTP)
‣ Lightweight Directory Services Protocol (LDAP)
‣ Constrained Application Protocol (CoAP)
‣ MQTT itself also can work on UDP
• UDP Apps Unique to DASH7
‣ Mode 2 Batch File Protocol
Point-to-Point and Point-to-Multipoint protocol for reading,
writing, or querying data from the filesystem.
(similar to cat & < / > operators in UNIX)
‣ Confit (i.e. “Configure It”)
Point-to-Point and Point-to-Multipoint protocol for
transferring bulk updates, such as Firmware Updates.
Almost identical to TFTP, except it works at very low power
on the device endpoint.
• All of these applications can be tunneled over MQTT, to DASH7!
• You can use MQTT topics to achieve multicast addressing!
• There is a file on the device for storing dynamic CBOR CDDL!