Bringing a LoRa®-Enabled Device to Market

Overview

This guide is intended to help device makers bring a new LoRa® device to market as quickly and easily as possible. In addition to the practical aspects of bringing a device to market, this document also includes important technical, business, and regulatory factors to consider.

Preamble

As a technical innovator with a great product idea, you already understand the fundamentals of bringing a product to market. You started by asking yourself why this product should exist, why it doesn’t exist already, and why you are best placed to deliver success. Then you asked yourself who this product was for, where it was going to work best, when it needed to get to market, and how you could be successful in bringing this product to best serve your customers.

In asking and answering all these questions you probably created a product roadmap, with a vision, a mission statement, a few clear goals, detailed personas, a Strengths, Weaknesses, Opportunities, and Threats (SWOT) analysis, a set of core features, a list of dependencies, success criteria, and a timeline for releases.

Somewhere along the line, you decided that this new product needed to be a LoRa device, which is where this guide comes in.

Introduction

What unique aspects of LoRa® and LoRaWAN® should you account for when planning your product? What are the opportunities, requirements, and challenges? Refer to this document for help with the practical aspects of bringing a successful LoRa device to market. In brief, we will cover factors and decisions on:

1. Device hardware
2. Provisioning
3. Network options
4. Regional requirements
5. Test, certification and branding
6. Distribution and Operation

Figure 1 – LoRa device maker considerations

Device Decisions

Hardware Options: Build, Buy, Integrate 

What must you design and build from scratch, as opposed to being able to create from third-party modules? In the early stages of developing the product, you might create a proof of concept (PoC) device out of existing, reliable modules. As you scale up and go to production, creating your own custom components becomes more cost-effective. However, using a module is an absolutely valid approach for going into production: it will help you get your device certified more quickly, and allow you to focus on the unique aspects of your product, rather than recreating fundamental technology.

Look at the vendors listed in the LoRa Alliance marketplace as a guide for tested and trusted partners. These vendors may become either a source of modules or assistance as you design new PCBs from scratch.

You should also explore the Semtech Partner Catalog to find suppliers of software, hardware, solutions, and services that can help accelerate your development process.

Chipset and PCB

How you choose to construct your devices will be based on the radio(s) you need, the kinds of support you’ll need, and how much you plan to customize them.

• Semtech provides a wide range of LoRa® RF modules, development kits, Mbed shields, and reference designs you can use to build your next great device. You can find these products here. You can also find a list of module makers in Semtech's Product Catalog.
• Semtech also licenses its LoRa designs to other chipset manufacturers.
• The Semtech FAQ has a helpful section about end devices, here.
• Once you have integrated a radio, sensors, and logic onto a printed circuit board (PCB), Semtech provides a free PCB design review service (you can find details here). The service is free for production runs planned for more than 5,000 units.
• Finally, you will need to get your device tested and certified (see the  Test and Certification section below).

Firmware and Software Decisions

Decision	Considerations & impacts
The programming language for your firmware	C is recommended.  It allows you to take advantage of LoRa Basics™ Modem libraries and the LoRaMAC-Node™ reference implementation. This impacts the engineers you need to hire, the training you need to plan, and the partners you choose.
LoRaWAN stack	If you are working in C, you can use the LoRaMAC-Node implementation example, or the libraries provided by LoRa Basics Modem for LR1110, SX1261 and SX1262, or LoRa Basics Modem for SX1280.
LoRaWAN Specification	At minimum, you should implement the LoRaWAN L2 1.0.4 specification, (TS001-1.0.4). At the time of writing, 1.0.4 is the most recent version of the LoRaWAN specification. Published in October 2020, it contains security updates, improvements to Class B, and other updates over earlier versions. Implementing LoRaWAN 1.0.4 is required to pass certification. Alongside LoRaWAN 1.0.4, you should follow the Regional Parameters specification, version RP002-1.0.3 (or more recent) which describes the LoRaWAN regional parameters for different regions worldwide. RP002-1.0.3 was published in May 2021. You should also check the specific laws and regulations of the countries where you plan to operate.
Payload design for uplinks and downlinks	LoRaWAN specifies a maximum data payload for each worldwide region. This maximum payload size varies by data rate and region due to the fact that local regulations are different for different regions with respect to the maximum on-air transmission time allowed. For more information, refer to the Packet Size Considerations section in the Semtech Best Practices guide, and check the Maximum Payload Size section in the RP002-1.0.3 LoRaWAN® Regional Parameters document for the regions in which you are going to launch your device.

