lorawan vs haystack
TRANSCRIPT
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
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
HybridLPWAN+LAN
HW
FW
HW
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
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
LoRaWANA 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
The Basic Problem With LoRaWAN
LoRaWAN is not a serious IoT protocol!
(and serious IoT developers should not use LoRaWAN!)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
9. LoRaWAN Does Not Support Roaming
FACTS: 1. LoRaWAN does not support roaming
between networks.
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
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
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
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
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
Here’s A Company With A Serious Stack for LoRa
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
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
OSI Layer
7 Application UDP + OIC + NDEF + AllJoyn/OCF
6 Presentation
DASH7 Corelow 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
LPLAN’s Usually OfferTwo 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
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
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 OfferTwo Distinguishing Features
We can bridge the gap between these two classes, to bring us closer to unified connectivity
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
20102005 2015 2020Cellular
Passive RF
WLAN/PAN
IoT/LPWAN
Bluetooth 4.x
CDMA2000 (3G)
GSM 3GLTE 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
NDEF-IoT
20102005 2015 2020Cellular
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 3GLTE 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 MilestonesEra of Internet Feature Integration Era of IoT Feature Integration
TI CC1350 SoC: DASH7+BLE
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 <ENB-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
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
DASH7low power low latency
ad-hoc LAN networking LPWAN networking
MSK Downlink, OFDM uplink
DASH7 + LoRa Device
NDEF + UDP/IP + Custom
DASH7low 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
DASH7low 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
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 PresentationDASH7low 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
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 PresentationDASH7low 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
Haystack: Better Performance
Requirement LoRaWAN Actility Senet Linklabs
Improved Range ❌ ❌ ❌ ❌ ✓Improved Battery Life ❌ ❌ ❌ ❌ ✓
Improved Network Capacity ❌ ❌ ❌ ✓ ✓Improved Latency ❌ ❌ ❌ ✓ ✓
Portable Across Multiple RF Technologies ❌ ❌ ❌ ❌ ✓
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 MulticastData Collection ❌ ❌ ❌ ❌ ✓
NoSQL-like Data Architecture ❌ ❌ ❌ ❌ ✓
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
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
Contact: Patrick Burns [email protected]
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