This post was originally published on Mbed Developer Blog.

On Wednesday Arm and The Things Network hosted two webinars on getting started with LoRa and LoRaWAN. Over 700 people joined the webinar, but if you missed it, the recording is available here.

That LoRa is a popular subject was much reflected in the Q&A; we received far more questions than we could handle during the webinar. So in this blog post, Jan Jongboom and Johan Stokking are answering as many as possible.

Where can I find the presentation??

The slides are available here, the presentation is available here.


How can I get a development board?

The L-TEK FF1705, which was used in the webinar, will be available soon from L-TEK. Other development boards you can use (that are available today) are the Multi-Tech mDot EVK and the Multi-Tech xDot. In addition, you can use any Mbed OS 5 compatible development board together with the SX1272 or SX1276 shield.

Note that the L-TEK FF1705 hardware design is open source. The design files are in the Mbed HDK.

What are the approximate prices for LoRa modules and gateways?

You can get LoRa modules (MCU + LoRa radio) from around $11 from various vendors (if you buy a few hundred). The SX1272 (just the radio) is selling for $3.90 on DigiKey for 3,000 or more units.

Gateway prices range from $100 to $2,500, depending on your needs. A cheap (and readily available) way to get started is using an IMST iC880A concentrator board ($140) and a Raspberry Pi. If you need IP67 certification, GPS, cellular backhaul, etc. the price goes up.

When will the Mbed LoRaWAN stack be released?

The pull request was opened on November 27th, and we aim to release this in Mbed OS 5.8 - around February 2018.

Does the Mbed library support OTA?

All Mbed libraries for LoRa (regardless of vendor) support both ABP and OTA activation. We strongly recommend OTA, as it’s more secure.

Do you see other vendors - for LoRa radios - coming except Semtech?

The LoRa radio IP has been licensed to ST and Microchip. We expect them to come out with integrated SoCs at some point.

Can I assume that a device needs different radios as you move from the EU to the USA?

Yes. 868 MHz radio for EU, 915 MHz for US. Theoretically someone could make a radio that spans both the 868 and 915 MHz bands, but dual FCC and EC certification are incompatible for LoRa radios.

How is the gateway connected to the network?

Over any IP backhaul. This can be Ethernet, Wi-Fi or 4G.

We recommend not using 3G for LoRaWAN backhaul, as the default RX1 window occurs one second after a TX window, and 3G latency can make you miss this window.

Are there any LoRaWAN transmission test results for a wide-temperature environment? For example from -40C to 85C?

I’m not sure about transmission tests, but according to the SX1272 datasheet (section 2.2), the absolute maximum temperature rating is from -55C to +115C. Of course this is just the radio; the rest of your components also needs to work in these conditions.

Do you see prices coming down significantly over the next two years? Particularly in outdoor IP67 rated gateways?

Prices are already coming down. Three years ago the cheapest LoRa gateway was $1,500. A year ago it was $500, and now we’re down to less than $100 for indoor gateways. We expect new integrated gateways at less than $50 to become more available in the coming year.

Do you know where I can buy an SX1308 Picocell?

Right now the only way to get one of the new picocells is directly through Semtech; they’re not available to the general public yet.

What gateway/antenna etc?

For development purposes, a gateway with good availability is the MultiTech Conduit with a 915 or 868 mCard. The Things Gateway will ship globally from January 2018 at a lower price.
For deployment, there are numerous options: for large scale indoor deployments, besides the Conduit and The Things Gateway, the Kerlink iFemtocell, Tektelic Pico, for outdoor also MultiTech’s, Kerlink’s, Gemtek’s, Tektelic’s, Cisco’s, and so on. Often, you can wire an outdoor antenna to an indoor gateway too.

Note that there are limitations on the maximum antenna gain in many locations.

Can existing WiFi routers be modified to function as LoRa gateways, or will dual-band systems appear?

WiFi routers cannot be modified to function as a LoRa gateway because their radios use different frequencies; they also often perform hardware modulation specific to WiFi. But yes, we already see dual-band systems appearing; Comcast is adding LoRa gateway chips to their set-top boxes in the USA.

