LoRa Device Developer Guide

Orange Connected Objects & Partnerships

In collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Credits
This LoRa Device Developer Guide is an initiative by Orange Connected Objects & Partnerships developed in
collaboration with Actility. It provides an overiew of the LoRa ecosystem, wireless network architecture, as well as
guidelines to support the growing community of developers adopting the LoRaWAN specification to connect
devices, sensors and actuators to IoT applications and services.

Main contributors to this document are:

Nicolas DUCROT
Dominique RAY
Ahmed SAADANI

Olivier HERSENT
Gabor POP
Guillaume REMOND

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Table of Content

Table of Content .......................................................................................................................... 3

Introduction to LoRaWAN ............................................................................................................ 5

2.1
LoRa wireless access, networks technology and key benefits .............................................................. 5
2.1.1
Internet of Things: networks technologies and market prospects....................................................... 5
2.1.2
Use cases and market verticals...........................................................................................................12
2.1.3
LoRaWAN versus other LPWA network solutions ..............................................................................20
2.2
LoRa wireless networks architecture ............................................................................................... 21
2.2.1
Network system architecture .............................................................................................................21
2.2.2
Authentication and security ...............................................................................................................22
2.3
Live Objects device and data management ...................................................................................... 24
2.4
Network Elements .......................................................................................................................... 25
2.4.1
LoRaWAN Base Station or Long Range Router (LRR) .........................................................................25
2.4.2
LoRaWAN omni versus multi-sector antennas ...................................................................................25
2.4.3
Macro-gateway base stations .............................................................................................................25
2.4.4
Pico-gateway base stations ................................................................................................................25
2.4.5
The Core Network Server or Long Range Controller (LRC) .................................................................25

LoRa devices architectures overview .......................................................................................... 26

3.1
3.2
3.3
3.4
3.5

Design based on a LoRa chipset ....................................................................................................... 27

Design based on a LoRa module ...................................................................................................... 28
Design based on a RF-MCU .............................................................................................................. 28
Design based on a LoRa modem ...................................................................................................... 29
Existing device with external LoRa modem ...................................................................................... 29

Development and integration of a LoRa device .......................................................................... 30

4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12

Architecture selection ..................................................................................................................... 30

Antenna design ............................................................................................................................... 30
Device autonomy ............................................................................................................................ 31
Integration and development .......................................................................................................... 33
Software development .................................................................................................................... 34
Software application layer............................................................................................................... 34
Test application .............................................................................................................................. 34
LoRa application best practices........................................................................................................ 34
Production parameters ................................................................................................................... 35
Manufacturing tests ........................................................................................................................ 36
Certification .................................................................................................................................... 36
Device life cycle .............................................................................................................................. 39

Project use cases examples ........................................................................................................ 40

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Glossary of Terms
Term

Definition

ADR

Adaptive Data Rate

API

Application Programming Interface

Application Key
(AppSKey)

The optional 128-bit key used to encrypt the payload of the messages.

Application Server
(AS) Routing Profile

The routing information defining how sensor data is routed to an

application back-end connected to the core network platform.

Long Range Receiver

(LRR) Base Station

The equipment implementing one or more radio transceivers complying

with the LoRaWAN network PHY and MAC layer specification. The LRR
operates under the control of the LRC.

Connectivity Plan

The connectivity plan defines the networking features (e.g. confirmed

messages, downlink traffic), the traffic policy parameters (token bucket
regulators for uplink and downlink traffic) and the associated activation
and recurring fee associated to a given device.

Device

An appliance identified by its globally unique IEEE EUI-64 identifier that is

able to initiate uplink traffic to, or receive downlink traffic from, one or
more Application Server through the LPWA network infrastructure.

EUI ID

A globally unique 64 bit identifier assigned according to the IEEE EUI-64

guidelines.

GUI

Graphical User Interface

LoRa

Long Range and low energy radio RF technology developed by Semtech.

LoRa is a registered trademark by Semtech Corporation.

Long Range
Controller (LRC)

The LPWA core network component implementing the cloud based MAC
layer and acting as a mediation function between connected devices and
Application Servers.

Network Key
(NwkSKey)

The 128-bit key used by the LPWA network to verify the authenticity and
integrity of each message transmitted through the system.

NOC

Network Operation Center

OSS

Operations Support System

SNR

Signal to Noise Ratio

LPWA

Low Power Wide Area networks

TDoA

Time Difference on Arrival is a wireless location technology that relies on

sensitive receivers that are typically located at basestations to determine
the location of a device.

MAC layer

Medium access control or media access control (MAC) layer is the lower
sublayer of the data link layer (layer 2) of the seven-layer OSI model.

ISM band

Industrial, Scientific and Medical usages dedicated licence-free frequency

spectrum.

MQTT

ISO standard (ISO/IEC PRF 20922) publish-suscribe based "light weight"

messaging protocol for use on top of the TCP/IP protocol.

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Introduction to LoRaWAN

2.1 LoRa wireless access, networks technology and key benefits

2.1.1 Internet of Things: networks technologies and market prospects
The Internet of Things (IoT) is a collection of connected objects, embedding electronics, software, sensors, and
wireless connectivity protocols that collect and exchange information with applications through wireless
networks connected to the Internet. The Internet of Things allows connected objects to remotely communicate
and be remotely controlled through applications by leveraging existing internet infrastructures, combined with
optimized wireless communication systems. Its enables a direct integration and communication between the
physical and the digital worlds. IoT is expected to produce a massive amount of information which will be used to
optimize the consumption of all types of resources and improve the efficiencies of increasingly inteconnected
sytems. IoT will also enhance or create new services to bring sustainable value to businesses, consumers and the
overall environment.
Today, the Internet of Things already impacts the business models of many industries and services such as
consumer electronics, automotive, utilities, facility management, smart buildings, connected cities, e-health,
supply chains or manufacturing applications.

Fig 1. Billion global connections, 2015-2025 (Machina Research, May 2015)