Generating, Provisioning, and Distributing Root Keys

Before joining to a LoRaWAN network, you need to generate cryptographic root keys for all the devices you make. A secure process for generating root keys is described in section 2.5.3 Root Key(s) of the TR007 Developing LoRaWAN® Devices guide.

You have two options for provisioning keys onto your devices:

1. Over-The-Air-Activation (OTAA) – This is the recommended option. One or more root keys (depending on the version of LoRaWAN) are stored on the device at the point of manufacture and are then used during a join process with the network server to generate the session root keys. These session keys then provide ongoing security. The session root keys can be changed by rejoining the network.
2. Activation-By-Personalization (APB) – This may seem to be simpler to implement, however, it  introduces severe limitations and drawbacks; key among them are that the session root keys are stored on the device at the point of manufacture and cannot be changed.

 

OTAA requires that your device is in network range when it turns on, so it can perform the join procedure and receive a join accept message. If the device is turned on out of network range, you have to ensure that it does not continuously retry the join procedure. Doing so affects battery consumption and can breach regional regulations. Hence, you need to plan and configure your device to handle conditions in which no networks are available, or make use of a library which handles this for you.

APB, by contrast with OTAA, has important drawbacks, including:

1. The device may become hard-coded to a specific operator
2. Inability to generate new session keys (a particular weakness in the event of is a security breach)
3. Network parameters are fixed, which results in more complicated configuration requirements setting up the device in the network server
4. A set of values must be persisted in non-volatile memory (NVM), to ensure the device remains connected following a power cycle. These are listed in section 3.14 ABP Required Persistent Values of the  TR007 Developing LoRaWAN® Devices guide.

 

OTAA is vastly preferred as the more secure and flexible option, with two exceptions:

1. If your device doesn’t have a LoRa receiver
2. If the power constraints on your device are so tight that you cannot support the join request calls.

If you plan to allow customers to choose their own network server and will not be pre-provisioning the devices on a network server before distributing them, you need to identify a method of sharing the DevEUI, JoinEUI (formerly AppEUI) and root keys required for the LoRaWAN specification version and end device activation method you have chosen. These keys will then need to be supplied by the customer to their network server provider so that they can join the devices on the network.

The DevEUI and JoinEUI should be stored on the outside of the device as discussed in the What to Put on the Enclosure section. The root keys themselves cannot be stored on the outside of the device; however, by storing the DevEUI on the outside of the device, someone setting up the device can look elsewhere for the relevant root keys and can then cross reference the device with the keys.

Methods of supplying keys to customers include relatively insecure methods such as emailing a spreadsheet, to advanced approaches such as setting up an after-sales portal which allows customers to securely access the keys via HTTPS.

What does all this mean for you as a device maker?

1. Opt for the more secure, more flexible approach of OTAA whenever possible
2. Talk to network operators in your target region
3. Have a plan for how to generate, store, provision, and distribute root keys
4. Consider talking to a security expert about how to make it harder for attackers to compromise your root keys

The book on best practices for provisioning exists, and it is here on the Semtech developer portal. Let this be your guide to the details of how to provision your devices.

Complementary Connectivity

LoRaWAN is designed to be a network that works well with other types of radio beyond LoRa. You may, therefore, choose to include Bluetooth LE, Wi-Fi, or Cellular connectivity on your device. Additionally, a system you are part of may include some or all of these.

There is also the exciting option of adding satellite connectivity to your LoRa device, through Long Range – Frequency Hopping Spread Spectrum (LR-FHSS). This application can be particularly useful in agricultural contexts and in rural and remote areas.