Does the MultiTech Conduit have a backhaul for 3G?

Yes, Multi-Tech Conduits are available with 4G, 3G or no cellular backhaul. See the product page.

Is there a version of the L-TEK board with a module that supports US frequency plan?

Yes, there will be both US915 and EU868 versions of the L-TEK FF1705.


How fast can a LoRaWAN device move and still be able to communicate with a gateway?

For the PHY layer, this depends on the spread factor that you use. If the coherence time of the LoRa signal is smaller than the symbol time of the LoRa signal, then you’ll see high packet loss. According to this paper this happens at ~40 km/h for SF12, and at ~160 km/h for SF7.

On the MAC layer you can run into issues when using Adaptive Data Rating (ADR) with moving devices. The network cannot reliably detect a good data rate for the device while it’s on the move (as this is not re-negotiated in every message). It’s better to use a custom algorithm for changing the data rate based on the RSSI and SNR of received messages on the end-device.

What’s the highest throughput available?

The highest throughput in an EU868 plan is 11 kbps (SF7 125 kHz), and in a US915 plan 12.5 kbps (SF8 500 kHz).

What is the maximum number of devices in a real scenario. For example, if I have a single gateway, what would be the maximum number of devices that can send a small packet five times an hour?

It’s hard to determine this as it’s very dependent on the data rates that the devices use. A typical LoRa gateway can demodulate eight messages at the same time (on eight different channels). If we assume a one second air time per message (which is probably higher than you’d see in real life), perfect timing distribution, and perfect channel distribution, we’ll see (3,600 * 8 = 28,800) messages an hour, which is 5,760 devices.

Having a higher data rate (lower spreading factor) helps tremendously with cell capacity. Air time for a message on SF7 is under 100 ms. Adaptive Data Rating (ADR) helps here, as it can optimize network load by switching devices to the optimal spreading factor.

What can you say about LoRa 2.4GHz?

Very interesting stuff! There’s nothing that ties LoRa modulation specifically to the sub-GHz spectrum, so we’re very interested to see how this will work in 2.4 GHz. The big advantage of 2.4 GHz over sub-GHz is that it works everywhere, and there’s no regional band differences. In addition, maximum TX power is higher. The downside is that path loss in 2.4 GHz is higher (6-10 dBM over 900 MHz per kilometer), and the band is a lot busier.

What’s nice about the SX1280 chip is BLE PHY compatibility, so you can have a single chip handling both BLE and LoRa. That’s pretty cool. Will have to see how it holds up, but for smart city deployments under 1 km this could be very nice.

What about LoRaWAN at 433Mhz for a more global coverage?

LoRa as a modulation is very powerful and does not require usage in the 800-900 bands. Indeed, there are regional parameters defined for the 433 MHz band, but so far there hasn’t been much market demand.

433 MHz would allow for even better range (perhaps 1.5-2 times as much as 915 MHz), due to lower path loss, but this will come at the expense of lower data rates.

Which LoRa frequencies are used in Indonesia?

923-925 MHz, so you could use a US915 radio with a custom channel plan in Indonesia. The LoRa Alliance Technical Committee is expected to release regional parameters for Indonesia in the next few months.

Since vertical transmission into the sky is virtually obstruction/interference-free, is it possible to have a satellite gateway for LoRaWAN?

The range allows for communication between earth and space, but putting a LoRaWAN gateway in space would have a noise floor and number of packets per second that would render the gateway unusable in practice. There are, however, initiatives to bring LoRaWAN gateways to space. Information about this will be disclosed at The Things Conference.

A lot of high buildings have multiple technology antennas on. Have you come across cases where LoRa or Sigfox had transmission/reception blocking issues?

This is where telecom grade gateways make a difference to indoor gateways: they come with captivity filters that strictly filter on specific frequencies. In fact, LoRaWAN networks deployed by telecom operators use the existing antennas for cellular communication. Still, sending and receiving from the same physical location as other signals in the same or very near frequency bands causes more noise. However, for LoRa, this is less of a problem thanks to its robustness to narrowband interference.

Do software-defined radios have a (potential) role in LoRA?

Yes, and there have been demonstrations of this already. What makes it challenging are the current price and intellectual property rights.