According to Machina Research, connected objects will account for more than 25 billion connections by 2025.
Based on the current projection, a large part of these connections will come from fixed and short range
connections such as Wifi, Bluetooth, Zigbee, Z-Wave etc. These technologies are well suited for short range
applications where power consumption and battery life is not a major issue. Cellular connections will originate
from SIM and/or e-SIM enabled devices using 2G/3G/4G network infrastructures and technologies. Current
generations of cellular technologies will need to be completed by cellular evolutions and LPWA (Low Power Wide
Area) technologies to serve many new IoT applications due to the low power consumption requirements by
devices to send and receive relatively low volumes of data.
Beyond cellular evolutions, the new wireless IoT connectivity family named LPWA networks is well suited to
support services and use cases which need long range communication (dozens of km) to reach devices which
must have a low power consumption budget in order to operate several years remotely on a single battery pack.
The trade-off is a low data rate delivered by LPWA network technologies, from 300 bps up to 5 kbps (with 125 kHz
bandwith) in LoRa modulation.

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Key use cases for LPWA networks include applications for Smart Cities such as smart parking, intelligent street
lighting, supply chain management with asset tracking & condition monitoring, smart grids with electricity, water
& gas metering, smart agriculture with land condition monitoring or animal tracking and geofencing.
These are just few examples of existing applications. Thanks to the growing awareness of LPWA capabilities and
live network deployments, new market needs and use cases appear continuously.
Several radio technologies co-exist to deploy LPWA networks. Along with the Ultra Narrowband (UNB) protocol,
LoRa and its MAC layer implementation LoRaWAN is the LPWA network solution currently gaining the most
traction to support IoT applications and services.

Fig 2. IoT connectivity technologies segmentation

Based on the LoRa radio modulation technology, invented in 2010 by the French startup Cycleo and then acquired
in 2012 by Semtech (a semiconductor company), a MAC layer has been added to standardize and extend the LoRa
physical communication layer onto internet networks. This MAC layer is called the LoRaWAN (LoRa for Wide Area
Networks) specification. The specification is open sourced and supported by the LoRa Alliance. The LoRaWAN
protocol also includes several key wireless network features such as E2E encryption and security, adaptive data
rate optimisation, quality of service, and other advanced communication applications.
Orange network supports currently the LoRaWAN 1.0 specification. A new version is under specification
(LoRaWAN 1.1) and will be available on Orange network in the future.

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Fig 3. Typical LoRaWAN network architecture overview

LoRaWAN networks are typically laid out as star-of-stars topology in which gateways relay messages between
end-devices and a central core network server. All gateways are connected to the core network server via
standard IP connections while end-devices use single-hop LoRa communication to one or many gateways. All
communication is natively bi-directional, although uplink communication from an end-device to the network
server is expected to be the predominant use case and traffic patern.

Fig 4. Usual network topologies

A star network architecture provides the best compromise between long range communication, number of
antennas (base stations) and devices battery life.

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Communication between end-devices and gateways is spread out on different frequency channels and data rates.
The selection of the optimized data rate is a trade-off between the communication range and the message
duration. Communications using different data rates do not interfere with each other. LoRa supports data rates
ranging from 300 bps to 5 kbps for a 125 kHz bandwith. In order to maximize both the battery life of each device
and the overall capacity available through the system, LoRa network infrastructures use an Adaptive Data Rate
(ADR) scheme to manage the individual data rates and RF output of each connected device.
End-devices may transmit on any channel available at any time, using any available data rate, as long as the
following rules are respected:
The end-device changes channel in a pseudo-random fashion for every transmission. The resulting frequency
diversity makes the system more robust against interference.
In EU 868 ISM band, the end-device has to respect the maximum transmit duty cycle relative to the sub-band
used and local regulations (1% for end-devices).
In the US, the end-device respects the maximum transmit duration (or dwell time) relative to the sub-band used
and local regulations which is 400ms.
Adaptative Data Rate is the procedure by which the network instructs a node to perform a rate adaptation by
using a requested data rate (and a requested TX Power in future LoRaWAN versions). The table below illustrates
the Data Rate as function of the distance and the Spreading Factor (SF). As illustrated, LoRaWAN optimizes the
communication data rate to minimize the airtime and power consumption of devices. Compared to fixed data
rate of LPWA technologies, this optimization can lower average power consumption of a connected object by a
factor of 100.

(with coding rate 4/5 ; bandwidth 125Khz ; Packet Error Rate (PER): 1%)

Fig 5. LoRaWAN protocol Spreading Factors (SF) versus data rate and time-on-air

LoRaWAN uses licence-free spectrum, usually ISM (Industrial, Scientific, Medical) bands to communicate over the
air. In Europe, ETSI regulates the ISM band access on the 868 MHz and 433 MHz bands. The usage of these bands
is submitted to limitations: The output power (EIRP) of the transmitter shall not exceed 14 dBm or 25 mW, and

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

the duty cycle imposed in Europe by ETSI is limited to 1% (for devices) or 10% (for gateways) depending on the
used sub-band.

Fig 6. LoRaWAN network layers

Three different classes (A,B,C) of communication profiles are available in LoRa networks between devices and
applications. Each class serves different application needs and has optimised requirements for specific purposes.
The key difference between A, B and C profiles is the trade-off made between latency and power consumption.

Fig 7. LoRaWAN communication profiles classes

April 2016

All rights reserved

in collaboration with

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Class A (available since LoRaWAN 1.0)

The below figure illustrates default configuration in LoRaWAN standard in SF12. Values can be adjusted.

Fig 8. Class A default configuration profile

Class A devices implement a bi-directional communication profile whereby each end-devices uplink transmission
is followed by two short downlink receive windows. The transmission slot scheduled by the end-device is based
on its own communication needs with a small variation based on a random time basis. This Class A operation is
the lowest power consuming option for applications that only require downlink communication from the server
shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any
other time has to wait until the next scheduled uplink. Class A covers the vast majority of use cases, and is the
most power efficient mode of LoRa.

Class B (will be available in LoRaWAN 1.1)

The below figure illustrates default configuration in LoRaWAN standard in SF12. Values can be adjusted.

Fig 9. Class B default configuration profile

April 2016

All rights reserved

in collaboration with