Once again, your application will determine the radios and chipsets you will need in your device. For example, LR-FHSS modulation is supported on Semtech SX1261, SX1262 and LoRa Edge™ (LR1110) transceivers, and for LoRa® chip licensees.

Read more about how LR-FHSSS expands LoRaWAN network capacity here on the Semtech blog

Device Classes

There are three classes of LoRaWAN device:

• Class A – Very limited messaging from the server
• • You must implement this
  • Lowest power / highest latency of messages from the server
  • Battery powered sensors, or actuators with no latency constraint
  • Lowest energy usage of all 3 classes
  • Messages can only be sent from the network server to the end device in a short period after a message has been sent from the end device to the network server
• Class B – More frequent messaging from the server
  • Medium power consumption / medium latency of messages from the server
  • Battery-powered sensors and actuators
  • Allows additional messages to be sent to the device from the network server at scheduled times
• Class C – Continuously listening for messages from the server
  • Highest power consumption / lowest latency of messages from the server
  • Should be mains-powered, unless your use case means you can easily change the battery.
  • Messages can be sent from the network server to the end device at any time

 

Given these three classes, you have three choices of what to implement in your device:

• Class A only
• Class A + Class B
• Class A + Class C

 

Your use case will dictate the type of device, and your choice of class to implement will depend on:

• The type of application: sensor only, or sensor and actuator
• Battery consumption requirements: What battery life do your customers need? How easy is it to replace the battery? Is your device going to be indoors, close to mains power?
• Latency: how frequently does your device need to send data to the server, and how frequently does it need to receive instructions?

Your LoRaWAN device MUST implement Class A. You may also choose to implement Class B or Class C (but not both at the same time) as extensions to Class A. Note that you can switch a given device to Class B or C behavior temporarily, as needed, keeping in mind the additional power consumption involved.

To learn more:

• Watch this video from Semtech for an overview of LoRaWAN device classes.
• Read this Semtech paper on Class A devices
• Read this Semtech paper on Class B devices
• Read this Semtech paper on Class C devices

Radio Behavior

As a device maker, you need to make sure your devices offer a long battery life and reliable connectivity, Additionally, how your radio behaves is central to success. For best results, follow known best practices and adhere to and the appropriate regional/national regulations.

Some best practices:

1. Packet optimization to make best use of bandwidth. More here.
2. Backoff. When re-sending messages (for example if the device is experiencing connection/network issues), your device should follow set rules for preventing network congestion by implementing increasing delays before each repeat attempt. Read more here.
3. Adaptive Data Rate (ADR). ADR is when the network server controls the data rate, RF transmit power, channels used, and the number of retransmissions each end device in the network makes when sending uplinks. ADR helps preserve battery life and reduces interference. ADR is the best approach when you know your device will be stationary. Read more on implementing ADR here.

Your best guide to these best practices is, naturally, the best practices guide from Semtech.

Regional rules and regulations:

1. Comply with legal requirements for duty cycle limits, which vary by country.
2. Control Transmit Power. Again, this is a legal requirement (see here) and a good practice for preserving battery life.
3. Respect frequency plans for your target region.
   1. Regardless of the region(s) in which your devices will operate, make sure to optimize the frequencies you use within the relevant frequency plan
   2. Know that devices must be designed for the region where they are expeted to be deployed. If you have unsold devices for region A you can’t simply ship them to region B.

For a solid foundation on regional considerations consult the LoRaWAN® Regional Parameters specification from the LoRa Alliance.

Industrial Design Needs

Think of the environment where your device will function over the course of several years. Will it move? Will it be exposed to weather? Are there industry requirements for waterproofing, ruggedness, or radio interference? What are the usability factors? Weight factors? Will your device also implement Class B or C as well as Class A? All of these will affect the kind of housing you need, the material for the case, the ports, the types of testing needed, and the power supply requirements.

What to Put on the Enclosure

As you think about the enclosure for your device, beyond ports, radio-affecting materials and thicknesses, form factor, ruggedness, and waterproofing, you will want to make sure the fundamental purpose is fulfilled: to connect your device to a LoRaWAN network. Any user, whether a consumer in the home or a field engineer working in factories, fields, and offices, needs to be able to set up the device easily. A critical part of this is presenting the right information to allow a person to add your device to their network, whether through manual or automated processes.