The Things Conference will cover software-defined radio for LoRa.


What is the main difference between LoRaWAN 1.0.x and the newly released LoRaWAN 1.1?

The main differences are security enhancements, the introduction of a Join Server, and the formalization of Class B devices. If you want more information on how these work, Johan hosted a webinar on LoRaWAN 1.1; the video is here.

How many devices can communicate in an area?
Does LoRa have any mechanisms to deal with the hidden node problem, when the number of devices (with similar RSSI) increase?

LoRaWAN devices do not implement any features preventing multiple nodes sending at the same time. For example, there’s no “listen before talk”. To deal with this issue LoRaWAN devices randomly switch through the available channels, and add random timing between messages to prevent devices being synced on frequency, data rate and timing. Also, the LoRaWAN MAC layer allows configuring the end device’s channels, so you can use spreading channels in regions with dozens of channels available, such as the USA, Asia and Australia.

Do end devices automatically connect to a gateway, or do you need to manually select a gateway for each end devices?

In LoRaWAN topology all gateways are transparent: they receive every message from every device (within range) and forward it to the network server. Thus, there’s no binding between the device and the gateway, and no pairing required. Just put down an extra gateway and traffic will be automatically routed through it. Adaptive Data Rating will switch devices that are near your new gateway to a faster data rate.

What is the difference between LoRa and LoRaWAN?

LoRa is really the physical layer, and there are different messaging protocols that exist on top of LoRa. LoRaWAN is the standard messaging protocol defined by the LoRa Alliance. Gateways are simply LoRa gateways: the LoRaWAN stack is implemented in the end device and in the network server; gateways are transparent and only translate LoRa traffic to IP traffic and vice-versa. We recommend using LoRaWAN because there is a wide variety of devices and network servers available, and it’s a feature rich protocol with a built-in MAC layer and security mechanisms.

Are there any equivalent developments on Wake Up Radio (WuR) for LoRaWAN?

End devices can use Class B to sync wake and sleep with the network, by listening to beacons and sleeping between so-called ping slots. These ping slots are windows when the end device wakes up so that the network can send downlink messages.

What is the addressing mechanism? How are devices addressed?

While the device is joining the network it’s addressed using the Application EUI and Device EUI, which are guaranteed to be globally unique. After a device has joined, it receives a LoRaWAN session, which contains a 4-byte device address and is then used for addressing. The device address does not have to be globally unique, and will change between sessions.

Is LoRaWAN suitable for firmware updates for small embedded devices?

Yes, Arm and The Things Network have been working on a multicast firmware update solution over LoRaWAN. This requires standardization of a few new specifications in the LoRa alliance, which we expect to happen in Q1 2018.

An article (and a video) describing the approach is here, and reference firmware is here (based on Mbed OS 5 running on an Arm Cortex-M3 with 32K RAM).

Do I need the CAD mode for low power listening?

CAD mode is useful for point-to-point protocols where you don’t know when the receive window will happen. For LoRaWAN, there is no need for the CAD feature, as you know exactly when the receive window is opened.

Why can’t we use Multi-Tech’s network server?

Multi-Tech’s network server runs directly on the gateway, which is a violation of the principle that gateways are transparent in a LoRaWAN network. Thus, using the Multi-Tech network server is fine for prototyping or demo purposes, but not for a proper scalable LoRaWAN deployment.

Can you describe the setup that they used to achieve the 700km test?

Please see here for the article where the setup is described. You can also find raw datasets there.

Can LoRa devices communicate without a gateway, using peer-to-peer to another LoRa device?

Not if you’re using LoRaWAN, which uses a star-of-stars topology in which the gateway is a transparent bridge and there is no peer-to-peer communication between nodes.

If you’re not using LoRaWAN, but just the LoRa PHY, you can do peer-to-peer communication, as it’s just radio. Here’s a simple Mbed ping-pong application using two SX1276 modules.

Please can you expand on the Amsterdam boat sensor? For example, does the radio transmitter works even though it’s wet? What hardware was used?

The boat sensor was a very simple proof of concept, which detected water by measuring the current with a few wires. There are various IP65 and IP67 LoRaWAN sensors on the market nowadays; antennas can easily be integrated in a weatherproof case.

