Compares the low power, wide area IoT stack known as LoRaWAN with Haystack's DASH7 stack. Don't implement LoRaWAN until you read this.

1. VS. LoRaWAN
A presentation from www.haystacktechnologies.com

2. 2
up to 30 Miles
Long Range /
“LPWAN”
30 feet 3 miles300 feet
Medium Range
Short Range /
“LPLAN”
NB-IoT
LPWAN’s: The Next IoT Battlespace

3. 3
LPWAN’s Address the Battery-powered IoT
Mains-powered IoT networking has already gone to WiFi.
“All of the easy types IoT integrations have been done already, and they’ve
been done almost entirely with WiFi”
— A major IoT cloud service integration partner
‣ Mains-powered IoT is the tip of the iceberg. Battery-powered is the
part under the water, and WiFi doesn’t address it.
‣ LPWAN is the next area that is being addressed.
‣ Haystack’s DASH7 IoT networking stack is firmware that can be
integrated into any LPWAN.
‣ DASH7-enhanced LPWANs can provide all WAN, LAN, and location-
based features with the kinds of real-time IP and database APIs cloud
& internet developers require.
Mains-Powered
(WiFi) IoT
LPWAN
Hybrid
LPWAN+LAN
HW
FW
HW

4. 4
LoRa - Maybe The Most Talked About LPWAN
Technology Right Now
Description
• Long range, low power radio technology for IoT
devices
Range
• 13 miles line-of-sight,
• 1.2 miles urban non-line-of-sight
Radio frequencies
supported
• 863-870 (EU), 433-434, 902-928 (US), 779-787
(China) (link)
Battery Life • Up to 10 years
Data Rate • Programmable from 0.3 kbps - 50 kbps
Security
• Various, but keys are distributed at point of
manufacture
Standardization • None. Exclusively available via Semtech.
Pricing • ~$4 per chipset
Competitors
• NB-IoT (Qualcomm, et al), Texas Instruments,
Sigfox
Manufacturer • Semtech

5. 5
Description
• Long range, low power radio technology for IoT
devices
Range
• 13 miles line-of-sight,
• 1.2 miles urban non-line-of-sight
Radio frequencies
supported
• 863-870 (EU), 433-434, 902-928 (US), 779-787
(China) (link)
Battery Life • Up to 10 years
Data Rate • Programmable from 0.3 kbps - 50 kbps
Security
• Various, but keys are distributed at point of
manufacture
Standardization • None. Exclusively available via Semtech.
Pricing • ~$4 per chip
Competitors
• NB-IoT (Qualcomm, et al), Texas Instruments,
Sigfox
Manufacturer • Semtech
LoRa - Maybe The Most Talked About LPWAN
Technology Right Now
Endorsed by
Haystack

6. 6
LoRaWAN
A Simple Networking Stack For LoRa
• Simple networking “freeware” for LoRa-based IoT
devices
• Really basic feature set and functionality
• Not the same thing as LoRa, which is only a physical
layer radio technology
• Defines low level Media Access Control and some
Network layer functions, but not an end-to-end
networking solution like WiFi or Bluetooth
• Works exclusively with LoRa chips
• Managed by the LoRa Alliance and sponsored by
Semtech

7. 7
The Basic Problem With LoRaWAN
LoRaWAN is not a serious IoT protocol!
(and serious IoT developers should not use LoRaWAN!)

8. 10 Reasons LoRaWAN
Is Not A Serious IoT Protocol
1. Incomplete networking stack
2. Fundamentally a one-way protocol
3. Network capacity & interference
4. Weak indoor & geolocation features
5. High latency, not real-time
6. Major security and privacy risks
8. No multi-hop, mesh, or P2P
7. No OTA firmware updates
9. No portability to other IoT tech
10. No roaming

