The essential requirements listed insection 3 were met. Uplink transmissions from all networks are received by Thingsboard without regard for their origin. End-node networks can currently be identified by their names in Thingsboard, as each network has a different way of displaying the unique identifiers. Downlink transmissions are possible in all networks, but rate limiting of downlinks for all networks is not in-cluded in this implementation. All used communication modules may enter their own low-power modes, and the power consumption of the modules are all under 25 µA. The output of the LPWAN-agnostic layer is JSON including the name of the physical quantity, and the data object form for both up- and downlink messages can be modified as required. The authentication and authorize requirement is imple-mented in both directions for all networks, with Sigfox and LoRaWAN relying on ready-made specifications and implementations and the NB-IoT network using the custom implementation. The anti-eavesdropping requirement is partially fulfilled.
Messages can not be eavesdropped on in any IP networks, and the payload contents are unencrypted only on the Sigfox network.
The LPWAN-agnostic layer in it’s current state generates value as it enables a
streamlined approach for developing end-nodes and their software on any of the three LPWANs. It enables end-node application developers to use a consistent API for most types of sensor nodes, resulting in faster future development cycles. The integration of the layer into the Thingsboard application allows thorough manual and automated data analysis regardless of the LPWANs in use.
Future improvements could include transitioning to use of OSCORE for NB-IoT au-thentication and an analysis of further integration of the LPWAN-agnostic layer to the LoRaWAN server and Sigfox backend. The objective of OSCORE is roughly the same as of the custom implementation built for this thesis. An benefits OSCORE in-tegration could yield benefits for all parties involved in the development of OSCORE.
The Sigfox backend and the LoRaWAN server both offer many more APIs than used in this thesis, and they may allow adding device provisioning or make more data on current end-node performance available to the IoT application.
5 Discussion
The goal of this section is to provide insights gained from the reviewed literature and the thesis implementation.
5.1 General
Sigfox, LoRaWAN and NB-IoT all aim for multi-year battery lifetimes and multiple kilometres of range, but the technical specifics on how the goals were aimed to be achieved differ greatly. Sigfox and LoRaWAN both utilize the 868 MHz band in Europe, while NB-IoT is operated in the licensed spectrum of Mobile Network Op-erators (MNOs). This may have a large impact once the number of deployed IoT end-nodes truly grows to the levels predicted that some predict. Sigfox and LoR-aWAN, operating in unlicensed bands will suffer decreased performance compared to today. A common way to get around the duty-cycle limits of the ISM band, used for example in The Things Network, is to deploy more devices. On one hand, this may allow for gateways with smaller ranges, more dense deployments and thus decreased noise. On the other hand, deploying more devices can further use up band capacity if used to enable more data throughput through a LPWAN.
In many instances it would be useful to leak the abstraction of the underlying LP-WAN by allowing knowledge of the LPLP-WAN used to propagate to the application server. Take, for example, sending a multiple kB downlink message to a single end-node. If the server-side business logic had knowledge of which LPWAN was being used, it could send this type of downlink message when it knows the device was using NB-IoT. Purposefully leaking the abstraction does bring about much higher complexity to the application, and it goes against the concept of abstraction. If the objective is to maximally exploit the capabilities of the more flexible networks, NB-IoT and LoRaWAN, the developed application must be tailored to each of these networks. For developing LPWAN-connected end-nodes which infrequently perform an update of sensor data to the application server, fully LPWAN-agnostic data links successfully provide a key abstraction to facilitate fast deployments in the future.
The NB-IoT and LoRaWAN networks capabilities, especially downlink ones, are limited to what can be supported by the Sigfox network. On one hand such a limitation effectively caps the possibilities of the LoRaWAN and NB-IoT networks, but on the other hand an application requiring more data throughput should not
Feature Status in Sigfox Receiving FOTA updates Not possible Transmitting Images / Audio Not possible Receiving simple ML models Possible Receiving complex ML models Not Possible
Uplink frequency Up to 140 / 24h
Downlink frequency Up to 4 / 24h Connectivity to Application Server HTTPS Callbacks
Downlinks receivable 20 seconds following uplink Table 8: Summary of Sigfox application capabilities.
include Sigfox in the LPWANs used, and perhaps could rely on only NB-IoT and LoRaWAN. This LPWAN combination also happens to be supported by LwM2M V1.1, so it may be a combination which will be seen in use in the future.
A data serialization scheme such as Cayenne LPP with pre-defined binary repres-entations of application-level objects, such as specific types of sensors and actuators, reduces payload sizes the most and was chosen for the implementation. The limita-tions of this approach are in the fact that application-level objects that haven’t been defined in both the sender and receiver can not be represented in any payload. For functionally simple, low cost end-nodes such as sensors and actuators, the Cayenne LPP format or an equivalent one covers the bulk of required tasks.
5.2 Sigfox
The Sigfox network adheres to simple principles – Don’t send much data, don’t send it often, and you’ll be offered simple and energy efficient LPWAN connectivity for the monthly subscription cost. As can be seen in table 8 on page 43, Sigfox end-nodes set hard limits on the guaranteed maximum performance of an LPWAN-agnostic data link using the three LPWANs discussed in this thesis. Without the application server having knowledge of which node uses which connectivity, it should assume it is limited to four downlink messages of 8 bytes each per day. For uplink connectivity, following the limits is up to the end-node, and so the application server doesn’t need to limit received uplinks.
The maximum uplink payload size limits valuable data transfer to individual sensor values, or already processed, synthetic sensor outcomes using edge computing. In
Security Issue Summary
Connectivity abuse Very low potential Data error checking Yes
Data confidentiality On air: No, optionally
On IP network: Yes, HTTPS supported Forging data Not possible
Replaying data Not possible
Table 9: Summary of the security on the Sigfox network.
order to allow for maximal application value generation, any results must be encoded in a compact manner. This is achieved in the implementation by using a format with a very heavy schema. Since Sigfox is the only network with unencrypted on-air payloads, this has the benefit of making it less obvious what an end-node is measuring or doing.
With the Sigfox backend requiring a downlink response within 20 seconds, the ap-plication server must be able to respond fast, and queue downlink transmissions.
The 12-bit authenticated sequence number used by the Sigfox network provides basic replay protection. The limits in table 2 allow for 10 days (One tier) or 3 days (other tiers) of no reception with only a warning provided once connectivity is restored. Since the sequence number repeats every 4096 messages, a malicious party with packet captures of old transmissions could upset connectivity for Sigfox end-nodes. For a Sigfox Platinum subscribed device, transmitting 144 uplinks a day, a message replay could be achieved in under 29 days of the devices first transmission.
Theoretically, transmitting a continuous stream of old packets could completely block a legitimate Sigfox end-node from the network. This is because the Sigfox network should not accept a new packet with the same sequence number as one just received.
The Sigfox Networks approach to link security is summarized in table 9 on page 44. The Sigfox LPWANs security weaknesses are limited to unencrypted payloads that can be eavesdropped on, and a theoretical possibility of an attacker replaying messages previously sent by the end-node after a full sequence number cycle.
Feature Status in LoRaWAN Receiving FOTA updates Possible
Transmitting Images / Audio Not possible Receiving simple ML models Possible Receiving complex ML models Possible
Uplink frequency Depends on range, thousands / 24h for close ranges
Downlink frequency Depends on amount of end-nodes per gateway, hundreds / 24h for close ranges.
Connectivity to Application Server HTTPS Callbacks, MQTT, Web-Sockets [14], [26]
Downlinks receivable Queued, any time [14], [26]
Table 10: LPWAN application features possible with LoRaWAN.
Security Issue Summary
Connectivity abuse Very low potential Data error checking Yes
Data confidentiality On air: Yes
On IP network: Yes, if trusted Network Server Forging data Not possible
Replaying data Not possible, possible in V1.0 [18], [75]
Table 11: Summary of security in the LoRaWAN network.
5.3 LoRaWAN
The open LoRaWAN standard is a flexible protocol which can be tailored to fit a much larger array of applications than Sigfox. FOTA updates or other large down-link transfers to multiple end-nodes at once are not possible with Sigfox. Neither can more Sigfox gateways be installed in a specific location to allow more frequent data transfer to take place. As table10presents, these are both possible with LoRaWAN.
In order to be used together with Sigfox as an LPWAN-agnostic data link, some features that LoRaWAN offers must be stripped down to what is offered in Sigfox.
End-nodes should communicate to the LPWAN-agnostic data link via LoRaWAN Class A, as it features the same functionality, and enables low power end-nodes.
Downlink communication must be limited to a maximum application packet size of 8 bytes, and can be guaranteed only according to the limit of the Sigfox network.
LoRaWAN has a thorough approach to network security, using two different
encryp-tion levels to allow routing without the router knowing the applicaencryp-tion-level contents of the packet. The LoRaWAN network is disconnected from the IP network, as the LoRaWAN Network and Application Servers (not the same as an enterprise ap-plication server) only forward messages to and from end-nodes which they know.
The standard encrypted communication standards of HTTPS and MQTTS provide simple and secure interfaces to upstream enterprise application servers. The thor-oughly firewalled approach leads to low abuse potential of the end-node in the IP domain, presented in table 11on page 45.
LoRaWAN is the only LPWAN examined for which you can build your own private network. The LoRa gateways with which it can be implemented can be had for under 200e. For use-cases in need of good indoor coverage of an area, for example a factory site, a private LoRaWAN network may be a reasonable investment.
5.4 NB-IoT
Similar to LoRaWAN, NB-IoT provides many ways to utilize the cellular network to provide low-cost and energy efficient communication. However, for extreme low energy use, NB-IoT uses PSM in a similar asynchronous data transfer scheme to Sigfox and LoRaWAN. End-nodes that connect to an LPWAN-agnostic server should enable PSM in order to maximize battery life.
Assuming the sent data can be fit into Control Plane packets, data should be trans-ported using Control Plane data transfer, which must be configured via an SCEF.
This should allow for more efficient communication between the core network and the end-node, leading to better battery life.
The application possibilities of NB-IoT are listed in table 12. As can be seen, NB-IoT offers the most possibilities for LPWAN usage. Even though it allows for much larger transfers, regular large transfers will come at the cost of reduced battery life.
The capability to transfer larger payloads should be used for functionality that is not invoked daily, like firmware updates.
If communicating to the end-node via the SCEF there is no reduction in battery life for a secure approach. The security model of NB-IoT communication when configured via SCEF is very similar to the ones used by Sigfox and LoRaWAN, as the application server can use standard HTTPS encryption when communicating with the core network. A summary of NB-IoT security when operating via the SCEF is presented in table13. The thesis security objectives would be achieved when using
Feature Status in NB-IoT Receiving FOTA updates Possible
Transmitting Images / Audio Possible Receiving simple ML models Possible Receiving complex ML models Possible
Uplink frequency Limited only by energy available and subscription
Downlink frequency Limited only by energy available and subscription
Connectivity to Application Server Direct IP connections from end-node or IP from Gateway (SCEF Configured) Downlinks receivable Receivable according to adjustable
PSM frequency, Single message queued Table 12: LPWAN application features possible with NB-IoT.
Security Issue Summary (SCEF) Summary (IP) Connectivity abuse Low potential Medium potential
Data error checking Yes Yes
Data confidentiality Yes Yes
Forging data Not possible Not possible Replaying data Not possible Not possible
Table 13: Summary of NB-IoT security issues when used via the SCEF and via IP (OSCORE, DTLS or TLS).
a correct implementation of the SCEF for communication with end-nodes.
SCEF support is not, however, available from Finnish mobile network operators as of the end of 2018, so a live SCEF implementation could not be examined in this study. When using NB-IoT without SCEF an end-node is a fully IP-connected node and can potentially initiate and receive connections directly from any IP service. In this case there is not necessarily any externally configurable firewall, but end-nodes using the asynchronous uplink mode of connectivity may rely on the fact that they are only vulnerable for the short duration when they connect to the IP network, and only connect to pre-determined hosts.
Table13on page47presents a summary of NB-IoT security when used via IP. Since NB-IoT end-nodes may be configured to directly contact external IP servers, and may allow updating of firmware OTA, the security of NB-IoT devices requires a more thorough approach than the other heavily firewalled approaches.
A TLS-PSK cipher suite used for DTLS or TLS should result in significant battery life improvements over most other TLS cipher suites, as the client does not need to download the possibly large server certificate. UDP and thus DTLS should be preferred over TCP and TLS, as UDP allows for less total back and forth communic-ation. OSCORE seems to be an even better fit for NB-IoT end-nodes with regards to energy usage. Pre-shared keys can be provisioned in a controlled environment, and from then on can provide secure communication between end-node and server. Un-fortunately, there is currently only one open source C implementation of OSCORE, possibly due to it’s current draft status. The implementation is a fork of the Con-tiki OS project with OSCORE support built-in [76], and not a platform-agnostic OSCORE library.