Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

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 ﬁrmware 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

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
• Deﬁnes 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!)

9.
9
1. LoRaWAN Is An Incomplete Stack
FACTS:
1. LoRaWAN is not a complete ﬁrmware solution
for LoRa-based networks.
2. LoRaWAN only deﬁnes 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
undeﬁned.

10.
10
1. LoRaWAN Is An Incomplete Stack
FACTS:
1. LoRaWAN is not a complete ﬁrmware solution
for LoRa-based networks.
2. LoRaWAN only deﬁnes 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
undeﬁned.
WHAT THIS MEANS TO DEVELOPERS:
1. Developers using LoRaWAN will need to invest in
additional development efforts to complete
endpoint and gateway ﬁrmware functions to
make LoRaWAN “work”.
2. Basic functions like packetization, multicast, and
downlink control are undeﬁned.
3. LoRaWAN lacks a common data representation
model and transport model for applications to use
(typically, this is a ﬁle).

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 conﬁrmation 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 conﬁrmation 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
sufﬁcient error correction to effectively deal
with concurrent channel usage.
4. Testing shows LoRaWAN’s MAC efﬁciency 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
sufﬁcient error correction to effectively deal
with concurrent channel usage.
4. Testing shows LoRaWAN’s MAC efﬁciency 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 deﬁciencies 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 ofﬁce 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 ﬁeld 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 ﬁeld 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”
dataﬂows.
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 Signiﬁcant
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 Signiﬁcant
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 spooﬁng of LoRaWAN endpoints
by hackers is easy, similar to WiFi or ZigBee.
4. Installing a security patch in most cases will be
impossible

24.
24
7. LoRaWAN Does Not Support
Over-the-Air Firmware Updates
FACTS:
1. LoRaWAN’s uplink-centric architecture, lack
of broadcast data ﬂows, low data rates
(<1kbps), and lack of robust two-way comms
makes ﬁrmware updates next to impossible.
WHAT THIS MEANS TO DEVELOPERS:
1. Updating ﬁrmware, 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 modiﬁed 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 ﬁrmware 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 ﬁrmware 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
ﬁrmware 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
ﬁrmware 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 sufﬁcient 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 ﬁrmware, 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 ﬁt this proﬁle should not use LoRaWAN!