9. 9
1. LoRaWAN Is An Incomplete Stack
FACTS:
1. LoRaWAN is not a complete firmware solution
for LoRa-based networks.
2. LoRaWAN only defines the Media Access
Control layer (layer 2 of the OSI model) and
parts of the Networking layer (layer 3).
Remaining Network, Session, Transport,
Presentation, and Application Layers are
undefined.

10. 10
1. LoRaWAN Is An Incomplete Stack
FACTS:
1. LoRaWAN is not a complete firmware solution
for LoRa-based networks.
2. LoRaWAN only defines the Media Access
Control layer (layer 2 of the OSI model) and
parts of the Networking layer (layer 3).
Remaining Network, Session, Transport,
Presentation, and Application Layers are
undefined.
WHAT THIS MEANS TO DEVELOPERS:
1. Developers using LoRaWAN will need to invest in
additional development efforts to complete
endpoint and gateway firmware functions to
make LoRaWAN “work”.
2. Basic functions like packetization, multicast, and
downlink control are undefined.
3. LoRaWAN lacks a common data representation
model and transport model for applications to use
(typically, this is a file).

11. 11
2. LoRaWAN Is Fundamentally
A One-Way Protocol
FACTS:
1. LoRaWAN is fundamentally a one-way/
simplex protocol
2. Two-way/duplex functionality is theoretically
possible, albeit at huge and impractical
costs.
3. A base station can respond to an uplink
message, but there is no a way to push data
down from the internet to the endpoints.
4. If a base station is transmitting while an
endpoint is transmitting, the endpoint’s
message will usually be lost.

12. 12
2. LoRaWAN Is Fundamentally
A One-Way Protocol
FACTS:
1. LoRaWAN is fundamentally a one-way/
simplex protocol
2. Two-way/duplex functionality is theoretically
possible, albeit at huge and impractical
costs.
3. A base station can respond to an uplink
message, but there is no a way to push data
down from the internet to the endpoints.
4. If a base station is transmitting while an
endpoint is transmitting, the endpoint’s
message will usually be lost.
WHAT THIS MEANS TO DEVELOPERS:
1. LoRaWAN’s claims about being a fully bi-
directional protocol are misleading at best.
2. There is no confirmation that a message
transmitted by an endpoint has reached the
gateway. Assume that ~80% (!) will be lost in a
fully-utilized network.
3. Use cases should be limited to “paging”
applications where receipt of the message is non-
mission-critical and confirmation of message
receipt is not mandatory. Using LoRaWAN to turn
lights on or off, for example, would have a high
probability of failure.
4. Internet-based applications that want to interact
with LoRa endpoint are not supported.

13. 13
3. LoRaWAN Has Huge Capacity
and Interference Challenges
FACTS:
1. LoRaWAN was designed with a 1% duty cycle
limitation for both endpoints and gateways.
2. When a gateway is transmitting, all gateway
receive channels are disabled, thereby making
it half-duplex only.
3. LoRaWAN utilizes a crude form of time domain
synchronization and framing and lacks
sufficient error correction to effectively deal
with concurrent channel usage.
4. Testing shows LoRaWAN’s MAC efficiency is
only in the 18-22% range.
5. Semtech’s LoRa PHY implementation offers no
model for standards’ compliant listen-before-
talk.

14. 14
3. LoRaWAN Has Huge Capacity
and Interference Challenges
FACTS:
1. LoRaWAN was designed with a 1% duty cycle
limitation for both endpoints and gateways.
2. When a gateway is transmitting, all gateway
receive channels are disabled, thereby making
it half-duplex only.
3. LoRaWAN utilizes a crude form of time domain
synchronization and framing and lacks
sufficient error correction to effectively deal
with concurrent channel usage.
4. Testing shows LoRaWAN’s MAC efficiency is
only in the 18-22% range.
5. Semtech’s LoRa PHY implementation offers no
model for standards’ compliant listen-before-
talk.
WHAT THIS MEANS TO DEVELOPERS:
1. The one-way “Aloha” MAC’s deficiencies in
network capacity are exacerbated by the 1% duty
limitation, practically, as endpoints must
frequently re-transmit messages in order to
ensure receipt.
2. EU regulations allowing greater duty cycle require
listen-before-talk features, but these are not
available to LoRaWAN developers.
3. LoRa and non-LoRa networks deployed near
competing LoRa networks are likely to experience
collisions and other failures. It is hard to prevent
LoRaWAN “bandwidth hogs”.