10

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Devices should implement a Class B communication profile when there is a requirement to ensure low latency of
downlink communication, while keeping the power consumption as low as possible. Class B emulates a
continuously receiving device by opening receive windows at fixed time intervals for the purpose of enabling
server-initiated downlink messages.
LoRaWAN Class B option adds a synchronized reception window on the remote device. Class B is achieved by
having the gateway send a beacon on a regular basis to synchronize all the end-point devices in the network. It
allows devices to open a short extra reception window (called ping slot) at a predictable time during a periodic
time slot.
Class B is currently still in experimental status at the LoRa alliance, but most use cases can already be covered by
combination of class A and class C. For example devices requiring periodic rendezvous points to receive
configuration data (e.g. room reservation display) may periodically request time from the LPWA network, then
synchronize their internal clock and periodically open rendezvous windows for downlink messages.

Class C (available since LoRaWAN 1.0)

The below figure illustrates default configuration in LoRaWAN standard in SF12. Values can be adjusted.

Fig 10. Class C default configuration profile

Devices implementing Class C communication profiles are used for applications that have sufficient power
available and thus do not need to minimize reception time windows. This is the case of most actuators (smart
plugs, remote control of powered devices, etc.). Class C devices will listen with RX2 windows parameters as often
as possible. The device listens on RX2 when it is not either (a) sending or (b) receiving on RX1, according to Class A
definition. To do so, it will open a short window on RX2 parameters between the end of the uplink transmission
and the beginning of the RX1 reception window and it will switch to RX2 reception parameters as soon as the RX1
reception window is closed; the RX2 reception window will remain open until the end-device has to send another
message.

April 2016

All rights reserved

in collaboration with

11

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

2.1.2 Use cases and market verticals

Key vertical markets and use cases for LPWA and specifically LoRaWAN are outlined in the table below:

Fig 11. LoRaWAN use cases and verticals

The LoRaWAN technology has been designed to respond to use cases where a sensor communicates small
amounts of data a few times a day. It is well suited for smart meters, trackers, comfort sensors etc. However, it
is not designed to support applications that require high data rates such as audio or video. However, LoRaWAN
can be used to control other wireless device capabilities; for instance to remotely instruct a camera to begin a
data transmission, and stay in low power mode whenever opening a video stream is not required.
The examples below detail several key applications of LoRaWAN: Smart cities, Factories and Industries, Facility
Management, Healthcare or dedicated networks for specific verticals, e.g. airport management.

April 2016

All rights reserved

in collaboration with

12

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Facility Management

Fig 12. Facility management vertical

Healthcare Applications

Fig 13. Healthcare application vertical

April 2016

All rights reserved

in collaboration with

13

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Factories and Industrial Applications

Fig 14. Smart Industries vertical

Airport Services
Management

Fig 15. The connected airport

April 2016

All rights reserved

in collaboration with

14

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Smart Parking
Application

Fig 16. Smart parking

Street Lighting

Fig 17. Street lighting

April 2016

All rights reserved

in collaboration with

15

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Elderly people assistance

Fig 18. Elderly people monitoring and assistance

Bicycle / vehicle tracking & location

Fig 19. Asset tracking and anti-theft solution

April 2016

All rights reserved

in collaboration with

16

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Medical wearables

Fig 20. Medical wearables

Connected devices: the smart glass

Fig 21. The smart glass

April 2016

All rights reserved

in collaboration with

17

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Home automation & appliances

Fig 22. Home Automation vertical

The connected button

Fig 23. The connected button

April 2016

All rights reserved

in collaboration with

18

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Waste management

Fig 24. Waste management use case

April 2016

All rights reserved

in collaboration with

19

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

2.1.3 LoRaWAN versus other LPWA network solutions

Several approaches are being used to benchmark LPWAN solutions commercially available, both from a technical
and a business perspective. Many LPWAN networks are currently in trial phases or in commercial rollout
worldwide because of the attractiveness to create a rapid route to market innovative IoT services.
The two leading network technologies contributing to the fast development of LPWA IoT markets are LoRaWAN,
and Ultra-Narrowband (UNB).
The LoRaWAN protocol has several advantages over other LPWA technologies:

The data rate ranges from 300 bps up to 5 kbps (with 125 kHz bandwidth) and 11 kbps (with 250 kHz
bandwidth) allowing for better time-on-air and better battery life
Communication is natively bidirectional and unlimited (with respect to ISM band local regulations)
Native payload encryption
Location without GPS with TDoA
Wide offer in gateways: macro-gateways, indoor gateways, pico-gateways for in-home usage
Able to create public and / or private networks
ADR (Adaptive Data Rate) enables an easily scalable network as base station addition will lower the
average ADR and time-on-air around it, allowing for more end nodes to communicate

Other LPWA technologies such as Weightless-N, Weightless-P from Weightless SIG and RPMA (Random Phase
Multiple Access technology) from Ingenu are also commercially deployed and used to support specific vertical use
cases.
Last but not least, there are several new 3GPP standards such as EC-GSM, LTE-M and NB-IoT that are currently
being specified to enable future 3GPP networks to support the specific requirements and use cases of the fast
growing IoT markets in upcoming years.

April 2016

All rights reserved

in collaboration with

20

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

2.2 LoRa wireless networks architecture

The following chapter provides an overview of a typical LoRa network architecture with specific examples related
to Orange and Actility assets.

2.2.1 Network system architecture

LoRaWAN networks leverage advanced communication system architectures to deploy, control and route IoT
data between end-devices and applications. LoRaWAN is one of the first fully virtualized wireless networking
technologies commercially available. In a LoRaWAN network system, all base stations collaborate and are
collectively seen by end-devices as the network. There is no complex (and power-hungry) handover procedure
between network cells. All network messages are managed by a centralized network controller function.
Orange LoRa network associated with Actility LoRaWAN platform includes network controllers (LRC servers), base
stations (LRRs) and Live Objects APIs, completed by a comprehensive ecosystem of interoperable certified sensor
devices enabling rapidly deployment of end to end use cases.
The network platform connects and manages devices compliant with the LoRaWAN PHY and MAC layer
specification published by the LoRa Alliance.
LoRaWAN network system architecture example

Fig 25. Simplified LoRaWAN data exposure model

