LoRaWAN vs Haystack

10,728 views

Published on

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

Published in: Technology
3 Comments
8 Likes
Statistics
Notes
No Downloads
Views
Total views
10,728
On SlideShare
0
From Embeds
0
Number of Embeds
7,577
Actions
Shares
0
Downloads
128
Comments
3
Likes
8
Embeds 0
No embeds

No notes for slide

LoRaWAN vs Haystack

  1. 1. VS. LoRaWAN A presentation from www.haystacktechnologies.com
  2. 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. 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. 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. 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. 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. 7 The Basic Problem With LoRaWAN LoRaWAN is not a serious IoT protocol! (and serious IoT developers should not use LoRaWAN!)
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 28 9. LoRaWAN Does Not Support Roaming FACTS: 1. LoRaWAN does not support roaming between networks.
  29. 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. 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. 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. 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. 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. 34 Here’s A Company With A Serious Stack for LoRa
  35. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×