15. 15
4. Indoor Location with LoRaWAN is
Weak or Non-existent
FACTS:
1. Because LoRaWAN is not a fully two-way
or real-time protocol, indoor location
cannot be determined with any practical
precision.
2. Querying the location of a LoRaWAN
endpoint in real-time is not supported.

16. 16
4. Indoor Location with LoRaWAN is
Weak or Non-existent
FACTS:
1. Because LoRaWAN is not a fully two-way
or real-time protocol, indoor location
cannot be determined with any practical
precision.
2. Querying the location of a LoRaWAN
endpoint in real-time is not supported.
WHAT THIS MEANS TO DEVELOPERS:
1. LoRaWAN’s claims about geolocation or even
indoor location are misleading at best.
2. Use cases requiring precise location in a
warehouse or office building, where GPS is
unavailable, should not rely on LoRaWAN.
3. The lack of a real-time query feature makes RSSI-
based geolocation problematic in nearly all use
cases.

17. 17
4a. Outdoor Location with LoRaWAN is
Weak Without GPS
FACTS:
1. LoRaWAN lacks a data field describing
transmit power from the endpoint, thus
preventing RSSI-based location over adaptive
power channels.
2. LoRa’s bandwidth is only 125-500 kHz, and
the modulation operates at low SNR. Time
based location models (e.g. TOF, TDOA),
have precision directly correlated to
bandwidth and SNR.
3. LoRa receivers have excellent multipath
robustness, which is a problem as the
bandwidth-time window is at best 2µs. A
multipath signal can travel 600m in 2µs, and
therefore interfere with location estimation.

18. 18
4a. Outdoor Location with LoRaWAN is
Weak Without GPS
FACTS:
1. LoRaWAN lacks a data field describing
transmit power from the endpoint, thus
preventing RSSI-based location over adaptive
power channels.
2. LoRa’s bandwidth is only 125-500 kHz, and
the modulation operates at low SNR. Time
based location models (e.g. TOF, TDOA),
have precision directly correlated to
bandwidth and SNR.
3. LoRa receivers have excellent multipath
robustness, which is a problem as the
bandwidth-time window is at best 2µs. A
multipath signal can travel 600m in 2µs, and
therefore interfere with location estimation.
WHAT THIS MEANS TO DEVELOPERS:
1. LoRaWAN location resolution is similar to that
experienced by GPRS systems, which as a rule of
thumb is 1/4 the cell-cell distance. This could be
hundreds of meters.
2. If you use LoRaWAN for tracking things outdoors,
accurately you must use GPS + results will not be
real-time + could have latency of many minutes.
3. The LoRa chipset is quite large, and it requires a
lot of external passives. Optimized SiP’s are in the
region of 11x17x1mm. In some devices, there
isn’t room for an additional GPS chipset.

19. 19
5. LoRaWAN is Not Real-Time
FACTS:
1. LoRaWAN cannot support “pull” type
communication from gateway to
endpoint. Endpoint initiates all
communication.
2. Responses from Gateway to Endpoint
are extremely limited; there are just two
short opportunities per cycle, and
communication is point-to-point.
3. The minimum network latency (cycle) is
128s, even for alerts.