Is the LoRa FOTA done from the gateway or from the cloud?

From an update server running on top of the application server. The gateway is transparent in a typical LoRaWAN network topology.

Which type of class is best for a real-time application scenario like a vehicle tracking system?

If the data flow is primarily from devices to the network, then LoRaWAN Class A works fine. However, for real-time applications, LoRa might not be the right choice: the best you can get is a message every seven seconds (on SF7, 125 KHz) as you have to adhere to the 1% duty cycle. In addition you’re susceptible to non-guaranteed Quality of Service, and. So for real-time applications, cellular is a better choice.

With LoRaWAN Class C it sounds like you might be better off with a different technology, is that correct?

Not really. You lose the low-powered nature of LoRa, but you maintain the long range (with good link budget both ways) in the unlicensed spectrum. On low spreading factors LoRa can outperform 4G in range.

In addition, we see Class C as a complimentary - temporary - mode that devices can switch to whenever they need to receive large blocks of data, such as a multicast firmware update.


How does LoRaWAN deal with security?

LoRaWAN uses AES 128-bit keys for message integrity code (CMAC) and encryption of application payload (ECB). There are two session keys in LoRaWAN 1.0.x and four in LoRaWAN 1.1, which are issued by a trusted third party Join Server (optional). The network server only works with the network session keys and cannot see application payload nor derive security keys when working with a trusted third party Join Server. See the LoRaWAN 1.1 specification and back-end interfaces document.

Through these keys, LoRaWAN provides message level integrity and payload encryption with AES 128-bit keys on two levels: the network and the application level. LoRaWAN 1.0.x had some security vulnerabilities that have been addressed with LoRaWAN 1.1. See more information about security in LoRaWAN here.

During the demo two keys were entered in plain text - are these a security risk?

Yes, absolutely. The Application Key is a Pre-Shared Key (PSK) that needs to be kept secret, as it’s used to do the initial authentication with the network (in return for session keys). Typically you’d inject the keys in a factory or during distribution in a trusted domain of control or in a secure element. But for development you can just put them in firmware, which is what we did in the demo.

What type of key management is recommended?

The recommended way to store keys is with a secure element in the end device. Various device makers in the LoRa Alliance are currently working on this, including Gemalto and ST. Since security in LoRaWAN uses symmetric root keys, we recommend using a trusted third party Join Server as well.

Could you give more details on the security suites used for message confidentiality and integrity?

The message integrity code (MIC) is calculated through AES 128-bit CMAC (RFC4493). This MIC is appended to each message and both the end device and the network server verify message integrity using the network session key. See the LoRaWAN specification for more information.

What’s the AppEUI for, and how does its usage change in LoRaWAN 1.1?

LoRaWAN 1.1 uses JoinEUI instead of AppEUI. The AppEUI was typically issued by the device maker, while the JoinEUI will be issued by the Join Server,. Ideally, the device maker provisions end devices securely on a trusted third party Join Server; the JoinEUI typically identifies a batch of end devices. The owner of the end devices then configures the network server to use. So, when a network server receives a join request from a device, it contacts the Join Server based on the JoinEUI. The Join Server sends session keys only to the network server that is configured by the owner of the devices.

LoRa vs. other technologies

What technology will stay in the future when the LTE NB-IoT and LTE-M1 have been introduced?

LoRaWAN and licensed spectrum narrowband technology (NB-IoT and LTE-M1) will each serve their purpose. LoRaWAN allows setting up private networks with full control over the infrastructure and coverage. It should also be cheapere, because there is no need for revenue streams that cover the billions of investments in licensed bands. The licensed spectrum technology, however, is very useful when your solution needs a nation-wide available network, with guaranteed quality of service.

How does the cost of LoRa compare with the ZigBee, e.g. TI CC2530?

The CC2530 is about a dollar cheaper. It lists for $2.93 on DigiKey when buying 2,500. The SX1272 LoRa radio lists for $3.90 in similar quantities.

Where does BLE 5.0 fit within your range power axes? Does it start taking some of the LoRa cases?

