LoRa is a proprietary wireless data communication technology developed by Semtech, for use in different unlicensed frequency bands worldwide. The technology consists of a patented chirp spread spectrum (CSS) type modulation scheme and allows for configurable data rates. LoRaWAN is an open source medium access control (MAC) layer built on top of LoRa, defined by the LoRa Alliance consortium. LoRaWAN offers a bidirectional link between endpoint and gateway. [8]
2.5.1 Architecture
The architecture of a LoRaWAN system is depicted in figure3. Endpoints broadcast to LoRaWAN gateways, which transparently forward the received messages over TCP/IP to their configured LoRaWAN network server. The network server then filters unwanted or duplicate packets. This architecture is said to simplify network access for end nodes, and move all the complexity to the network server. [2]
LoRaWAN Application Servers provide part of the LoRaWAN functionality, and these are not necessarily the same as the enterprise application servers which are referred to as just application servers outside this chapter. The LoRaWAN Applic-ation Server can forward data to an enterprise applicApplic-ation server which implements business logic [14].
IEEE Wireless Communications • October 2016 64
The gateways relay messages between the end devices and the NetServer according to the protocol architecture represented in Fig.
2. Unlike in standard cellular network systems, however, the end devices are not required to associate with a certain gateway to get access to the network, but only to the NetServer. The gateways act as a sort of relay/bridge and sim-ply forward to their associated NetServer all successfully decoded messages sent by any end device, after adding some information regard-ing the quality of the reception. The NetServ-er is hence in charge of filtNetServ-ering duplicate and unwanted packets, and of replying to the end devices by choosing one of the in-range gate-ways, according to some criterion (e.g., best radio connectivity). The gateways are thus total-ly transparent to the end devices, which are logically connected directly to the NetServer.
Note that current full-fledged LoRa gateways allow the parallel processing of up to nine LoRa channels, where a channel is identified by a spe-cific sub-band and spreading factor.
This access mode greatly simplifies the man-agement of the network access for the end nodes, moving all the complexity to the Net-Server. Furthermore, the end nodes can freely move across cells served by different gateways without generating any additional signaling traf-fic in the access network or the core network.
Finally, we observe that increasing the number of gateways that serve a certain end device will increase the reliability of its connection to the NetServer, which may be interesting for critical applications.
LoRa Device Classes: A distinguishing feature of the LoRa network is that it envisages three classes of end devices, Class A (for All), Class B (for Beacon), and Class C (for Continuously listening), each associated with a different oper-ating mode [17].
Class A defines the default functional mode of LoRa networks, and must be mandatorily supported by all LoRa devices. In a Class A net-work, transmissions are always initiated by the end devices in a totally asynchronous manner.
After each uplink transmission, the end device will open (at least) two reception windows, wait-ing for any command or data packet returned by the NetServer. The second window is opened on a different sub-band (previously agreed on with the NetServer) in order to increase the resilience
against channel fluctuations. Class A networks are mainly intended for monitoring applications, where the data produced by the end devices have to be collected by a control station.
Class B has been introduced to decouple uplink and downlink transmissions. Class B end devices, indeed, synchronize with the NetServer by means of beacon packets, which are broad-cast by Class B gateways and can hence receive downlink data or command packets in specific time windows, irrespective of the uplink traffic.
Therefore, Class B is intended for end devices that need to receive commands from a remote controller (e.g., switches or actuators).
Finally, Class C is defined for end devices without (strict) energy constraints (e.g., connect-ed to the power grid), which can hence keep the receive window always open.
LoRa MAC: The medium access control (MAC) layer, according to the LoRaWAN spec-ifications [17], is basically an ALOHA protocol controlled primarily by the LoRa NetServer. A description of the protocol is beyond the scope of this article and can be found in [17]. Overall, the LoRa MAC has been designed attempting to mimic as much as possible the interface of the IEEE 802.15.4 MAC toward the higher layers.
The objective is to simplify the accommodation, on top of the LoRa MAC, of the major protocols now running on top of the IEEE 802.15.4 MAC, such as 6LoWPAN and Constrained Application Protocol (CoAP). A clear analogy is the authen-tication mechanism, which is taken directly from the IEEE 802.15.4 standard using the 4-octet message integrity code.
LoRa IP Connectivity: LoRaWAN employs the IEEE 64-bit extended unique identifier (EUI) to automatically associate IPv6 addresses with LoRa nodes. Therefore, IPv6/6LoWPAN protocols can be deployed on LoRaWAN net-works, thus enabling transparent interoperability with the IP-based world.
Security in LoRa: Security aspects are taken into account in the LoRaWAN specifications as well [17]. Several layers of encryption are employed, using:
• A unique network key to ensure security at the network layer
• A unique application key to ensure end-to-end security at the application layer, and finally
• A device-specific key to secure the joining of a node to the network.
Figure 3: The architecture of a LoRaWAN system from end-node to Network Server [2].
Each Lorawan device and application is addressed by a unique 64-bit identifier, known as DevEUI and AppEUI, respectively. The standard allows activating end-nodes with the network in two ways, via Over-The-Air-Activation (OTAA) or via Activation By Personalization (ABP). ABP requires the device to be pre-loaded with personalized credentials, while OTAA bootstraps the authentication from non-personalized credentials, so that all produced end-nodes may have identical firmware.
2.5.2 Transmission and End-node Specifics
LoRaWAN’s maximum payload size for both uplink and downlink transfers is between 51 bytes and 222 bytes, depending on the spread factor used [15]. The spread factor of LoRaWAN determines the resulting Data Rate used [16], and affects the range [17]. Transmissions with different data rates do not interfere with each other [17], [18]. In addition to predetermined data rates the network can also adjust data rates automatically [19].
The LoRaWAN standard specifies three seperatedevice classes of end-nodes, map-ping to different operating modes: Class A(for All),Class B (for Beacon) andClass C (for Continuously listening) [18]. These allow trading battery life for increased connectivity.
Class A is the default operating mode for all LoRaWAN devices, and as such im-plementing it is mandatory. Data transfer is always initiated asynchronously by end-node as an uplink, after which the end-node must open two receive windows.
The receive window start delays must be set to the same values in both end-node
and network server. Class A enables the lowest power consumption, and is intended for devices that only require downlink data transfer immediately following an uplink transfer. Asynchronous downlinks can be cached until the next scheduled uplink.
[18]
Class B end-devices allow more downlink receive slots in a synchronous manner at the price of higher power consumption. At pre-determined times, the end-node turns on it’s radio to open a receive window. To keep the end-node synchronized with network time, it also wakes up to open a ping slot when it roughly expects one. The time between downlink application data transmissions, called the beacon period, is adjustable from 0.96 to 122.88 seconds. Transition decisions from Class A to Class B are left to the application layer of the end-device, not the LoRaWAN layer. This means that for the server to turn on Class B operation of an end-node, it must wait for the Class A uplink, and only then send it’s downlink. Class C devices constantly listen for new transmissions, and have the lowest latency and highest power consumption out of all Classes. They are specifically intended for applications with ample power to use, and are not further described in this thesis.
[18]
In addition to downlinks to a specific device, both Class B and Class C devices can simultaneously receive the same message by so-called multicast downlinks, where a group of devices temporarily share the same LoRaWAN encryption keys [18]. This notably allows LoRaWAN devices to implement large downlink transfers such as firmware OTA updates despite their limited payload sizes and duty cycle limitations [20].
Devices from both Class A and Class B enable power consumption low enough to enable battery powered devices [18]. Much like Sigfox, LoRaWAN achieves its lowest power consumption when used in an application with mainly asynchronous uplink data transfer. Its usable payload sizes provide space for simultaneously transmitting GPS coordinates and other sensor data [5], but can not be reasonably used to send raw audio or video data [15].
The LoRaWAN specification must follow local regulations, and in the EU 863-870 band devices must adhere to the duty cycle limits specified in the ETSI EN 300 220-2, as shown in table 3 on page 13. To maximize allowed air-time, an end-node would utilize different channels in order to increase its maximum duty cycle. For example, a specific LoRaWAN may use both the 868.0 – 868.6 MHz and 869.7 – 870.0 MHz band, with a 1 % duty cycle limit each, together in order to increase
its total effective duty cycle limit to 2 %. Some LoRaWAN modules such as the RN2483 allow the user to specify duty cycle limits in order to ensure regulatory compliance.
Frequency, MHz Limit, % 863.0 – 867.0 0.1 868.0 – 868.6 1 868.7 – 869.2 0.1 869.4 – 869.65 10 869.7 – 869.9 1
Table 3: EU863-870 ISM band duty cycle limits. [21]
The duty cycle limits of the used frequency bands determine the maximum allowed amount of transmissions per day from the gateway and the end-node. Using the lorawan_toaprogram [22] which is based on the formulae given in the LoRa Modem Design Guide [23], it is possible to calculate practical transmission frequency limits.
In order to send a LoRaWAN application payload of 10 bytes on LoRa spread factor 12 in an EU band, the Time On Air (TOA) used is roughly 1483 ms. Assuming a duty cycle of 1 %, the next transmission may occur 148.3 seconds after the beginning of the first transmission. The maximum amount of transmission per day for this example would be 582. Using the fastest spread factor of 7, the TOA would be under 62 ms, allowing for transmissions just over every six seconds. If using multiple EU sub-bands for communication, the transmission frequency could be still higher.
For LoRaWAN gateways, however, the situation is more complex. The gateway or network of gateways has the same duty cycle capacity as end-nodes do, and must serve both downlink data transfers and acknowledgements to uplink messages [15].
With up to hundreds of end-nodes for each gateway, downlink communication is scarce, and this must be taken into account by the application.
2.5.3 Security
LoRaWAN messages are encrypted on multiple layers using unique network keys, application keys and device keys [2]. This multi-layered approach makes it possible to transmit application payloads with end-to-end encryption, but still does not allow safe communication over a malicious Network Server [18]. LoRaWAN devices are not IP-connected, and can only communicate to IP networks via Network Servers,
which act as a similar strict firewall to the Sigfox networks backend system. To ensure data integrity, thePHY Payload contains a four byteMessage Integrity Code covering it’s other contents [18]. Additionally the Radio PHY layer utilizes a CRC for both the LoRa Physical Header and the whole PHY Payload [18].
The LoRaWAN network protects against replayed join attempts to the network by using a nonce in the join procedures. Regular data messages include a frame counter in the encrypted contents. Messages with the same frame counter repeated more times than agreed to by the end-node and network are ignored. [18]
2.5.4 Managing Power Consumption
LoRaWAN end-nodes can disable their radio interfaces in Class A and B operation in order to save power. The lowest overall power consumption can be achieved in Class A operation, where the devices radio interface is only activated once the device has data to transmit.
According to [16], LoRaWAN battery life is increased when using higher Data Rates (DR). This is because the higher bit rates allow for shorter transmissions. Power consumption was increased by a factor of up to 2.8 from DR 5 to DR 0 when using a five-minute uplink period. Decreasing payload size also decreased power consump-tion by a maximum factor of 1.59. The study also found that end-node power consumption was lower when using acknowledged transmissions. This, however was assumed to not be the case for all hardware and to depend on low bit error rates.
Since the LoRaWAN DR affects battery life significantly, it should ideally be the highest possible while ensuring no lost packets. A scheme with the objective to maximize battery life and overall network capacity is the Adaptive Data Rate (ADR) defined in the LoRaWAN specification [18]. The ADR is negotiated between the end-node and the network in order to optimize DR for signal strength and battery life in the current conditions.
LoRaWAN end-nodes may use Listen Before Talk, but it is not generally mandatory [15]. Under EU863-870 LoRaWAN uses duty-cycle limited transmissions, instead of the alternative Listen Before Talk Adaptive Frequency Agility, to comply with ETSI standards [17], [24]. This means that end-nodes in Europe may communicate immediately following their termination of a low-power state.
Analysis of LoRaWAN:s Medium Access Control layer indicates that with the massive amount of end-devices projected to be in use, there may be significant problems with
Feature LoRaServer Lorawan-server
HTTP Server Yes Yes
HTTP Client Yes Yes
MQTT Client Yes Yes
RX direct to database Yes, InfluxDB Yes, MongoDB
Websockets (RFC6455) No Yes
gRPC Yes No
AMQP 0-9-1 No Yes
Table 4: Comparison of most popular LoRaWAN network and application server connectivity. [14], [26]
collisions leading to reduced probability of messages being received [15], [25].
LoRaServer [26] and lorawan-server [14] are implementations of the Network and Application Servers for LoRaWAN. Both lorawan-server and LoRaServer implement-ations allow for queueing of messages from an external application backend, which the Sigfox backend doesn’t provide. Table4 summarizes the generally similar con-nectivity of the two implementations, with both supporting multiple connections to external servers and databases. Both LoRaServer and lorawan-server provide REST HTTP api’s for configuration and downlink data, can connect to external HTTP api’s and function as MQTT clients, allowing for up- and downstream com-munication.