20. 20
5. LoRaWAN is Not Real-Time
FACTS:
1. LoRaWAN cannot support “pull” type
communication from gateway to
endpoint. Endpoint initiates all
communication.
2. Responses from Gateway to Endpoint
are extremely limited; there are just two
short opportunities per cycle, and
communication is point-to-point.
3. The minimum network latency (cycle) is
128s, even for alerts.
WHAT THIS MEANS TO DEVELOPERS:
1. Real-time applications like indoor location are not
feasible with such high latencies.
2. Exchanging data with moving objects (roaming) is
not feasible due to latency issues or lack of “pull”
dataflows.
3. If your use case requires the ability to transmit
“live” sensor data, LoRaWAN is a poor choice.
4. If your use case includes querying the status or
sensor log of an individual endpoint(s), LoRaWAN
is a poor choice.

21. 21
6. LoRaWAN Has Significant
Security and Privacy Risks
FACTS:
1. Public key handshaking cannot be
executed safely via LoRaWAN due to
networking limitations.
2. All encryption is handled using static keys,
such as SIM cards.
3. LoRaWAN beacon mode is easily detected
4. Security patches cannot be transmitted
over the air, creating potentially huge
vulnerabilities
5. LoRa and LoRaWAN are a new, but they
have already been fully reverse engineered
and published as open source GNU radio
software.

22. 22
6. LoRaWAN Has Significant
Security and Privacy Risks
FACTS:
1. Public key handshaking cannot be
executed safely via LoRaWAN due to
networking limitations.
2. All encryption is handled using static keys,
such as SIM cards.
3. LoRaWAN beacon mode is easily detected
4. Security patches cannot be transmitted
over the air, creating potentially huge
vulnerabilities
5. LoRa and LoRaWAN are a new, but they
have already been fully reverse engineered
and published as open source GNU radio
software.
WHAT THIS MEANS TO DEVELOPERS:
1. Public key cryptography should not be
implemented using LoRaWAN
2. LoRaWAN recommends SIM cards to provision
secure codes for private key crypto. This is neither
cost effective nor especially secure for IoT use-
cases, where physical security is rare.
3. Discovery and spoofing of LoRaWAN endpoints
by hackers is easy, similar to WiFi or ZigBee.
4. Installing a security patch in most cases will be
impossible

23. 23
7. LoRaWAN Does Not Support
Over-the-Air Firmware Updates
FACTS:
1. LoRaWAN’s uplink-centric architecture, lack
of broadcast data flows, low data rates
(<1kbps), and lack of robust two-way comms
makes firmware updates next to impossible.

24. 24
7. LoRaWAN Does Not Support
Over-the-Air Firmware Updates
FACTS:
1. LoRaWAN’s uplink-centric architecture, lack
of broadcast data flows, low data rates
(<1kbps), and lack of robust two-way comms
makes firmware updates next to impossible.
WHAT THIS MEANS TO DEVELOPERS:
1. Updating firmware, patching bugs, or security
holes requires manually and physically connecting
with each endpoint, a hugely time intensive and
impractical endeavor that in most cases will not be
supported
2. If LoRaWAN were modified to provide OTA FW
capabilities, its lack of key exchange features
leaves to door open to worms and bot-net
malware, as recently evidenced in Phillips Hue
lightbulbs.
3. The lack of OTA security updates should be a deal
killer for most developers.

25. 25
Additional Notes On LoRaWAN Security
1. It is clear that LoRaWAN was not designed with security or privacy as a serious
requirement. This should give pause to any serious IoT developer.
2. The importance of the ability to patch firmware with over-the-air updates cannot be
overstated. If a security vulnerability is detected in your LoRaWAN device, in most
cases there will be no practical way to install a patch.
3. It may be theoretically possible to push a firmware update over the air using
LoRaWAN, but at an excruciatingly slow pace and with security risks comparable to
the Phillips Hue lightbulb debacle. Serious developers will not expect to attempt OTA
firmware updates with LoRaWAN.
4. It is theoretically possible to support public key encryption via LoRaWAN using a SIM,
though the ease of taking physical possession of the endpoint or SIM renders this
security moot for IoT.

26. 26
8. LoRaWAN Does Not Support Multi-hop,
Mesh, or P2P Networking
FACTS:
1. LoRaWAN does not support multi-hop
networking
2. LoRaWAN does not support mesh networking
3. LoRaWAN does not support P2P networking.
4. LoRaWAN’s Gateway MAC is actually
implemented in the cloud.