A LoRaWAN network includes the following key components: the base station or gateway also known as LRR
(Long Range Relay), the LRC (Long Range Controller) i.e. the LoRaWAN network server, and the OSS (Operation
Support System) for provisioning and management of the network system.
Base station (LoRaWAN Gateway)
Macro-gateway and pico-gateway base stations are pre-integrated with the platform to ease LPWA network
rollout and provisioning using common interfaces and APIs.
Macro-gateways are typically used in public network deployments to ensure city or nationwide coverage.
Pico-gateways can be deployed to increase network capacity in dense areas, or to improve Quality of Service
parameters, for example to lower time on air in order to increase the battery lifetime of a specific application (e.g.
smart parking applications), or to ensure coverage of hard-to-reach or isolated sites. Pico-gateway functionality
may also be added to other equipment to allow longer range or neighborhood communication use cases.

April 2016

All rights reserved

in collaboration with

21

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Core network server (or LRC)

The core network server is controlling the virtualized MAC layer of LoRaWAN. It coordinates messages (frames)
and Network commands (MAC) between the base stations and the OSS / Application Servers. The server
implements download packet routing, intelligent dynamic base station selection (for optimized traffic routing),
device authentication, duplicate packets removal and Adaptive Data Rate (ADR) functionality. It also interfaces
with the OSS for provisioning, administration and reporting purposes.

2.2.2 Authentication and security

A LoRaWAN network solution comes with a baseline authentication and security framework based on the AES 128
encryption scheme and other established security standards such as IEEE 802.15.4/2006 Annex B [IEEE802154].
Compared to some other systems which rely on a single key for authentication and encryption, the LoRaWAN
framework separates authentication and encryption, so that Orange is able to authenticate packets and provide
integrity protection. Authentication and integrity control use the network session key (NwkSKey); user payload
encryption uses the application session key (AppSKey). The AppSKey and NwkSKey are stored by Orange for
regulatory and security reasons.
The NwkSKey and AppSKey are AES-128 root keys specific to the end-device that are assigned by the device
manufacturers or the application owner.
The LoRaWAN core network server solution supports 2 authentication and activation methods described in the
LoRaWAN specification: Activation by Personalization (ABP) and Over-The-Air Activation (OTAA).

Over the Air Activation (OTAA)

Orange network supports an Over-The-Air activation method where devices are not initially personalized for any
particular network but send a JOIN request to a given LoRa Network to receive a device address and an
authorization token from which to derive session keys. The Application and Network session keys are derived
during the OTA Join procedure, from a root AppKey pre-provisioned in the device as part of manufacturing or
commissioning. OTA Activation provides a high level of security.

Fig 26. Over-the-air activation

April 2016

All rights reserved

in collaboration with

22

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Activation by Personalization (ABP)

In Activation by Personalization, devices are personalized to work with a given LoRaWAN network defined by its
Network ID. Devices are therefore pre-provisioned with the Network and Application session keys and the 32-bits
device network address. Orange recommends using this method for specific situations only, the default
recommendation for device makers is to use the OTAA method.

Fig 27. Activation by Personalization process

April 2016

All rights reserved

in collaboration with

23

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

2.3 Live Objects device and data management

Orange device and data management platform for IoT is Live Objects Manage. You can find information on Live
Objects Manage on the following web site:
https://datavenue.orange.com/live-objects

Live Objects Manage

Publish &
Subscribe

Persistent
FIFO queue

Message Router

MQTT(S)

LoRa interface

Live Objects
services

-SMS
-E-mail

Security

Bus

Out

Data
Management

Device
Management

Orange LoRa network

HTTPS

Bus

Connectivity

internet
Devices /
things

IoT application

IoT application

Apps

Fig 28. Live Objects Manage architecture

Live Objects offers a set of device and data management tools exposed through APIs and Portals interfaces to
easily monitor the status and data of objects, sensors and actuators. The main purpose of Live Objects is
interconnecting end-devices with IoT applications.
When using Orange LoRa network, all the data generated by your device will be natively stored within Live
Objects Manage platform. As Live Objects is open through web APIs (REST and MQTT), you can easily plug your
IoT application on Live Objects to retrieve your data. Live Objects is also the platform providing all device
management features including device provisioning used for Over The Air Activation.
The current features available on Live Objects are the following:

Connectivity interfaces to collect data, send command or notification from/to IoT devices
Device management (supervision, configuration, firmware, etc)
Message routing between devices and IoT applications
Data storage with advanced search features

April 2016

All rights reserved

in collaboration with

24

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

2.4 Network Elements

2.4.1 LoRaWAN Base Station or Long Range Router (LRR)
The LoRaWAN LRR, commonly referred to as macro-gateways or base stations are equipped with LoRa
transceivers based on Semtech SX1301 chipsets. Orange network supports bitrates from 300 bps up to 5 kbps
(depending on Spreading Factor between SF7 and SF12) for the 125 kHz bandwidth. LoRaWAN base stations are
pre-installed with software allowing them to be remotely managed by the LoRaWAN network server OSS. LRR
base stations exist in macro-gateway or pico-gateway versions.

2.4.2 LoRaWAN omni versus multi-sector antennas

LoRaWAN base stations come with both omnidirectional antennas and multi-sector antennas. Base station
antennas options depend on local country transmit power restrictions and the defined link budget requirements
for network rollout.

2.4.3 Macro-gateway base stations

Macro-gateway base stations ensure large area coverage based on the LoRaWAN technology. Orange LoRaWAN
macro-gateway base stations support multiple backhauling technologies based on Ethernet and 4G/3G networks.
LoRaWAN base stations equipped with the 2016 new reference design from Semtech allows base stations to
possibly use two SX1301 chipsets and fine time-stamping of every uplink frame to send accurate timestamps to
the Network Location Solver. This enhanced LRR configuration will enable in the future the LoRa network to
compute an accurate position of every connected device without needing the assistance of embedded GPS
modules with TDoA approach. This advanced network feature will reduce the cost of the tracking end-device and
optimize its battery-life.

2.4.4 Pico-gateway base stations

Device makers and end users can easily set up a LoRaWAN pico-gateway at home or in offices. They can for
example add a simple plug and play LoRa pico-gateway module to an existing appliance such as an alarm system
or an Internet box to enhance LoRa network coverage in their neighborhood. Pico-gateways need to be selected
within Orange certified catalogue.