It’s definitely a great step in the right direction. BLE 5 can give a 12 dB link budget improvement over BLE 4, which is a big improvement; in free space it quadruples the distance! This makes BLE 5 a lot more suitable for smart home and smart office solutions where you need more range, and it puts it close to the range of 802.15.4 technologies (like 6LoWPAN and Zigbee). In addition, adding mesh networking to BLE is great, especially with everyone’s phone being a potential edge router, which will give extensive coverage.

However, LoRa still offers a much better link budget (maximum 151 dBm for LoRa vs. 108 dBm for BLE 5), so for anything that needs to span more than an office, LoRa is still a better choice. But it’s great to see radio technology moving more to long range; better choice choice between radio technologies is good for innovation.

How is LoRaWAN better than Sigfox?

Both have their advantages. The main advantage of LoRaWAN is that anyone can build a network without requiring permission from Sigfox. A downside is that you can only source the radios from Semtech, whereas there are many Sigfox radio vendors. Sigfox radios are also slightly cheaper at the moment. Technically, LoRaWAN has a better link budget from gateway to device, as it was built for two-way communications from the start.

In the webinar, you mentioned 6LoWPAN. But this is not an RF technology… do you mean 802.15.4?

Yes, 6LoWPAN over 802.15.4. Often this is categorized under just ‘6LoWPAN’ by vendors (for example here); I agree that it’s a bit confusing.

Is it correct to assume that in the future systems will use two or more complementing technologies (short range/long range, low/high bandwidth)?

Yes; LoRaWAN combined with BLE or WiFi makes a very powerful combination for both long range (aggregated) telemetry communication and high bandwidth short range communication. It really depends on the use case whether the added BOM cost are feasible.

The Things Network

Where is The Things Conference?

The Things Conference is hosted in Amsterdam, the Netherlands on 1-3 February, 2018. More information is on the official website.

When will the online course to prepare for the conference be released?

The LoRaWAN Academy for attendees of The Things Conference starts in early January.

What kind of cookie?

If you come to the Things Conference, find me or Johan, and mention the webinar, we’ll give you a stroopwafel. It’s probably the best thing invented in the Netherlands, just before wooden shoes and dikes.

What are the warranties to have a stable network when using a community network like The Things Network? How do I implement a product with a lifetime of 10 years with such an unknown future network coverage?

The Things Network is a community network and does not come with guarantees or SLAs. The power of The Things Network is that you are in control yourself. When you need support or SLAs and would like to make use of the same technology, we provide private networks through The Things Industries. From early 2018, we will also enable peering between a private and the public community network so you get the best of both worlds.

Does The Things Network provide an MQTT bridge?

Yes. In fact, MQTT is the developer’s primary method of sending and receiving messages on the network. We also support HTTP integration, which is very convenient for web developers. There is also RESTful storage as well as numerous integrations with third party IoT platforms.

If I register to your network, can I provide my global customers with a product with the same account?

Yes, The Things Network works with devices and gateways on any frequency plan, and all data can be grouped together regardless of physical location. The routing regions of The Things Network are also interconnected, so that it’s one big global LoRaWAN network.

Is The Things Network free of charge? If so, what are the usage restrictions?

The Things Network is provided free of charge and there are no usage restrictions. There is a Fair Access Policy to keep LoRaWAN in general scalable. As it is a community network, there is no service level agreement (SLA) available, but we do provide that for private networks with the same technology through The Things Industries.

What is the price for an account for 1,000 devices?

The Things Network can be used free of charge. Private networks through The Things Industries come at about 150 euro a month for 1,000 devices.

Arm Mbed OS is provided free of charge under the Apache 2.0 license, even if you ship 1,000,000 devices.

Is there support for the latest LoRaWAN 1.1 specs?

The LoRaWAN 1.1 specification just came out, and we expect device and network support to become available in the first quarter of 2018. The Things Network Stack V3 will support LoRaWAN 1.1 and will be fully open source from 2018 Q1.


Jan Jongboom is Developer Evangelist IoT at Arm, Johan Stokking is co-founder of The Things Network. They’re both active in the LoRa alliance and both owe their editor a stroopwafel.