27. 27
8. LoRaWAN Does Not Support Multi-hop,
Mesh, or P2P Networking
FACTS:
1. LoRaWAN does not support multi-hop
networking
2. LoRaWAN does not support mesh networking
3. LoRaWAN does not support P2P networking.
4. LoRaWAN’s Gateway MAC is actually
implemented in the cloud.
WHAT THIS MEANS TO DEVELOPERS:
1. All LoRaWAN messages are routed through a
gateway.
2. With a cloud-based MAC, adding MAC-based
features or networking improvements requires a
serious architectural overhaul.
3. Extending the range of LoRaWAN via endpoints
that multi-hop or mesh is not supported
4. Associating a LoRaWAN endpoint with another
LoRaWAN endpoint is not supported.

28. 28
9. LoRaWAN Does Not Support Roaming
FACTS:
1. LoRaWAN does not support roaming
between networks.

29. 29
9. LoRaWAN Does Not Support Roaming
FACTS:
1. LoRaWAN does not support roaming
between networks.
WHAT THIS MEANS TO DEVELOPERS:
1. Roaming is currently being addressed through the
use of a third party SIM card
2. Provisioning and programming individual
endpoints with SIM cards is impractical for most
IoT developers.

30. 30
10. LoRaWAN Is Not Portable to
Other Wireless Technologies
FACTS:
1. LoRaWAN is designed to work exclusively
on Semtech’s LoRa radios. NB-IoT, SigFox,
and new radio technologies (e.g. from Texas
Instruments) are not supported.

31. 31
10. LoRaWAN Is Not Portable to
Other Wireless Technologies
FACTS:
1. LoRaWAN is designed to work exclusively
on Semtech’s LoRa radios. NB-IoT, SigFox,
and new radio technologies (e.g. from Texas
Instruments) are not supported.
WHAT THIS MEANS TO DEVELOPERS:
1. You will need to support and maintain multiple
firmware stacks if you choose to support other RF
technologies besides LoRa
2. LoRaWAN leaves you locked-in exclusively to
Semtech for future hardware options
3. Interoperability with non-LoRa LPWAN devices
will only be possible at the gateway

32. 32
LoRaWAN Is Not A Serious IoT Protocol!
LoRaWAN may be sufficient for showing
a simple proof of concept, but it was not
designed with 21st century IoT
requirements in mind.

33. 33
So Why Are Some Developers Still Using
LoRaWAN?
LoRa might be OK for hobbyists and others who accept a network with all of the
following:
1. Simple endpoints that only transmit occasionally and no need for real-time data
2. No ability to update firmware, zero concerns about IoT security
3. Endpoint transmit failure rate of between 5-80%
4. Limited or no ability to control or query the endpoint
5. Small deployments of a few dozen endpoints per gateway
6. Use of multiple gateways to cover each node
7. Exclusive commitment to Semtech LoRa as a LPWAN radio platform
Use cases which don’t fit this profile should not use LoRaWAN!

34. 34
Here’s A Company With A Serious Stack for LoRa

35. 35
Haystack Solves For All LoRaWAN’s Weaknesses
1. Incomplete networking stack
2. Fundamentally a one-way protocol
3. Significant capacity and interference issues
4. Geo and indoor location is weak or non-existent
5. Not real-time and has huge latency risks
6. Significant security and privacy risks
7. No multi-hop, mesh, or P2P networking
8. No over-the-air firmware updates
9. No roaming
10. Not portable to other wireless IoT technologies
LoRaWAN