2.4.5 The Core Network Server or Long Range Controller (LRC)

The core network server controller implements virtualized cloud based MAC layer and acts as a mediation
function towards connected application servers. It coordinates messages (frames) and MAC commands between
base stations, the network OSS tools and customer applications servers.
The LRC manages devices authentication, packet routing and provides redundant and scalable centralized
management for all base stations and wireless end-devices. It dynamically selects the best base station for
optimized sensor data traffic routing as well as the de-duplication of packets using the ADR (MAC) functionality.
The LRC exposes key interfaces to the network OSS for provisioning, administration and reporting purposes. It can
also be connected to several other key networking elements for secure key management services.

April 2016

All rights reserved

in collaboration with

25

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

LoRa devices architectures overview

A LoRa device is typically based on reference hardware architecture, as shown below:

Power
supply

MCU

LoRa
radio

Peripherals / sensors / IO /

Fig 29. Generic LoRa device architecture

Power supply may be provided through a power plug or a battery

The MCU is the microcontroller managing all device functionalities, and implementing the LoRaWAN stack
The LoRa radio is composed by the LoRa transceiver, the antenna matching circuitry and the antenna itself.
Peripherals may be sensors like accelerometers or temperature sensors, or I/O such as relay or display.

Depending on design and production constraints, several options are available to build a LoRa device:

Design based on a LoRa chipset

Design based on a LoRa module
Design based on a RF-MCU
Design based on LoRa modem
Existing device with external LoRa modem

The choice of the target architecture needs to be made based on criteria such as expected production quantities,
RF engineering skills available and the development timeline available to complete the project.
In order to select the optimal architecture, it is preferable to start with a LoRa starter-kit and create a mockup.

April 2016

All rights reserved

in collaboration with

26

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

The generic device software architecture can be described as below:

Application

My Temperature
Sensor

Middleware

LoRaWAN
stack

Power
management

Drivers

USB

UART

SPI

Analog

Fig 30. Generic LoRa device software architecture

The driver layer provides the hardware adaptation and implements all the drivers to manage the device
peripherals. It abstracts the hardware as simple functions exposed to the middleware.
The middleware implements the communication protocol libraries (LoRaWAN, 6LowPAN), it implements also
complex drivers like screen, GPS driver.
The application layer contains all functional applications where the device behavior and functionalities are
implemented.

3.1 Design based on a LoRa chipset

This design follows the generic architecture with the LoRa radio part based on the LoRa transceiver from Semtech
and the antenna plus associated circuitry from any vendor.
Power
supply

MCU

App

SX127x

LoRa
WAN

LoRa radio

Peripherals / sensors / IO /

Fig 31. LoRa chipset device architecture

In this architecture, the device developer must take responsibility for the entire RF design, including PCB routing
constraints, antenna tuning and emission/immunity issues.

April 2016

All rights reserved

in collaboration with

27

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

The entire LoRaWAN stack here must be managed by the main MCU, and implemented by the device developer
or manufacturer. The software architecture is explained in the chapter 4.5.

3.2 Design based on a LoRa module

A LoRa module is a component containing the MCU and the LoRa radio. The MCU is available for software
programming in order to run the application and the LoRaWAN stack.
The main benefit of this design approach is that all RF hardware development is implemented by the module
manufacturer.
The antenna tuning and matching is mostly done inside the module. The module manufacturer provides a
reference design to connect or redesign an antenna.
Power
supply

LoRa

MCU

App

module

LoRa
WAN

LoRa
radio

Peripherals / sensors / IO /

Fig 32. LoRa module device architecture

Compared to the previous architecture, as the MCU is available, the device manufacturer is only responsible for
the integration of the LoRaWAN stack. Depending of the module provider, the LoRaWAN stack may be delivered
as a library.

3.3 Design based on a RF-MCU

A RF-MCU is a SoC (System-on-Chip) including a MCU and a LoRa transceiver in a same silicon package. The RF
constraints remain the same as in previous RF design but this architecture offers major gains in overall device size.
From the developer point of view, this design is similar to a module.
As of today there are no existing SoC but ST-Microelectronics is preparing such a solution:
http://www.st.com/web/en/press/c2790.

April 2016

All rights reserved

in collaboration with

28

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

3.4 Design based on a LoRa modem

A LoRa modem is a component containing all the radio related components: stack + RF circuitry.
Some modems may also include an integrated antenna, or a reference design is provided by the modem maker on
how to design or connect an external antenna.
The modem integrates the entire LoRaWAN stack and acts as a slave so it requires a host in order to manage it.
The communication is usually done through AT commands to configure it or to send messages.
The hardware interface could be usually an UART, USB or SPI.

MCU
host

Power
supply

App

LoRa
LoRa
WAN

modem

Peripherals / sensors / IO /

Fig 33. LoRa modem device architecture

Several manufacturers propose a LoRa modem such as Microchip RN2483, Multitech or also ATIM.

3.5 Existing device with external LoRa modem

A LoRa modem can also be an external stand-alone device, connected to an existing device through a USB
connection for example.
In that case, the existing device must have an available external connection and also be able to power the
external LoRa modem.
The modem integrates the entire LoRaWAN stack and acts as a slave so it requires a host in order to manage it.
The communication is usually done through AT commands to configure it or to send messages.

LoRa
Existing Device

LoRa
WAN

modem

App

Fig 34. LoRa external modem architecture

April 2016

All rights reserved

in collaboration with

29

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Development and integration of a LoRa device

4.1 Architecture selection

The choice between a homegrown design and a module or modem based architecture is mostly done depending
on the following parameters:

Maturity of the device specifications: feasibility test phase, market test phase or mass production phase
Electronic and RF development skills
Budget for development
Project timeline
Expected quantities and expected market price
Software development resources availability
RF region (ISM band)

The ISM band where the device will be deployed will impact the architecture as the antenna matching and the
antenna itself must be tuned to fit the correct frequency band. The module and modem architecture, which
already includes the RF part, will specify in which band it is available.
In terms of a project timeline, the key tasks to be estimated are:

Feasibility study, is dev-kit available with the target architecture?