You must establish a mechanism to share the onboarding data with your customers. For devices implementing LoRaWAN 1.0.x the required information is the Device EUI (DevEUI), JoinEUI/AppEUI and Application Key root key (AppKey). Typical methods include emailing the customer a spreadsheet or other document containing the information for the device they have purchased.

When installing devices, your customer will need to know which device is which, hence, the following information should be printed on each device:

• The DevEUI, in human-readable form. This is essential for the user to be able to match the device in the real world with the device that shows up in the network server.
• A QR code containing both the DevEUI and JoinEUI. This is beneficial in that it can help users during the setup process. Read and follow the TR005 LoRaWAN® Device Identification QR Codes technical recommendation to ensure the QR code you add follows the recommendations set out by the LoRa Alliance.

 

 

Getting to Market

Test and Certification Requirements

There are several testing and certification tasks to consider:

1. Region- and country-specific requirements, such as the Federal Communications Commission (FCC) in the USA and the CE standards in Europe. These are out of scope for this document.
2. Getting your device LoRaWAN Certified^CM. The LoRaWAN certification from the LoRa Alliance is the only certification program that ensures that end-devices conform to LoRa Alliance LoRaWAN standards. Here is a handy task list from the LoRa Alliance showing the test and certification process.

 

This program stipulates:

1. You must be a LoRa Alliance member, or a Certification Affiliate Program Member to have your device test, certified, and profiled on the LoRa Alliance website.
   1. Alliance members are provided access to the LoRaWAN Certification Test Tool (LCTT) and free certification testing as part of their membership.
   2. Certification Affiliates get one free license to the LCTT but must pay an annual fee and a per-device fee to certify a device.
2. Your device(s) must conform to the LoRa Alliance standard.
3. An Authorized Testing House must certify this conformance and will produce a test report as supporting evidence. You can find a list of authorized testing houses here.

 

When planning for certification, understand there are three possible paths:

Path	Description
New certification	Appropriate for newly developed devices and devices that have never been certified. Higher risk of needing to re-work and re-test. Test houses will not be familiar with the device and its components.
Certifying by similarity .	Appropriate for devices that are derived from an existing, already-certified device Devices must be made and submitted by the same manufacturer of the previously-certified device. Lower risk of needing re-work and re-testing Test houses will be familiar with the existing, similar device
Certifying by inclusion	Appropriate for devices that integrate previously-certified modules. Previously-certified components may come from any LoRa Alliance member manufacturer Lower risk of needing re-work and re-testing. Test houses will be familiar with the previously-certified integrated module.

 

To get your end devices certified and released to market, you need to understand the LoRa Alliance End Device Certification program.  For more detail on the LoRaWAN Certification process, refer to LoRa Alliance certification policies, processes and procedures here.

For a look at the minimum testing requirements by region, see the LoRa Alliance document LW1.0.4 End Device Certification for All Regions.

From Proof-of-Concept to Pilot and Production

It is essential to prove that your device works successfully in the markets and contexts you are targeting. Hence, you should test early and often with real users, on real networks. Semtech offers a free network server to support your proofs of concept and pilots. You can find more information here. Additionally, the Semtech partner catalog is a good guide to partners who can help you with everything from user testing to custom applications to running a pilot program.

Sales and Distribution

You can make your certified device available through several marketplaces. For instance:

1. The LoRaWAN Certified devices directory
2. Operator marketplaces like Senet, Actility, or The Things Network (Note: These may have additional requirements for device information and features.)
3. Technology platform marketplaces such as the AWS Partner Device Catalog

 

Third parties may have their own validation requirements for getting listed, as well as other terms and conditions.

As discussed in the Generating, Provisioning, and Distributing Root Keys section, your choice of distribution channel should factor in provisioning, and you should have a mechanism for generating, storing, and distributing root keys securely.

Logo Requirements

To use LoRaWAN branding in your product and marketing materials, you must be a member of the LoRa Alliance. Find guidance from the LoRa Alliance on how to use branding here.