36. 36
Haystack Solves For All LoRaWAN’s Weaknesses
1. Incomplete networking stack
2. Fundamentally a one-way protocol
3. Significant capacity and interference issues
4. Geo and indoor location is weak or non-existent
5. Not real-time and has huge latency risks
6. Significant security and privacy risks
7. No multi-hop, mesh, or P2P networking
8. No over-the-air firmware updates
9. No roaming
10. Not portable to other wireless IoT technologies
More information: http://bit.ly/2hC9COL
Complete networking stack (layers 2-6)
Fully bi-directional two-way protocol
Supports thousands of endpoints per gateway
Excellent geo and indoor location
Real-time/very low latency
Good security and privacy
Multi-hop, mesh, and P2P networking support
Over-the-air firmware updates
Roaming
Portable to other wireless IoT technologies
LoRaWAN Haystack/DASH7

37. 37
OSI Layer
7 Application UDP + OIC + NDEF + AllJoyn/OCF
6 Presentation
DASH7 Core
low power
low latency
low cost
5 Session
4 Transport
3 Network
2 Data Link
1 Physical LoRa, NB-IoT, Others
Hold On … There Already Is a
Full Stack for LPWAN’s
‣ Works over LoRa and
other LPWAN PHY’s
‣ Designed specifically
for modern
sub-1GHz wireless
sensor networks
‣ Layers 2-6 are fully
defined, fully QA’d,
now available
‣ Fully bi-directional
‣ Supports multiple
application layer
options including
IPv6
‣ Extensive feature set
and capabilities
‣ The most complete,
end-to-end solution
available for
LPWAN’s
Technical Features

38. 38
LPLAN’s Usually Offer
Two Distinguishing Features
Requirement LPLAN LPWAN
Multi-year Battery Life
✓ ✓
Low Cost (sub-$5) Devices
✓ ✓
Indoor Location Precision
✓ ❌
Mesh Networking
✓ ❌
(ZigBee, Thread, 6lowPAN, et al) (LoRaWAN, SigFox, NB-IoT)

39. 39
Requirement LPLAN LPWAN
Multi-year Battery Life
✓ ✓
Low Cost (sub-$5) Devices
✓ ✓
Indoor Location Precision
✓ ❌
Mesh Networking
✓ ❌
(ZigBee, Thread, 6lowPAN, et al)
LPLAN’s Usually Offer
Two Distinguishing Features
By solving for these two features,
LPWAN’s can substitute for most or
all of today’s LPLAN technologies
(LoRaWAN, SigFox, NB-IoT)

40. 40
Requirement LPLAN LPWAN
Multi-year Battery Life
✓ ✓
Low Cost (sub-$5) Devices
✓ ✓
Indoor Location Precision
✓ ❌
Mesh Networking
✓ ❌
(ZigBee, Thread, 6lowPAN, et al) (LoRaWAN, SigFox, NB-IoT)
LPLAN’s Usually Offer
Two Distinguishing Features
We can bridge the gap between
these two classes, to bring us
closer to unified connectivity

41. OSI Layer
7 Application AllJoyn, Others AllJoyn, Others AllJoyn, Others AllJoyn, Others AllJoyn, Others AllJoyn, Others
6 Presentation
5 Session Partial Definition
4 Transport Partial Definition
3 Network Partial Definition
2 Data Link Partial Definition
1
Physical
“PHY”
LoRa @
169 - 960 MHz
Various @
315 - 930 MHz
Various LTE
Bands
Various @ 27 -
1025 MHz
RPMA @ 2.4 GHz
SigFox @ 900,
868 MHz
Example LPWAN PHY’s
41
NB-IoT
Historic LPWAN/NB-IoT Opportunity
Most entrants come from the semiconductor industry and need a common stack

42. 20102005 2015 2020
Cellular
Passive RF
WLAN/PAN
IoT/LPWAN
Bluetooth 4.x
CDMA2000 (3G)
GSM 3G
LTE 3-4G
BLE
DASH7
CDMA & GSM to
LTE
NB-IoT
ISO 14443
ISO 15693 / ISO 18000-3
NFC
Notable Technology Integrations: 2000-2020
Bluetooth
to BLE
NDEF (data)
to DASH7
ISO RFID
to NFC
LoRaDASH7 to LoRa &
NB-IoT PHYs
NDEF-IoT
NDEF-IoT:
DASH7+NFC