Design specifications
Schematics
PCB routing
Software development
Proto v1 debug - If modification are needed: Proto v1 review (schematics + routing)
Manufacturing test bench development + test software

4.2 Antenna design

The antenna is a critical part in a communicating device and such a device where the sensitivity is a major issue in
the LoRa technology.
In the 868MHz band, a /4 antenna is 8.2cm length, so depending on the product this has to be taken into
account during the mechanical design to place correctly the antenna to avoid closed disturbance from the
product itself.
There are 3 typical antenna architectures:
A dedicated OEM antenna tuned for the LoRa frequency: this solution is the easiest one as the dedicated
antenna is the perfect fit to achieve the best results in terms of transmission and sensitivity. However, this
solution is the most expensive.
A PCB-Antenna which is a simple trace on the circuit however parameters like copper width and thickness
must be taken into account during the antenna design.
A simple quarter wave wire antenna (/4 length) could be the easiest implementation. The main challenge is
to ensure repeatability in its production and to deliver the correct antenna length on every product. Such
design must also have a correct mechanical part to maintain the wire properly inside the product in order to
ensure a consistent RF performance on all manufactured products.

April 2016

All rights reserved

in collaboration with

30

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Several antenna design examples are shown below:

PIFA antenna

http://www.semtech.com/images/datasheet/AN1200.20SARANT_V1_0_STD.pdf

Helical Wire Antenna

Miniature Helical PCB Antenna

http://www.ti.com/lit/an/swra161b/swra161b.pdf

http://www.ti.com/lit/an/swra416/swra416.pdf

4.3 Device autonomy

Device autonomy requirements must be taken into account before hardware and software development phases
as both may have a huge impact on power consumption.
From the hardware point of view:

Choice of the MCU

Choice of the battery and its power management
Hardware issues (pull-up and pull-down resistors, pins not connected, mA leak inside components)
Sleeping mode of peripherals

In order to estimate the lifetime of a battery, 5 major consumption modes must be known:

Sleeping: everything is OFF or sleeping

Idle: everything is sleeping except the MCU
Running: the device is awake and running its functionalities
LoRa Tx: the device is sending a data
LoRa Rx: the device is listening or receiving a data
April 2016

All rights reserved

in collaboration with

31

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Once each of these 5 power modes are known, the developer needs to estimate how long the device will stay in
each mode to calculate the average power consumption per hour. It is highly recommended to consider worst
cases in the calculation, for example SF12 for LoRa messages duration.
With this approach it will be possible to estimate the battery capacity due and the expected lifetime of the device.
Semtech provides a tool that can help with fast evaluation of link budgets, time on air and energy consumption of
SX1272 transceiver. It can be downloaded at http://www.semtech.com/wireless-rf/rf-transceivers/sx1272/
Below is an example of power consumption measurement during transmission and reception phases:

RSSI probe
11ms M3
MCU
processing

47mA at
14dBm
10.6mA Rx
current

Actility Confidential Under NDA

Rx slot 1
5 symbols
@SF12

Rx slot 2
5 symbols
@SF9

Fig 35. LoRa device consumption diagram

April 2016

All rights reserved

in collaboration with

32

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

4.4 Integration and development

The first entry point for a device maker is a starter kit that comprises of a development board with connectors for
sensors or other peripherals, and the Lora radio board. The key idea of a starter kit is to quickly add LoRa
connectivity to a development kit. In the starter kit the LoRaWAN stack is ready and offers a simple API to send a
message.
Orange proposes a ready-to-use starter kit using LoRaWAN modem architecture, with Grove connectors to
connect sensors easily and also an Arduino shield connection to receive a shield extension. An external battery is
also included so a final application can be tested very quickly from the data capture to the application with LoRa
connectivity.
Website: https://partner.orange.com/orange-kit-for-iot/

Actility provides as well wireless developer kits with or without base station bundles. The picture below is an
example of a ThingPark Wireless developer kit including developer libraries available on the ARM mBed platform.
Website: https://developer.mbed.org/teams/Actility/code/LoRaWAN_actility/

April 2016

All rights reserved

in collaboration with

33

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

4.5 Software development

The software development project depends on the hardware architecture chosen for the device.
The easiest case is the LoRa modem architecture: the whole LoRaWAN stack is already implemented inside the
modem and the communication is managed by itself. The developer only needs to implement the initialization of
the stack to be able to easily send or receive messages.
With the module architecture, the module manufacturer may provide a ready to use LoRaWAN stack
implementation fitting the integrated module MCU. In such a case, the developer has an API with commands to
initialize and manage the LoRaWAN stack.
If a LoRa chipset integration approach is chosen, or in case no LoRaWAN stack is provided with the selected
module, the developer will have to implement the LoRaWAN stack inside its software. A LoRaWAN stack is
available and maintained by StackForce, available here: https://github.com/LoRa-net/LoRaMac-node.

4.6 Software application layer

When an end-device needs to communicate with multiple applications, there is a need to use a published syntax
for applicative messages.
A possibility would be to use the ZigBee Cluster Library (ZCL) syntax, which has been defined by the ZigBee
Alliance for the application layer (APS) of ZigBee, and appears to be a good compromise between functionality
and complexity. The ZCL should not be confused with the mesh networking and physical layers of ZigBee, which
are not used.

4.7 Test application

A test application is a test mode inside the application. It is needed and very helpful for several reasons:

Test during development

Inter-operability with a LoRaWAN Network Server
LoRaWAN certification (LoRa Alliance)
End-Of-Line manufacturing test

The test mode can be activated through a specific command on a dedicated FPort. Then the test mode is able to
check all available MAC commands and open a fast period communication with the server to check all message
type and integrity.

4.8 LoRa application best practices

The LoRaWAN protocol offers several helpful key features during end-to-end application integration. Here are a
few guidelines for device makers based on these features:
FPort: several application ports available for data, for example it could be used to send each data on a
specific port to a dedicated final application. These several application ports give also the capability to
choose a different AppSKey per port (in ABP only).
ADR and maximum payload length: due to the ADR and to the Spreading Factor changed dynamically, the
maximum payload length is related to the Spreading Factor. In that case, the application must know in which
SF the message will be sent in order to know what is the maximum length authorized. The size limit of the