If you want to use Semtech branding, review Semtech’s guidance on branding, which includes a useful video.

Regional Requirements: Global and National

Different regions impose rules around frequency plans, certification, and power use. Different regions will also offer different options for distribution partners and network operators and coverage. To learn more about regional and country-specific frequency plans, read this article.

In summary, for each region and country where you plan to make your device available, you must understand and comply with local regulations covering frequency plans and duty-cycle limitations.

There are practical considerations, too, including:

1. What distribution partners exist in your target region?
2. What network operators offer good coverage in your target region?

To help you find the right hardware, software, and networks for the regions in which you plan to deploy your solution, check out the Semtech partner catalog.

Operational Requirements

The success of your device in the market will depend not only on your good work in getting the hardware, software, and radio behavior right, but also on operational factors like:

• Network connectivity
• Device setup 
• Support and maintenance 
• Firmware updates

 

The Semtech partner catalog is also a great place to look for service partners that can help fulfill one or more of these functions, or that can help you build up your own capabilities.

Network Factors

Your customers have a few options for connecting your device to a network:

1. Build a private network. This involves setting up gateways to ensure coverage in their target area.
2. Pay a network operator. There are network operators in every region that offer different areas of coverage and levels of service and support. The major network operators often have roaming agreements that increase their overall range of coverage.

 

Search the Semtech partner catalog for network operators in your chosen geographic market.

Your choice of how to connect your devices to a network will impact your provisioning story. For example, do you plan to have your devices pre-joined to a particular join server, or will you give the end user the flexibility to choose their own network? If your customers will make their own network connectivity choices, that should be informed by their business model. As a device maker, you may not care much about these factors, but you should make sure there are no barriers to connecting your devices to the networks your customers want to use.

Firmware Updates to Deployed Devices with FUOTA

As your device lives on in the wild, you may want to offer firmware updates to take advantage of new features in LoRaWAN, fix bugs, or your own improvements. LoRaWAN provides a standard mechanism for updating your device firmware, called Firmware Update Over-the-Air (FUOTA). The LoRa Alliance provides conceptual details about FUOTA here, and Semtech provides more deeply technical information here.

End of Life

As a responsible device maker, you will certainly be thinking about your device’s end of life (EOL). For instance, you will need to ensure that your device can be disposed of or recycled, in whole or in part, safely and in compliance with regional regulations and best practices. Here are a few considerations to take into account:

Consideration	Options
How can you extend the life of a device through upgrades and updates?	You can apply software updates or upgrades, for example, via Firmware Updates Over-the-Air, as described above.  You can also extend the life of a device with replaceable batteries. If you plan to take this route, you will also need to consider how to handle the old batteries.
What is the battery EOL?	Having a replaceable battery has implications for industrial design and may increase costs. However, employing a replaceable battery will extend the life of your device in the wild.
Can the materials be recycled?	Ask yourself: What is the case made of? What plastics and metals are included? How easy is it to separate the component materials? How can the PCB and modules be processed?
Where will your device be sold?	Recognize that regional and national regulations for recycling and disposing of materials vary and may impact the choices you make for your devices. You should review the following documents as you begin designing your devices The European Union’s directive on Waste from Electrical and Electronic Equipment (WEEE) United States’ Environmental Protection Agency strategy for cleaning up electronic waste.California regulations on electronic hazardous waste  (These regulations often lead the way for the Unites states overall)
Can the sensors or components in the device be re-purposed, migrated to other devices?	Do you want to offer a return program? What systems and procedures must be in place for shipping, receiving, storing, and processing such returns? How will the costs of running this operation factor into the overall ROI?

 

For more information about the impact of electronic waste and how it approaches the problem, read Semtech’s own environmental impact guidance.

Conclusion

Your success in bringing a LoRa device to market depends on your own hard work. A considerable amount of help is available, however, from a variety of sources: from Semtech, its many partners, and from other LoRa Alliance members. Whether you’re working with hardware, software, testing and certification, system integration, or operations, you have access to all the resources you might need to create a successful LoRa device that will delight your customers wherever they are in the world.

Good luck!