43. NDEF-IoT
20102005 2015 2020
Cellular
Passive RF
WLAN/PAN
WSN/IoT
Bluetooth 1.x
WiFi b WiFi g WiFi n WiFi ac
Bluetooth 2.x Bluetooth 3.x Bluetooth 4.x
CdmaOne (2G) CDMA2000 (3G)
GSM 2G GSM 3G
LTE 3-4G
BLE
ZigBee & 802.15.4 Diaspora
ISO 18000-7 [Mode 1] DASH7
LoRa
LTE, WiFi, BT,
GPS SoC
WiFi, BT SoC
[Projected]
NB-IoT added to
4G SoC
NB-IoT
ISO 14443
ISO 15693 / ISO 18000-3
NFC
[Projected]
DASH7, NFC SoC
Total Integration Picture, With SoC Milestones
Era of Internet Feature Integration Era of IoT Feature Integration
TI CC1350 SoC:
DASH7+BLE

44. NDEF-IoT
2015 2020
Cellular
Passive RF
WLAN/PAN
WSN/IoT
LTE 3-4G
BLE
DASH7
LoRa
[Projected]
NB-IoT added to
4G SoC
NB-IoT
NFC
[Projected]
DASH7, NFC SoC
DASH7 Integration Roadmap: Present-2020
TI CC1350 SoC:
DASH7+BLE
In an IoT market experiencing a glut of both standardized
and proprietary PHY layer options intended for PAN,
LAN, and WAN usage, DASH7 uniquely supplies a
firmware-based networking stack that meets all
requirements of the disparate PHYs yet manages to
provide a universal data and API layer via familiar IPv6
and NoSQL database paradigms.
Integration 1: DASH7 + LoRaWAN over LoRa
Currently available via Semtech SX127x transceiver. Validating with
STM32L LoRaWAN reference platform, as well as TI CC13xx.
Integration 2: DASH7 over BLE & 802.15.4g+
Currently in development via TI CC1350 SoC
Integration 3: DASH7 over NB-IoT &LTE
NB-IoT Draft spec validated, waiting for prototype semiconductors to
emerge.
Integration 4: DASH7 + NFC Hybrid
Technology and strategy validated, two-chip prototype proven, waiting
for prototype SoC.

45. 45
OSI Layer
7 Application
6 Presentation
5 Session
4 Transport
3 Network
2 Data Link
1 Physical
DASH7 + NB-IoT Device
NDEF + UDP/IP + Custom
DASH7
low power
low latency
ad-hoc LAN networking
LPWAN networking
MSK Downlink, OFDM uplink
DASH7 + LoRa Device
NDEF + UDP/IP + Custom
DASH7
low power
low latency
ad-hoc LAN
LoRaWAN
low power
high latency
cellular WAN
+ Adaptive RS Encoding
LoRa CSS
DASH7 can operate on the LoRa radio
PHY and also in parallel with the
LoRaWAN stack. In this integration,
DASH7 adds important bursty
c o m m u n i c a t i o n f e a t u r e s t o
LoRaWAN, much the way data
features were added to 3G cellular.
The emerging NB-IoT PHY and Data
Link specification is an ideal fit for the
DASH7 stack. DASH7 networking
already supports all the requirements
of the NB-IoT draft spec, and it is
capable of providing LPWAN and
LAN features to NB-IoT.
NDEF-IoT: DASH7+NFC
NDEF + UDP/IP + Custom
DASH7
low power
low latency
ad-hoc LAN
LPWAN
NFC
low power
low latency
proximity
RFID
Hybrid PHY
DASH7 is designed to work in a
hybrid environment with NFC.
Extending an NFC device to support
DASH7 was an early design goal.
NFC’s proximity communication is
complimented by DASH7’s long
range networking capabilities.
DASH7 Total Integration Strategy: Highlights