April 2016

All rights reserved

in collaboration with

34

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

payload in SF12 is 51 bytes. In order to maximize the efficiency of communications in all situations (whatever
the radio condition) we recommend using a size of 20 bytes at maximum.
Spreading Factor: Orange recommendation is to use the SF12 by default at device initialization in order to
maximize the efficiency of the communication, even under difficult radio conditions.
Repetition mechanism: we recommend the implementation of a repetition mechanism up to 3 transmissions
to increase significantly the radio performances.
Duty cycle: as the LoRa network is operated over ISM band, it is under regulation with a maximum duty
cycle. The good practice is to develop the application depending on a respectable behavior with the respect
of the duty cycle but not develop the application in order to fit exactly the maximum authorized duty cycle.
The purpose of the duty cycle is to provide a fair use for every transmitter (and not block the frequency for
too long time).
Channel selection: when the device selects the frequency to use among the channels proposed by the
network, we recommend implementing a random selection instead of testing the received channels one by
one following the exact received order.
Mobility: mobile devices need to implement a data rate adaptation algorithm. Unlike for fixed or slow
devices, the network will not provide consistent data rate information to mobile devices. Orange can support
you to select the best algorithm for your object.
JOIN procedure management: in order to increase security level on devices, Orange recommends that
devices generate a JOIN REQUEST regularly to trigger a JOIN ACCEPT message allowing them to regenerate
their network and application session keys.
Confirmed messages: back to the duty cycle issue, as the duty cycle is per emitter, the gateway has also its
maximum duty cycle in emission so each downlink messages (from network to devices) has a cost in the
gateway duty cycle for every device. Please note that the confirmed mode is not available by default for
uplink messages (from devices to network), devices will need to use Unconfirmed mode for uplink messages.
SF adaptation: so as to adapt the SF when no downlink message is received by the device, the
ADR_ACK_LIMIT parameter can be used. The value of this parameters sets the number of uplink messages
(without downlink answers) sent before a downlink message is requested by the device. The ADR_ACK_LIMIT
needs to be set on 64.

4.9 Production parameters

Some parameters are mandatory to register a device on the Orange network, a few are related to the device
manufacturer and others are coming from Orange.

Activation-By-Personalization (ABP):
ABP

Who?

What is it?

DevEUI

IEEE

DevEUI is not used in LoRa communication in ABP but is

used to identify the device at the Network Server side

DevAddr

Orange

The DevAddr is the Device Address on the LoRa Network

NwkSKey

Device manufacturer
OR
Orange

The NwkSKey encrypts the data during the transmission.

Gateways from other networks cannot see the content of
messages. The NwkSKey authenticates the device on a
LoRa network

AppSKeys

April 2016

All rights reserved

in collaboration with

35

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Notes:
The unicity of a device in a LoRaWAN network is based on the combination of DevAddr and NwkSKey
It is mandatory to generate a random NwkSKey per device during manufacturing and to not use the same
NwkSKey for every device.

Over-The-Air Activation (OTAA):

OTAA

Who?

What is it?

DevEUI

IEEE

The DevEUI identifies the device on the LoRaWAN

network during the JOIN request

AppEUI

IEEE

The AppEUI identifies the application during the JOIN

request

AppKey

Device manufacturer

The AppKey encrypts the data during the JOIN request

The DevEUI or AppEUI is a unique IEEE MAC addresses. Each device manufacturer must purchase an address block
to IEEE. There are 3 available ranges from IEEE:
MAC-L: http://standards.ieee.org/develop/regauth/oui/
MAC-M: http://standards.ieee.org/develop/regauth/oui28/index.html
MAC-S: http://standards.ieee.org/develop/regauth/oui36/index.html
For LoRa modems, the manufacturer should already have a range of addresses and then each modem should be
delivered with its pre-defined DevEUI.

4.10 Manufacturing tests

Every device RF performance must be tested after assembly in order to ensure compliance with applicable
regulation and to avoid any issue during deployment. It is particularly important to test the quality of antenna
matching, which may be performed by implementing the following checks as part of end-of-line test procedure:
Transmit one message from the device under test in 3 different channels at a specified output power: the
receiver must receive the 3 messages and must check the RSSI / SNR of these 3 messages which must be
measured within the limits pre-calibrated using a reference unit.
Receive 1 or several messages and check the RSSI at reception by device under test: it must receive the
messages and the RSSI must be measured within the limits pre-calibrated using a reference unit.
These checks ensure that frequency tuning and the antenna matching are correct.

4.11 Certification
Regulatory certification
Each device that is built and sold in the European market must obtain the CE mark, under responsibility of the
manufacturer. CE mark requirements depend on the device type. A LoRa device must be compliant at least with
ETSI EN 3002-220 series. Compliance may be tested by the manufacturer or by an independent laboratory.

April 2016

All rights reserved

in collaboration with

36

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Depending on product category, other certifications may also be required; for example in automotive or medical
fields. Devices operating in potentially explosive atmosphere must bear a specific ATEX mark. Devices connected
to the electric power lines must comply with directive 2006/95/CE.
During the RF tests that are part of EN 3002-220, the Effective Radiated Power (ERP) of the device is tested. This
measurement takes into account all loss inside the circuit and the antenna, and provides a radiation directivity
measurement for the product.
For most sensors designed for indoor use, an omnidirectional pattern is optimal. For outdoor sensors, directive
antennas with high gain may provide better results, especially in the downlink direction.

Fig 36. ERP diagram

Another important RF test, not part of EN 3002-220, is to qualify the sensitivity of the reception path of the
device. LoRa is a high sensitivity technology, and the public network dimensioning assumes that deployed devices
have a radio receiving performance in line with the technology capabilities. Sensitivity testing ensures that the
device will perform as expected in the LoRaWAN public network.

Orange Device Interoperability Certification

The Orange device interoperability test plan and processes enable LoRa device providers to validate the
performance of their devices in the Orange public LoRaWAN network environment.
For example, Orange LoRaWAN network may implement configuration parameters such as specific RF channel
frequencies or receive window timings.
In order to guarantee the performance of the service on its network, Orange may ask for results of ERP and
Sensitivity tests.

