Reception support for measurements aggregated from multiple devices was not re-quired at this stage, but in the future this may be an important way to optimize battery life without losing time resolution of measurements. Aiming for the pos-sibility of fully described units would be a good goal for making sure that the implemented system could be interfaced to applications which require explicit units.
SenML provides a well-specified way to implement both measurements aggregated over time and well-specified units.
With the achieved LPWAN-agnostic data connectivity, the application software can control device uplink and downlink frequency to optimize power consumption. For Sigfox and LoRaWAN the uplink period is defined only by when the device wakes up and transmits, but on NB-IoT end-nodes the PSM parameters have to be agreed upon between the end-node and the network. An application that makes use of PSM period adjustments should define how the end-node reacts if the network does not allow the it to use the desired PSM parameters.
The LoRa Server by brocaar supports some additional features compared to lorawan-server used in this implementation, like support for LoRaWAN V1.1, and all device classes defined in LoRaWAN. Due to similar API connectivity options, LoRa Server could be expected to work well in place of lorawan-server.
A similar approach to the concept studied in this work can be found in lpwan-server[77], which seems to aim to combine data processing from multiple LPWANs.
Currently it only has support for LoRaWAN, so it hasn’t yet achieved its goal.
The HTTP connector chosen within lorawan-server for interfacing to the LPWAN-agnostic layer has a higher overhead compared to eg. websockets, MQTT or AMQP, which are all supported by lorawan-server. Performance of LoRaWAN communica-tions could be significantly improved by using any of these, with websockets’ possibly better suited to the task, as it doesn’t require an external broker running.
If compared to DTLS or OSCORE, the security implementation used for NB-IoT in the LPWAN-agnostic layer does not provide as much protection. DTLS encrypts the whole UDP packet, while OSCORE encrypts the full request/response interactions of the client and server. The custom security implementation focuses primarily on authenticating the data, and leaves for example the UUID of the end-node, the requested URI path and response code in plain-text. This information is not expected to be valuable, but still presents a larger risk than what would be expected in OSCORE or DTLS.
6 Conclusions
The main objective of this thesis was to find out if and how battery powered end-nodes from the Sigfox, LoRaWAN and NB-IoT networks could communicate to a common cloud interface. The research sub-questions to be answered were on which technical common elements the LPWANs shared, whether the security of the devices and authenticity of data could be assured, and what limitations utilizing an LPWAN-agnostic approach would suffer from.
An LPWAN-agnostic application layer was found to be both possible and useful, combining communication from Sigfox, LoRaWAN and NB-IoT networks. The main limitations found were to do with downlink (to end-node) transmission frequency (4 per day) and payload size (8 bytes each).
Security and the Internet Protocols used for the NB-IoT network became a critical part of this study, as different implementations’ effects on projected battery life and required processor resources were significant.
6.1 Technical similarities
Sigfox and LoRaWAN end-nodes are non-IP devices, and always have gateway soft-ware to translate radio data to IP communication. NB-IoT is the most complex and flexible network out of the three, and utilization of NB-IoT contains an im-portant distinction in whether the NB-IoT network is used via a Service Capability Exposure Function or not. The SCEF is a component in the cellular core network which provides an externally accessible API to the operators network, and when it is used the NB-IoT network can function the same way as with Sigfox and LoRaWAN.
Unfortunately the SCEF is not supported by operators in Finland at the time of publication, so end-nodes must directly use IP protocols.
All LPWANs can operate in a common communication mode, using asynchronous uplink transfers (to network) and synchronous downlink transfers (to end-node). In this mode of operation, end-nodes keep their radios in a low-power mode until they have a message to transmit. Then the end-nodes may transmit the message without any measures to establish a connection, and then may listen for an acknowledge-ment of their message, or a data response from the network. In NB-IoT this mode of operation requires the network and the end-node to agree on the utilisation of the Power Saving Mode functionality, and the end-node should act as a client in order
to minimize network messaging. For Sigfox, asynchronous uplinks with synchronous downlinks is the only possible mode of operation, while LoRaWAN and NB-IoT are more flexible, and can also be set to be constantly listening to their network. Oper-ating based on asynchronous uplink connectivity the most energy efficient operOper-ating mode for all networks as it allows end-nodes to power on their radio only when it will be of use.
6.2 Security
The security properties against which the different networks were tested were:
• Connectivity can not be abused
• Data errors are checked for
• Data remains confidential on air and on IP systems
• Data authenticity
• No possibility of replay attacks.
The device connectivity in all networks when used as asynchronous-uplink sensor nodes can not be harnessed for unwanted activity or other misuse. NB-IoT and LoRaWAN devices have the possibility for Firmware Over The Air (FOTA) updates, but only NB-IoT end-nodes can connect to external IP services after a theoretical malicious firmware update. Data errors are checked for in all networks.
The three networks all allow for authentication and authorization of messages sent to and from end-nodes. Sigfox and LoRaWAN end-nodes operate as Non-IP devices, and can only communicate with network gateways. How these gateways are con-figured defines how the communication with a particular end-node is translated to the IP plane. Communication with end-nodes belonging to different deployments can be directed to different IP application servers, making both network function as if they are behind a very thorough firewall. Only authenticated and author-ized application servers may communicate with specific end-nodes in both networks, significantly reducing risk of attacks against end-nodes. If NB-IoT end-nodes are configured to only communicate via the operators SCEF, they also function as non-IP end-nodes. Non-non-IP NB-IoT end-nodes are authenticated and authorized by the network.
When communicating via IP, NB-IoT end-nodes must also authenticate the applica-tion servers and be authenticated by them. How this is implemented has significant effects on deployment security, battery life and end-node requirements. The fol-lowing only applies to IP end-nodes as clients in a client/server model. TLS and DTLS versions 1.3 and 1.2 fulfill the thesis security requirements energy-efficiently for IP traffic (DTLS 1.3 is still in draft status as of the end of 2018) when used with Pre-Shared Key (PSK) cipher suites. The most important feature of the PSK cipher suites is to enable reduced data traffic, and thus energy consumption, in the initial handshake messages. Other possible benefits of the cipher suites are to al-low for use of more resource-efficient symmetric cryptography and more simple key management.
CoAP is an application-layer protocol which is suitable for battery powered NB-IoT data. When using CoAP, data authentication and confidentiality can be achieved by implementing OSCORE, an IETF draft for secure CoAP communication. OSCORE is extremely light-weight, encrypts communication with a PSK, and is suitable for end-nodes constrained both in processor resources and energy. OSCORE is a signific-ant improvement over even DTLS 1.3 for these devices, but unfortunately OSCORE is currently lacking C/C++ language implementations.
On-air communication confidentiality is enabled by default in LoRaWAN and NB-IoT, but Sigfox is vulnerable to eavesdropping on messages as it does not encrypt them by default. Sigfox and LoRaWAN on-wire communication can be encrypted by HTTPS with no battery life decrease. NB-IoT communications can be kept confidential by using OSCORE, DTLS or TLS, in the order of least overhead to most overhead.
In the Sigfox network, the authenticated sequence number is used to guard against replay attacks. The LoRaWAN network is also protected against replay attacks both in the join procedures, by using a nonce and other data transmission by ignoring repeated messages. OSCORE, DTLS and TLS all implement sufficient protection against replay attacks.