46. 46
Haystack Endpoints with LoRa
LoRa and LoRaWAN can operate concurrently and on the same chip with DASH7
Semtech LoRa
Transceiver
Compact,
low cost,
low-power
WAN/LAN
nodes
OSI Layer
7 Application AllJoyn + OIC + NDEF + UDP
6 Presentation
DASH7
low power
low latency
ad-hoc star
LoRaWAN
low power
high latency
cellular WAN
5 Session
4 Transport
3 Network
2 Data Link + Adaptive RS Encoding
1 Physical LoRa CSS
The DASH7 stack can run
concurrently with LoRaWAN, on the
same hardware, allowing compliant
LoRaWAN interoperation alongside
higher-throughput, low latency
Haystack DASH7 LAN usage.

47. 47
Haystack Endpoints with LoRa
LoRa and LoRaWAN can operate concurrently and on the same chip with DASH7
Semtech LoRa
Transceiver
Compact,
low cost,
low-power
WAN/LAN
nodes
OSI Layer
7 Application AllJoyn + OIC + NDEF + UDP
6 Presentation
DASH7
low power
low latency
ad-hoc star
LoRaWAN
low power
high latency
cellular WAN
5 Session
4 Transport
3 Network
2 Data Link + Adaptive RS Encoding
1 Physical LoRa CSS
LoRaWAN developers:
You can add DASH7 to
LoRaWAN devices and run
both stacks side-by-side.

48. 48
Haystack: Better Performance
Requirement LoRaWAN Actility Senet Linklabs
Improved Range
❌ ❌ ❌ ❌ ✓
Improved Battery Life
❌ ❌ ❌ ❌ ✓
Improved Network Capacity
❌ ❌ ❌ ✓ ✓
Improved Latency
❌ ❌ ❌ ✓ ✓
Portable Across Multiple RF
Technologies ❌ ❌ ❌ ❌ ✓

49. 49
Haystack: Data Features for
Internet Data Flows
Requirement LoRaWAN Actility Senet Linklabs
Support for files & privileges
❌ ❌ ❌ ❌ ✓
Arbitrated, Acknowledged,
High-Efficiency Bursty MAC ❌ ❌ ❌ ❌ ✓
Query-Driven Multicast
Data Collection ❌ ❌ ❌ ❌ ✓
NoSQL-like Data Architecture
❌ ❌ ❌ ❌ ✓

50. 50
Haystack: Better Security Roadmap
Requirement LoRaWAN Actility Senet Linklabs
Listen-before-talk “stealth” mode
❌ ❌ ❌ ❌ ✓
Support for Public-Key Exchange
❌ ❌ ❌ ❌ ✓
Streaming AES
Cryptographic Ciphering ❌ ❌ ❌ ❌ ✓
Encrypted and Tokenized
MAC Addressing ❌ ❌ ❌ ❌ ✓
Over-the-air Security Patches
❌ ❌ ❌ ✓ ✓

51. 51
Haystack: Better Developer Options
Requirement LoRaWAN Actility Senet Linklabs
Communication model supports
REST-style applications ❌ ❌ ❌ ❌ ✓
Data architecture supports caching
and proxying at edge ❌ ❌ ❌ ❌ ✓
Supports Real-Time Indoor
Location to 1 meter precision ❌ ❌ ❌ ❌ ✓
Roaming Between Gateways
❌ ❌ ❌ ✓ ✓
Compiles into <30KB
❌ ❌ ❌ ✓ ✓

52. 52
Contact:
Patrick Burns
pat@haystacktechnologies.com
More Resources:
• www.haystacktechnologies.com
•The Indoor-Outdoor IoT http://bit.ly/2b65gRQ
•The IoT Hunger Games http://bit.ly/1IkYRtO
•Disrupting the IoT http://bit.ly/2cHRXFH
•Haystack’s open source firmware stack: http://bit.ly/
1p5OjJg