LoRa Alliance Certification

The LoRa Alliance proposes a LoRa Alliance Certification. Its goal is to confirm that an end-device meets the
Functional Requirements of the LoRaWAN Protocol Specification. A device manufacturer must become a member
of the LoRa Alliance to obtain a LoRa Certification. Once it is registered as a member of the LoRa Alliance, the
device manufacturer can contact one of the approved Test Houses to go through this certification process.
The test requires that the device implement the LoRa Alliance test mode. This feature will make it possible to
perform automated testing through LoRaWAN port 224. A set of test scripts will test the LoRaWAN specified
mandatory features such as:

April 2016

All rights reserved

in collaboration with

37

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Frame format and encryption

Timing of the end-device receive slots
Frequency hopping and data rate adaptation
Cryptographic implementation

LoRaWAN Network Platform Interoperability Certification

Actility is a LoRaWAN network platform and system provider that offers an end-to-end interoperability program
helping device and application developers to integrate and test their devices or applications with a production
network, and to validate the actual use case they aim to implement commercially (the LoRaWAN Certification
covers only the device performance in test mode). Actilitys Partner Interoperability Program and related testing
processes ensures that approved devices will work in all public networks using Actility ThingPark platform.

Other certification required from a device manufacturer

CE marking is under responsibility of the manufacturer:
For chipset designs, it is mandatory to test the device with a test lab certified in RF testing.
For module-based designs, it is up to the manufacturer to determine whether the way the module has been
implemented may change the RF performance. Any change of antenna should justify a new testing phase.
In cases where the LoRaWAN stack has already been integrated inside the modem or module and cannot be
modified by the application, the LoRaWAN certification may be performed faster, as only the configuration of the
stack will be verified.
Orange certification is mandatory for all types of LoRa object designs. If the object is based on a previously
certified module, then this certification is considered as already validated.
The three certifications levels available for Orange network may be resumed as below:
Object Design

LoRa Alliance certification

Actility certification

Orange certification

Chipset

Recommended

Recommended

Mandatory

Module

If Orange certified module:

not required
Else: recommended

If Orange certified
module: not required
Else: recommended

If Orange certified
module: not required
Else: mandatory

RF-MCU

Recommended

Recommended

Mandatory

Modem

Recommended

Recommended

Mandatory

External modem

Recommended

Recommended

Mandatory

The Orange LoRa certification is available since April 2016.

April 2016

All rights reserved

in collaboration with

38

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

4.12 Device life cycle

During the device operation, the device settings may be adjusted dynamically. For most sensors, the device
settings may impact the duty cycle, i.e. the number of messages sent by the device and the time on air. The
maximum time on air must always comply with applicable regulation. Orange is not limiting the number of
messages per day, provided the duty cycle is respected.
Due to the limited bandwidth of LPWA networks, most devices will not support Firmware updates over the air.
For such devices, firmware upgrades are performed by the manufacturer, or require special tooling. Some devices
may support USB or Bluetooth upgrades.

April 2016

All rights reserved

in collaboration with

39

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

Project use cases examples

Below are some typical examples of existing devices that may be improved by migrating to LPWA technology.

Migrating existing Industrial ISM band devices (e.g. wM-Bus) to LoRaWAN

The ISM band ecosystem has generated many popular application layers which have been optimized for specific
applications. Typical examples are the ZigBee Cluster Library (ZCL) used in general purpose automation devices,
Wireless M-Bus for water or gas metering, KNX for building automation, and ModBus for industrial automation.
These application layer standards have generated a huge and mature ecosystem. Device developers may seek to
leverage the performance of LoRaWAN LPWA networks without replacing the entire application layer. The good
news is that this is usually possible, and quite straightforward: the LoRaWAN standard may carry any payload,
including the binary PDU of higher levels application layers.
For example the ZCL application frame of a ZigBee device may be transported over LoRaWAN, instead of the
ZigBee-Pro meshed networking stack, in order to serve long range or public network use cases not addressed by
the standard ZigBee network layer.
A Wireless M-Bus device can be converted to a LoRaWAN device by changing only its physical layer and carrying
the wM-Bus application layer frame as payload of the LoRaWAN packet. This is usually possible by changing the
wM-Bus radio module to a LoRaWAN radio module, and will typically achieve much longer communication range.
wM-Bus 868MHz may also reuse the same antenna (wM-Bus 169MHz devices will need to switch to 868MHz to
be used over public LoRaWAN networks).
The LoRa Alliance is working on standard encapsulation profiles for popular M2M and metering protocols.
Keeping an existing application layer allows to keep intact most of the firmware and ecosystem, facilitating
migration to LPWA.

Migrating existing consumer ISM band devices to LoRaWAN

Many consumer connected devices use short-range radio such as Bluetooth Low Energy or Wi-Fi. Some of the
questions listed below can help assess the potential benefits of migrating a BLE or Wi-Fi devices to LoRaWAN:

Does the device application or use case require high data bandwidth?
Does it require real time communication with a smartphone?
Should it be able to connect to Internet without support of a local bridge (smartphone or internet box)?
Would the device use cases be enhanced by lower power consumption or wider connectivity coverage?

With this in mind, it appears that many different types of consumer connected devices could benefit from
LoRaWAN connectivity, for example:
Internet buttons, currently connected with Wi-Fi to a home internet box
Connected smoke detectors, currently using WIFI, connectivity which should be able to stay connected even
when no WIFI network or power supply is available
Remote home gardening sensors usually connected through Bluetooth to a smartphone
Personal key-ring Bluetooth tracker, which works only when they are in range of their smartphone
All type of people, pets or personal assets trackers
As Bluetooth and Wi-Fi operate in 2.4GHz band, wearable devices are often built with a simple chip and small
antenna design. Moving these form factors to LoRaWAN requires fitting a longer antenna in a small footprint, and

April 2016

All rights reserved

in collaboration with

40

LoRa Device Developer Guide

Orange Connected Objects & Partnerships

still keeping good RF performance. This technical challenge can be met fairly easily provided that LoRa antenna
design is integrated into the device architecture at the beginning of the overall product design thinking process.

April 2016

All rights reserved

in collaboration with

41

Thank y u