An LPWAN-agnostic application layer for the IoT in Finland

(1)

AN LPWAN-AGNOSTIC APPLICATION LAYER FOR THE IOT IN FINLAND

Supervisors: Professor Pertti Silventoinen

Adjunct Professor Tapio Saarelainen Advisors: Turkka Laakkio M.Sc. (Tech)

Jyrki Ojaniemi M.Sc. (Tech)

(2)

LUT School of Energy Systems Electrical Engineering

Artturi Rämänen

An LPWAN-Agnostic Application Layer for the IoT in Finland

2019

Master’s thesis.

60 p.

Examiners: Professor Pertti Silventoinen

Adjunct Professor Tapio Saarelainen

Multiple Low Power Wireless Area Networks (LPWANs) currently operate in Fin- land. A typical part of an IoT application is a battery operated node which collects data from sensors and forwards it over LPWAN to a cloud system.

Studies on technical differences among pairs of LPWANs exist but few studies exist on application-level possibilities of the networks. This thesis studies how data from sensor-nodes using Sigfox, LoRaWAN and NB-IoT could be routed to an IoT application with no LPWAN interfaces, while preserving multi-year battery life.

A literature review of the features affecting the application level use of the LPWANs was conducted. Based on the results of the review, an application was created to interface between the IoT server application and nodes in the three LPWANs.

LPWAN-agnostic communication to and from end-nodes using the studied LPWANs was found to be a viable approach for IoT applications. Frequency and size of uplink transmissions were unaffected, but downlink transmissions were limited to a maximum of 8 bytes four times a day.

(3)

TIIVISTELMÄ

Lappeenrannan–Lahden teknillinen yliopisto LUT LUT School of Energy Systems

Sähkötekniikka Artturi Rämänen

LPWAN-riippumaton sovellustason tiedonsiirto Suomen IoT:ssa

2019

Diplomityö.

60 s.

Tarkastajat: Professori Pertti Silventoinen Dosentti Tapio Saarelainen

Suomessa on käytössä useita matalan virrankulutuksen langattomia laaja-alaisia verkkoyhteyksiä (engl. Low Power Wide Area Network, LPWAN). Tyypillinen IoT-sovelluksen komponentti on akkukäyttöinen sensorisolmu, joka lähettää ker- äämäänsä tiedon LPWAN:in avulla pilvisovellukseen.

LPWAN-parien välisiä teknisiä eroavaisuuksia käsitteleviä tutkimuksia on lukuisia, mutta verkkojen käytännön sovellustason mahdollisuuksia käsitteleviä tutkimuksia ei ole paljon. Tämä diplomityö tutkii sitä kuinka Sigfox, LoRaWAN ja NB-IoT verkoissa toimivien sensorisolmujen data voidaan reitittää IoT-sovellukseen, joka ei sisällä LPWAN-spesifisiä rajapintoja, niin että sensorisolmujen usean vuoden ak- unkesto säilyy.

Aihetta tutkittiin ensin tutustumalla LPWAN:ien sovellustason käyttöön vaikut- taviin ominaisuuksiin. Näiden perusteella toteutettiin sovellus tulkkaamaan IoT- palvelinsovelluksen ja kolmen LPWAN:in sensorisolmujen välistä kommunikointia.

LPWAN:ista riippumattoman tiedonsiirtoyhteyden todettiin sopivan IoT-sovelluk- sien kehittämisen perustaksi. Lähestymistapa ei lisää rajoituksia sensorisolmusta lähetettävän datan määrään tai tiedonsiirron tiheyteen, mutta sensorisolmulle lähet- ettävien pakettien koko ja lähetystiheys on rajoitettava maksimissaan 8 tavuun 4 kertaa vuorokauden aikana.

(4)

Preface

This thesis was brought about by my move to Turku in early 2018. During the course of 2018 I have had the chance to research the subject of this thesis deeply, and to develop my understanding of not only low power communication, but also of best practices in software development and of the troubles in developing applications with cutting-edge technology.

Firstly I would like to thank my supervisors, Professor Pertti Silventoinen and Ad- junct Professor Tapio Saarelainen, for the guidance that they have provided during the course of this thesis. The work for this thesis couldn’t have progressed as straightforwardly as it did without it. Secondly, I would like to thank the whole of RCP Software and especially my instructors Turkka Laakkio and Jyrki Ojaniemi for the direction and support given to me while I was constructing this thesis. Thank you for giving me the chance to apply such continued focus on this topic.

Thirdly, thank you to my family and friends for your support both before and while I was writing this thesis. Inka, thank you for your help and continued support for me and my projects. You’ve all been a blessing to me.

Turku, 4.1.2019

Artturi L. I. Rämänen

(5)

Abbreviations

LPWAN Low-power wide-area network IoT Internet of Things

LwM2M Lightweight Machine to Machine Protocol WiFi IEEE 802.11x

M2M Machine to machine

4G Fourth generation cellular broadband 5G Fifth generation cellular broadband ISM Industrial, scientific and medical bands IP Internet Protocol

NB-IoT Narrowband IoT (LPWAN) REST Representational state transfer API Application programming interface

ETSI European Telecommunications Standards Institute HTTP HyperText Transfer Protocol

FOTA Firmware over-the-air SNR Signal to noise ratio CSS Chirp spread spectrum MAC Medium access control

TCP Transmission Control Protocol DevEUI Device EUI

AppEUI Application EUI OTAA Over the air activation ABP Activation by personalization GPS Global Positioning System TOA Time on air

PHY Physical layer

CRC Cyclic redundancy check

DR Data rate

ADR Automatic data rate

MQTT Message queuing telemetry transport 3GPP Third Generation Partnership Project MNO Mobile network operator

LTE Long term evolution

GSM Global System for Mobile communications UE User equipment

S-GW Serving gateway P-GW Packet gateway

MME Mobility management entity QoS Quality of Service

SCEF Service capability exposure function ID Identifier

RAN Radio access network

(8)

CIoT Cellular IoT

MTC Mobile-type communications SIM Subscriber identity module TLS Transport Layer Security UDP User Datagram Protocol DTLS Datagram TLS

3G Third generation cellular broadband RFC Request for comments

PSK Pre-shared key PSM Power saving mode TAU Tracking area update JSON JavaScript Object Notation XML eXtensible Markup Language

CBOR Concise Binary Object Representation SenML Sensor Measurement Lists

CoAP Constrained Application Protocol URI Uniform Resource Identifier

SCTP Stream Control Transmission Protocol

OSCORE Object Security for Constrained RESTful Environments CPU Central Processing Unit

APN Access point name

AEAD Authenticated encryption with associated data UID Unique identifier

PDU Protocol data unit

IETF Internet Engineering Task Force

(9)

The Internet of Things (IoT) is currently growing globally. Battery powered devices performing simple tasks such as measuring relative humidity are to be deployed by the billions worldwide. Low Power Wide Area Networks (LPWANs) make transferring these small payloads of data from the long-lived battery powered devices to the cloud possible. These IoT devices with sensors and LPWAN connectivity are referred to as end-nodes in this thesis. Currently LPWANs such as Sigfox, NB-IoT and LoRaWAN compete against each other for use cases. All three differ in their pricing, network architecture and the RF bands they use.

The key aspect to LPWA networks is to facilitate transport of the required data to the destination, often a cloud system. Interfacing the cloud system with the LPWA network is always necessary, but often the value of the application being developed does not depend on specialities of the LPWA network, but the data being sent over the network. In this case time should be spent on activities that bring value to users. IoT applications may require different networks on a case-by-case basis, for example because the deployment area doesn’t have Sigfox coverage, a customer wants to own their IoT network infrastructure, or a customer requires the absolute lowest initial cost per end-node. An LPWAN-agnostic application layer could provide cost-efficient development of these systems.

LPWAN protocols do, however, differ greatly from one another, and may be polar opposites between each other in areas such as downlink connectivity, transmission frequency, allowed packet sizes and end-node lifetime events. It is unknown whether LPWANs can be deployed on end-nodes interchangeably.

1.1 Objectives

The main research question is "How can the LPWAN data links available in Finland be used interchangeably?" Sub-questions to be answered are:

• What are the technical common elements of LPWANs?

• Can security of the devices themselves be assured, and can authenticity of data be assured?

• What kind of performance limitations does the LPWAN-agnostic approach suffer from?

(10)

1.2 Scope of thesis

With regards to connectivity of LPWANs, this thesis will consider the application link between an end-node’s radio module and a generic IoT dashboard. The end- nodes for which the concept of LPWAN-agnostic links would be applied are battery powered devices which provide infrequent updates of sensor data to an application server, referred to as end-nodes. Use of device management features such as the ones provided by Lightweight Machine to Machine (LwM2M) are outside the scope of this thesis, but the application level data links may allow for basic device management operations. LwM2M end-nodes act as servers, the opposite of both Sigfox and LoRaWAN, and so the technology was not included in this thesis.

If security of the data is considered, the paper [1] by S. M. Riazul Islam et al.

sets the following standards for assessing security of IoT Healthcare: confidentiality, integrity, authentication, availability, data freshness, non-repudiation, authorization, resiliency, fault-tolerance and the ability to self-heal. Out of these, aspects, self- healing and fault-tolerance are not directly related to secure lpwan-agnostic data links. Most are summarized in the following security checklist specifically for lpwan- agnostic data links which will be applied in this thesis:

• Can device connectivity be harnessed for unwanted activity or otherwise mis- used?

• Are data errors checked for?

• Can data remain confidential?

– On air

– In IP networked systems

• Can data be forged?

• Is the end-node or server vulnerable to replay attacks?

A replay attack involves recording a true message, and transmitting it again in order to make the receiving party repeat the same action that the original message made happen. Data repudiation does not seem possible in LPWANs, and so is not considered in this thesis. Denial of service is also outside the scope of this thesis.

(11)

1.3 Structure of thesis

This thesis is structured in two main parts, a review of relevant standards and literature, and a practical implementation of an LPWAN-agnostic application layer link. The literature review first examines some essential concepts of communicating application data from an end-node to a cloud system, and then goes on to examine the capabilities of LPWANs available in Finland, and in which way they may be used with common functionality. The environment and goals for the implementation of this thesis are defined insection 3, with the following section containing a description of the implementation and key choices made. The implications of the results are discussed insection 5, and the conclusions of the thesis are presented insection 6.

(12)

2 Background

What are the minimum requirements to generate value from the Internet of Things when no WiFi is available and the device must be battery powered? This includes the communication component – LPWANs, the types of IoT data that may be required to be transmitted, and specific device constraints that IoT devices have, and which must be taken into account when attempting to achieve an application level LPWAN link.

The core features of each of the three LPWANs are examined with the aim to find out how they can be integrated into an LPWAN-agnostic application. Key features include architecture of the system, supported payload sizes, communication frequency limitations and how upstream applications are interfaced with. The way in which each LPWAN must be operated in order to enable LPWAN-agnostic behavior is then be derived from these key features.

2.1 M2M communication

Requirements for communication technologies for the IoT vary greatly from use case to another. For example, some applications of M2M communication may require range extending into ten’s of kilometres, while other applications require high data throughput. As can be seen in figure1both cellular technology such as 4G/5G and WiFi target applications where high data throughput is required over battery life.

LPWANs trade data throughput for long range and low power. According to [2]

low power IoT connections can be achieved via multihop short-range transmission technologies, but as their coverage is limited, they face more obstacles than LPWANs if urban-area-wide coverage is required.

According to a definition in [2], LPWANs are not cellular networks, which operate in licensed bands, and they are not short-range multihop connections, operating in the industrial, scientific and medical (ISM) bands. LPWANs are defined as networks exploiting sub-gigahertz unlicensed frequency bands, with the intent of low power consumption and long range. Devices using LPWANs typically connect to agateway, which bridges the LPWAN to IP networking. [2]

Narrow-Band IoT is an exception here, as it is defined to be both low power, and to have wide-area coverage [3]. In a 2016 paper [4], NB-IoT is defined as an LPWAN operating in a licensed band. The LPWAN definition used in this paper includes

(13)

Cellular Sigfox, LoRaWan, NB-IoT ^LPWAN

Local Area Network WiFi, Zigbee

Personal Area Network Blutooth

Range

Battery Life 5 km

5 m

Figure 1: A map of different wireless communication standard applications.

NB-IoT.

2.2 Types of IoT Data

According to [2], IoT communication is expected to happen mostly in the form of small data packets, which are transmitted sporadically. Typical sensor data can most often be represented in two or three bytes [5], and this is what one can expect of current LPWAN data.

In order to reduce the amount of transmitted data, data rich samples such as images or sound may be processed into valuable information directly on the end-node. This is called edge computing or fog computing. One approach using this technique is described by Gierad Laput et al. [6], in which the end-node was programmed to classify the current state of an environment via machine learning. Processed sending outcomes such as "are the lights on", or "how long have the lights been on in the last 24 hours" are referred to assynthetic sensors.

2.3 IoT Device Constraints

Many IoT applications require long battery life and small size or weight. Assum- ing a purely uplink-oriented end-node, transmitting data is most likely the largest source of power drain in an IoT device. Transmitting more often leads to lower life expectancy of the IoT device, and so must be balanced with the increase in gener-

(14)

ated value for end-users from transmitting data more often. Since all networks have overhead, it is generally more efficient to group more data into each transmitted packet, rather than transmitting it over several packets.

Due to the large amount of deployed devices, production costs of IoT end-nodes must be kept to a minimum, meaning end-nodes are typically limited in their RAM size, nonvolatile storage size and available processing power.

2.4 Sigfox

Sigfox is an ultra-narrowband communications system designed for low data rates and ranges of up to 20 km [7]. The Sigfox network operates in the EU 868 MHz / US 915 MHz ISM bands. An end-node in the LPWAN is connected to an enterprises application servers via Sigfox’s own cloud backend. The gateway network used to communicate with end-nodes in the system is maintained by Sigfox, and the communication modules are registered to and billed by Sigfox (the company), leading to a business model similar to cellular operators.

2.4.1 Architecture

Data sent by Sigfox end-nodes is broadcast to all base stations within range, which process and forward the message to the Sigfox backend, triggering user-set callbacks in the Sigfox backend [7]. These callbacks forward the data to any of a number of systems. These systems include IoT platforms by Amazon, Microsoft and IBM, e-mail, and any other REST API. The architecture supports downlink data transfer, but it is much secondary to uplink data transfer in link frequency.

2.4.2 Transmission Specifics

Technical limitations of the Sigfox system are payload size, messages per day and downlinks per day. The up- and downlink payload limits of Sigfox are 12 bytes and 8 bytes, respectively. Sigfox utilizes a pricing model in which there are four levels of communication volume per day, presented in 1

The Platinum uplink limitation is a consequence of ETSI regulations used in Europe, citing a 1 % duty cycle limitation leading to 144 12-byte-payload Sigfox messages per day [9]. As the pricing model shows, the Sigfox LPWAN is designed for higher uplink

(15)

Subscription level Uplink / 24 h Downlink / 24h

One 1-2 0

Silver 3-50 1

Gold 51-100 2

Platinum 101-140 4

Table 1: Sigfox subscription tiers [8].

frequency than downlink, and for transmitting small payloads, such as infrequent sensor data. Downlink transmissions to many end-nodes must be sent by the same gateway, which itself must stay within the same ETSI duty cycle limitations as the end-node. Transmitting high-bandwidth data such as images, audio or video is not possible over the Sigfox network.

The Sigfox downlink transmission scheme [10] is as follows:

1. The end-node requests a downlink message by adding a downlink request flag to an uplink. The sequence is always initiated by the end-node.

2. The Sigfox Cloud runs a callback to the customer’s application server and gathers any downlink data available for the end-node.

3. In a few seconds, the downlink message is transmitted to the end-node.

With such a scheme, the end-node can not be activated remotely to perform an action with low latency. The application must allow waiting until the next uplink connection to transmit data downlink to the end-node. The downlink HTTP response must be received by the Sigfox backend in under 20 seconds [9]. Also, with a maximum downlink data rate of 24 bytes per day, it is not possible to perform firmware Over-The-Air (FOTA) updates. This amount of data may, however be enough for example adjusting certain parameters of a device remotely.

2.4.3 Security

According to Sigfox’s paper on their approach to security [11], the Sigfox network relies heavily on their non-IP connection and limited bandwidth. The paper ar- gues that Sigfox devices are expected to only use their data link for implementing their default behaviour, and don’t allow for radically changing device behaviour.

As the end-node can only ever contact Sigfox’s backend, the company has control

(16)

over where to forward the resulting IP traffic. Sigfox assures that data being sent over the air in both directions is error-checked, authenticated and protected against replay attacks, but is not encrypted and can thus be decoded by third parties. Au- thentication guarantees the proper origin of the message, either the end-node or the Sigfox network.

Each Sigfox message received contains a sequence number identifying the message.

A newly received sequence number is then compared to the ones last received by the Sigfox network, and action is taken according to the gap’s severity. A warning is issued if there is any gap in the sequence number, and an error message along with interruption of message delivery if the gap is larger than the error limit of a subscription level. After 4096 messages the sequence number wraps around to 0.

[12]

The Sigfox error limits for different subscription levels are presented in table2. The error limits for all but the "One" subscription level translate to roughly three days of continuous loss of coverage, assuming maximum subscription uplink throughput.

The "One" subscription level will issue an error after 10 days under the same conditions.

Subscription level Error Limit

One 20

Silver 150

Gold 300

Platinum 420

Table 2: Maximum difference in received Sigfox sequence numbers before messages are not forwarded. [12]

2.4.4 Managing Power Consumption

Sigfox end-nodes initiate uplinks completely asynchronously, and do not implement listening before transmitting [13]. This means that an end-node does not need to use radio power listening to the network before transmitting, may transmit immediately once it has ceased operating in a low-power state, and should receive any queued downlinks directly following the uplink transmission. The sequence allows for extremely low power consumption, as the end-node may fully turn off power to their radios during a low-power state, effectively making the connectivity option not use any power.

(17)

2.4.5 Configuration

The user interface for the backend system of the Sigfox network is displayed in figure 2. Sigfox provides an abstracted link between end nodes and the Sigfox backend, so all settings wth regards to data transfer have to do with either the end-node or the uplink callbacks. So-called custom callbacks can modify the data in a limited way, add more information like date, time, location and SNR, and forward this data to a HTTP API or e-mail.

Figure 2: A screen capture of the device callback editor in Sigfox Backend.

The callback editor provides settings for at least:

• Type: Data/Service/Error – What to react to

• Type (continued): Uplink / BiDir – Is a downlink expected?

• Channel: Url / Batch-Url / E-mail – Where to forward data?

• Custom payload config – How to decode received bytes to variables for message editor

(18)

• Url pattern: Url to invoke, may include variables such as device name

• HTTP Method: POST / GET / PUT

• Headers: User-defined headers such as authorization

• Content-type

• Body: A field in which to write the message body, may include variables The Sigfox Custom Format is a way to encode and decode data in few bytes, while specifying the data types used. It can decode a pre-determined sequence of bytes to signed, unsigned integers, floats, character sequences and booleans. These variables are then referenced according to pre-determined names.

2.5 LoRaWAN

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 application server which implements business logic [14].

(19)

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 filtering duplicate and unwanted packets, and of replying to the end devices by choosing one of the in-range gateways, according to some criterion (e.g., best radio connectivity). The gateways are thus totally 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 specific sub-band and spreading factor.

This access mode greatly simplifies the management 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 traffic 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 network, 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, waiting 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 broadcast 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., connected 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 specifications [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 networks, 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 1. LoRa system architecture.

End device End device

End device

End device End device

LoRa radio links End device

End device

LoRa

gateway LoRa

gateway

IP connection IP connection

LoRa NetServer

The NetServer is hence in charge of filtering duplicate and unwanted packets, and of replying to the end devices by choosing one of the in-range gateways, according to some crite- rion. The gateways are thus totally transparent to the end devices, which are logically con- nected directly to the NetServer.

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 implementing 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

(20)

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

(21)

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,

(22)

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]

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 consumption 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

(23)

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 implementations allow for queueing of messages from an external application backend, which the Sigfox backend doesn’t provide. Table4 summarizes the generally similar connectivity 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 communication.

2.6 NB-IoT

Narrowband IoT (NB-IoT) is a wireless cellular standard released in 3GPP Release 13 for providing wide-area coverage for IoT devices. Objectives that the standard was built around include:

• very low cost,

• extended coverage,

• possibility for 10 year battery life with 5 Wh battery, and

• support for up to 50 000 devices per cell.

The standard, released in 2016 supports theoretical communication speeds of up to 250 kbps for uplink and downlink. [27]

(24)

NB-IoT can be deployed by Mobile Network Operators (MNOs) in a gradual manner, coexisting with legacy GSM and LTE networks. This is possible as NB-IoT can be deployed in three different schemes with respect to existing LTE carrier bands: fully replace a GSM carrier band, deploy within an existing LTE carrier band or deploy in an LTE guard band. The options are intended to increase deployment flexibility.

Finally, NB-IoT makes much use of the existing LTE design, significantly reducing the development time and cost of NB-IoT products for existing LTE equipment and software vendors. [3]

A 2011 paper reckoned that if the LTE architecture could be repurposed for machine- to-machine communications, the wide coverage of existing cellular networks may mean that cellular networks could well be an important route for M2M communications [28]. NB-IoT can be deployed on existing cellular Base Transceiver Station’s via a software update [29]. NB-IoT is designed primarily for latency-insensitive applications, but the standard still allows for a latency of under 10 seconds for cases such as alarm signals [3].

2.6.1 Architecture

NB-IoT uses existing cellular network architecture to enable M2M communication, thus a short survey of current Long Term Evolution (LTE) network architecture is in order.

From the perspective of an LTE user the Evolved Packet System is that which provides the User Equipment (UE) with IP and voice connectivity to the internet and the operator’s services. To provide this the UE accesses the core network via anevolved NodeB, as seen in figure 4. Evolved NodeB’s provide radio access in LTE networks, while the Core Network consists of multiple elements. The Core Network elements, including the Serving Gateway (S-GW), the PDN Gateway (P-GW), the MME (Mobility Management Entity) and others work together to provide all the services associated with modern LTE connectivity, including enforcing subscriber policies, IP allocation, settings Quality of Service (QoS) for different data, mobility management and more. [30]

From the perspective of an application developer NB-IoT supports two types of routes for communication: routes in Non-IP planes and routes in the IP plane [3]. In non-IP plane communications the application server communicates to an end-node via a certain network operator’s API, which acts as a gateway to the NB-IoT devices.

(25)

Figure 4: Network elements of the Evolved Packet System used by LTE, with Core Network on right side of vertical dashed line. From [30].

IP plane connections allow an end-node to connect directly to the application server over IP protocols, a feature absent from the other LPWANs in this thesis.

The Service Capability Exposure Function (SCEF) is defined in 3GPP release 13, and is a component that securely exposes specific functions of the 3GPP network for enterprise use. It may provide API’s, use of external ID’s and Non-IP Data connectivity. API’s to the 3GPP network could make the following possible: An enterprise application polls for information on whether a specificUser Equipment (UE) is currently reachable, and if not, has the SCEF send the application a notification once the UE is reachable. [31]

As in figure5, the SCEF is the component used by an enterprise application server to communicate with an operator’s Core Network and manage, configure and communicate with cellular IoT devices.

Figure 5: Network elements used for NB-IoT data transmission. Red routes indicate Control Plane CIoT EPS optimization, the blue route stands for User

Plane CIoT EPS optimization. From [32].

(26)

2.6.2 Connectivity Options

According to the GSM Association, NB-IoT supports both SMS and multiple data connectivity options. SMS is not included in the minimum recommended features of the second edition of the GSMA NB-IoT Deployment Guide, and is not covered in this thesis. The data connectivity options include:

• IP over Control Plane

• IP over User Plane

• Non-Ip over Control Plane

• Non-IP over User Plane.

All but Non-IP over User Plane are visualized in figure5. Both IP and non-IP data over control plane can travel RAN – MME – S-GW – P-GW – Application server, while the route RAN – MME – SCEF – Application server is only for Non-IP data over Control Plane [33].

In LTE networks, user data is transported using both SMS and IP over User Plane.

The traditional IP over User Plane directly via the S-GW and P-GW requires the most signalling out of the four data connectivity options. The other three were first defined in 3GPP Rel-13, and offer ways to balance the power consumption of end- nodes and their connectivity by utilizing different routes and optimizations through the core cellular network. The new Control Plane CIoT EPS optimisation defines both IP and non-IP Control Plane options for sending user data and SMS messages.

[33]

By utilising the Control Plane, the power consumption of sending reasonably small messages can be optimized by reducing the required signalling and total transmission time. It is possible to further optimize power consumption by using non-IP transmissions, as they allow use of custom protocols suited for the use case. If the amount of data to be transmitted is large, a User Plane connection may consume less power. It is argued that using non-IP connections over the User Plane may not reduce power consumption of the User Plane connection due to the User Plane connections overhead. [33]

Conventional User Plane traffic must build a connection to the destination server each time a packet is sent. User Plane CIoT EPS Optimization in NB-IoT, visualized

(27)

in blue in figure 5, allows the transfer of a sequence of packets on the User Plane with just a single built connection, leading to lower total overhead for larger data transfers. Both IP and non-IP data are supported. [32]

2.6.3 Security (Non-IP)

NB-IoT inherits much of its security model from LTE networks, and is different from Sigfox and LoRaWAN in that it can also be used directly on the IP plane, with it’s benefits and downsides. The communication security criteria which both are compared against in are: error checking, data confidentiality, possibility of forging data or data being replayed in either direction. The security of Non-IP communication configured via the SCEF is examined first, followed by a similar examination of the security of IP-plane connections.

Specific requirements of security in MTC in 3GPP networks are defined in 3GPP TS 133 187. It requires that anyMachine-Type Communications (MTC) optimizations within the core network must not degrade security compared to non-MTC communications. Communication between the enterprise application server and SCEF must implement integrity protection, replay protection and privacy protection, and confidentiality protection should be used. In addition the SCEF should be able to verify the authorization of any application communicating with it. The specification defines optional procedures that include filtering unauthorized SMS messages that may be used for triggering devices, so that only the authentic application messages are passed to the UE, restricting a specific SIM card to specific UEs and different types of efficiently secured connections. [34]

Since the application server connects to the SCEF via IP protocols, the requirements set in TS 133 187 are satisfied by a succesfully implemented TLS (Transport Layer Security) connection [35], along with authentication for applications. For communication between the UE and the mobile network, the data is required to be integrity, confidentially and replay-protected from unauthorized parties when sending data on both the Control Plane [36], [37] and the User Plane [36].

2.6.4 Security (IP)

If using NB-IoT in the IP domain, the end-node will directly contact the application server, complicating the communication protocol choices for battery powered NB- IoT devices. The aim of this section is to go examine the various Internet and

(28)

Internet-related protocols suitable for M2M communication in battery-powered end- nodes.

Using IP communication, data sent over NB-IoT can be integrity protected by using either TCP [38] or UDP [39]. Each TCP message does, however, require back-and- forth communication between the server and client [38], while UDP does not. Thus, UDP allows for more flexibility for scheduling communication over NB-IoT. Because of this, battery powered devices such as end-nodes should achieve longer battery life when using UDP rather than TCP.

If leaving the IP communication unencrypted, any end-node and server authorization information is transmitted in plain-text, and may be intercepted, modified or re- transmitted at will. This could lead to unfilterable spam in the application server and unauthorized commands being sent to end-nodes, both of which are fatal to an IoT application.

In order to authenticate the end-node at the application server, at minimum a cryptographic Message Authentication Code of the data must be sent alongside the payload for the server to verify that such a device may access the application server. If the data to be transmitted requires secrecy, the data must be encrypted.

The connection overhead and duration should be simultaneously minimized by the application developer, as there is no gateway converting between on-the-air payloads and IP such as in LoRaWAN and Sigfox.

IP communication can be confidentiality, replay and forgery protected with TLS.

Datagram Transport Layer Security (DTLS), deployed over UDP is a protocol offering the same protection as TLS, while preserving the datagram structure of UDP [40]. TLS and DTLS both involve negotiating a secure session between the server and the client before transmitting application data. For the duration of the session, application traffic after the handshake is encrypted by symmetric encryption. A TLS 1.2 full handshake requires two TCP round-trips to the server, and a server certificate must be presented to the client [41]. Similarly, DTLS 1.2 requires three or one and one-half UDP round-trips to initiate and resume a session, respectively, in addition to receiving the same server certificate [42]. The server certificate’s public key certificate size can be multiple kB (For example, the *.google.com certificate is 1995 bytes in the end of 2018 when encoded in DER binary form). Receiving a mostly redundant 2 kB each time the end-node communicates with the application server can be expected to significantly reduce end-node battery life.

In a study by Miranda et al. TLS and it’s effect on energy consumption in mobile

(29)

devices using both WLAN and 3G was tested. They found that for the smallest tested transaction sizes of 1 kB in a 3G network, 80 - 90 % of the energy consumed by the device was spent in the TLS handshake [43]. A transaction size of 1 kB is much larger than allowed for Sigfox and LoRaWAN, meaning that for encrypting payloads of under 1 kB, NB-IoT end-nodes using TLS encrypted IP protocols would spend a very significant amount of energy initiating secure sessions, and hardly any for transmitting application payloads.

One client authorization scheme in TLS is to use a client public key certificate [41].

The initial handshake contains a challenge in which the client can cryptographically prove it’s identity to the server. Another scheme is to rely on the eavesdropping protection of TLS and DTLS and have the end-node provide a unique secret on the application level to prove its identity. For example when using HTTPS this could be achieved by using basic access authentication [44], a simple user/password pair.

A client certificate offers the possibility to update the certificate without the server losing trust (via Certificate Authorities), but requires the certificate to be sent by the client in each initial TLS/DTLS handshake, leading to more transmitted data.

The authentication is then valid for the whole session. A user/password pair sent in every request may require less overhead for short sessions with few requests, but the pair can not be updated without server-side changes.

The TLS-PSK cipher suites are a solution within TLS to support authentication via symmetric Pre-Shared Keys (PSK), known only by the client and the server.

Originally defined by the RFC 4279 as the cipher suites beginning with TLS_PSK, benefits of the TLS-PSK cipher suites are the fact that there is no need for costly- to-compute public-key operations and key management can be simplified greatly.

The RFC document specifically mentions clients with pre-configured machine-to- machine connections as a suitable use case. The TLS handshake when using PSKs also requires much less data to be transmitted back and forth, as no certificates are transferred. [45]

PSK cipher suites are also part of the DTLS specification [40], [46], offering the same benefits of lower bandwidth use and less costly encryption and decryption operations [46]. The PSK handshake in DTLS 1.3 allows the client to send application data after just one UDP round-trip, without transferring a server or client certificate either way. [40].

(30)

Two modes of communication in cellular networks have been recently introduced by the 3GPP in order to enable optimization of power consumption in cellular networks.

PSM, introduced in 3GPP Release 12, is designed to enable IoT devices to achieve the specified design goal of 10 year battery life. Turning the radio of the end- node off conserves the most battery, and has always been an option in cellular networks. On subsequent wake up, the device would need to register again with the network, leading to increased power consumption over the lifetime of the device.

PSM configurations enable the end-node to stay attached to the network for a set amount of time without any radio transmissions. [33]

The applied PSM configuration is negotiated jointly by the UE and the network. A device may initiate PSM by providing two timers, T3412 and T3324 to the network.

If accepted by the network, the difference between these two timers defines the PSM cycle during which the UE may keep it’s radio powered off. The UE is also allowed to broadcast uplink data before the expiration of the PSM cycle, for example to send information of an alarm condition. PSM cycle time can reach up to approximately 413 days. A feature that is recommended by the GSMA is to store downlink packets received by the network during PSM, and transmit them once an uplink transmission occurs. [33]

More specifically,Active Timer T3324 controls how long the UE is reachable by the network after the data transfer period. This is shown in figure6 on page 23as the UE reachable period. The Tracking Area Update (TAU) timer T3412 controls the period between the UE signaling it’s existence on the network. [47]

According to a recent Master’s thesis, the average power consumption of the BG96 cellular modem in NB-IoT mode during the data transfer period was roughly 247 mW for 12 s for one Finnish MNO, and 218 mW for 15 s for the other [48]. The experiment fails to specify the values used for timers T3412 and T3324. The power consumption of the following network idle period were roughly 102 mW for 32 s and 66 mW for 43 s. Since the length of the idle period should be set by timer T3324, a shorter idle period duration should reduce total power consumption.

(31)

Figure 6: PSM uses the length of the TAU period and PSM cycle to set transmission frequency and downlink availablity. From [33].

2.7 Data Serialization

Serialization and deserialization is a critical part of IoT applications, since data must be transferred over constrained networks to constrained end-nodes. Many efficient serialization methods have been developed with goals ranging from "hundreds of bytes is fine" to "every byte decreases battery life". The requirements for an efficient serialization and deserialization scheme include low processor resource consumption at the end-node, support for time-aggregated sensor readings and small-as-possible payload sizes.

Data serialization refers to turning object data into a binary format that can be either saved or transmitted. Deserialization means the opposite, constructing the original object representation from the binary format. The serialization can require a schema, where an externally defined structure is required to understand the data, or schema-less, where the object attempts to represents itself. The most critical aspect with regards to data serialization and LPWANs is the resulting payload size.

Examples of common schema-less serialization schemes are JSON [49], XML [50], CBOR [51] and MessagePack [52]. All of these allow for representation of common programming objects such as arrays and key/value pairs, with JSON and XML being fully human-readable while CBOR and MessagePack are binary formats. Mes- sagePack and CBOR both encode information in a compact manner. MessagePack outperformed JSON, XML, CBOR and all the other tested serializers in speed and compactness in a study [53] by Bo Peterson et al., but this may depend on payload type.

As seen in listing 1, serializing an object containing the data of a humidity and

(32)

temperature sensor with JSON in results in a payload size of 145 bytes (whitespace removed), which is twelve times the allowed Sigfox uplink payload size. The example listing includes a channel value in order to seperately identify multiple sensors of the same type in one payload, for example indoor and outdoor temperature. Serializing the same data structure with MessagePack yields a payload size of 117 bytes for the same data. This is an improvement, but is still roughly ten times the size of the maximum allowed Sigfox payload, and double the maximum payload size of LoRaWAN with the slowest data rate.

{

"device": "Example",

"data": [{

"type": "temperature",

"unit": "C",

"channel": 1,

"value": 20.50 }, {

"type": "humidity",

"unit": "%",

"channel": 3,

"value": 50.5 }]

}

Listing 1: Example of explicit end-node sensor data. Channel of data allows for multiple readings of the same type to be referenced.

A model of how to compress sensor measurement data has been defined by the IETF as Sensor Measurement Lists in the RFC 8428. SenML is a data model, and serializations of it are provided for JSON, CBOR, XML and Efficient XML Interchange (EXI). SenML compresses the data by reducing redundant data in lists of sensor measurements. It supports measurement lists for values at different relative and absolute times, different sensors and actuators, completely different devices. [54]

A simple example of a SenML-modeled JSON serialization is shown in listing 2.

A base name "bn" and base unit "bu" are used to reduce redundant data. The JSON serialization less whitespace requires 78 bytes, and a CBOR serialization of the same data requires 46 bytes – a decrease of 71 bytes in payload size compared to listing 1 MessagePacked. In the case of a single measurement SenML achieves this decrease mostly due to reducing key lengths to one or two characters. Where SenML shines is when data from multiple devices or timepoints are to be expressed in a

(33)

compact manner. For example historical measurements can be added without using a Real Time Clock by adding measurement instances with the"t" parameter set to a negative value. At of -5indicates "5 seconds before this moment". Measurements from other devices at different times can be added by adding a measurement defining a new base name.

[{

"bn": "Example",

"bu": "%RH"

}, {

"n": "1",

"u": "Cel",

"v": 20.50 }, {

"n": "3",

"v": 50.5 }]

Listing 2: A sensor measurement list using SenML of the same data as in listing1.

JSON, XML, and MessagePack all serialize data with mostly human-readable keys.

The keys allow the contents to be understood without knowledge of a schema, but this is also the main cause for the large payload sizes. NB-IoT’s unrestricted payload sizes allow sending data in these schema-less formats such as JSON, XML and MessagePack, but especially Sigfox can not transmit data in these formats due to the large payload size. For a 12-byte payload as in Sigfox, one must use a binary format together with a schema.

In the example of listing 1, much of the payload bytes are spent in ensuring that the data is deserializable without knowledge of the contained data. For example, if the use of Celsius degrees and percent as the units of temperature and humidity were known by both serializing and deserializing parties, the payload could be made smaller. This is the main approach used by Cayenne LPP, based on IPSO smart objects.

IPSO Smart Objects define a data model, consisting of the object representation, the data type used, operations one can perform on the object and more. The data model, specifically designed for IoT applications by OMA Specworks defines Object Type ID’s for digital input’s digital outputs, temperature sensors, accelerometers and more. An instance ID is also defined, allowing multiples of the same sensor to be referenced per end-node. [55]

(34)

Hex Stands for Result 0x01 Channel 01

0x67 Temperature sensor Temperature (Channel 1): 20.5 °C 0x00CD Value of 205

0x03 Channel 03

0x68 Humidity sensor Humidity (Channel 3): 50.5 % 0x65 Value of 101

Table 5: Explanation of Cayenne LPP packet 0x016700CD036865 containing the same data as in listing 1.

The IPSO Smart Objects specification was used to define the Cayenne LPP, which is a more simple model with emphasis on suitability for LPWANs with very constric- ted payload sizes, and reading sensors instead of executing commands on objects.

Cayenne LPP defines an object data type ID which mandates the data type (in- teger, float, boolean, etc), the length (No. of bytes), what the object representation (temperature reading, humidity reading) and the data format (0.1 °C, 0.5 %) of the following binary data. [5]

Using the pre-defined data types in Cayenne LPP, the previous data from listing 1 specifies the same functional data in 7 bytes. The only factor the Cayenne LPP is missing compared to the listing 1, is that the payload doesn’t specify the device’s identifying string. Sigfox and LoRaWAN payloads are always forwarded together with the device name or identifier. The SCEF would also be expected to report a name or identifier of an NB-IoT end-node. Only in the case of direct NB-IoT IP communication the end-node must specify it’s identity within the payload. The Cayenne LPP 2.0 specification draft also includes representations for historical data and device configuration commands such as sensor on/off, transmit period and sensor reading period [56].

2.8 CoAP

The Constrained Application Protocol [57] is a web application layer protocol designed for use with resource constrained nodes and constrained networks in M2M applications. CoAP enables a request/response model of communication, similar to HTTP, including features such as URIs and support for different media types.

The standard, defined in the RFC7252, is specifically designed to be operate over

(35)

datagram transports, mainly UDP. This is a key underlying difference to HTTP, which operates over a connection-based protocol such as TCP. CoAP can be used with DTLS to allow secure communication over UDP, and also used over other transports such as SMS, TCP and SCTP [57].

The fundamentals of CoAP consist of the messaging model, and the request/response model. The messaging models concern is exchanging messages over UDP between endpoints, and does not define servers or clients. The request/response model defines how a server and a client interact with each other. We will examine the messaging model first.

The CoAP messaging model has two features:

• Stop-and-wait retransmission reliability with exponential back-off for Confirm- able messages.

• Duplicate detection for both Confirmable and Non-Confirmable messages.

CoAP defines four types of messages: Confirmable (CON), Non-Confirmable (NON), Acknowledgement (ACK) and Reset (RST). The Confirmable message type is used for reliably transmitted messages. The recipient of such a message must either respond with an ACK (to acknowledge) or a RST (to indicate that the message could not be processed properly). A NON message is a one-way message, and if a message does not make it to the recipient, neither the sender nor the receiver will know without using out-of-band data.

CoAP requests and responses are carried in CoAP messages, and include either a Method Code or a Response Code, respectively. The Method Codes are listed in table 6. The Methods map roughly to HTTP methods, but are specifically defined for CoAP. Response Codes belong to class 2, 4 or 5, indicating Success, Client Error and Server Error, respectively. Response Codes are written in the formatC.XX, with Cas Class of code, and XX specifying the details of the response code.

CoAP also specifies how the message type influences client and server interaction. A CON request requires an ACK within ACK_TIMEOUT, which is by default 2 seconds.

Since replying with an ACK and immediately sending the actual response to the request would be wasteful, CoAP specifies that responses may be sent within the same PDU (Protocol Data Unit) as an ACK. An example of this kind of exchange is shown in figure 7. The optimization, called piggybacking, allows a request and response pair to occupy only two PDUs. In case either of the messages are lost,

(36)

Method Short Description Safe Idempotent GET Retrieves a represetation of the inform-

ation that correspond to the resource identied in the request URI.

Yes Yes

POST A request to process the enclosed data. - - PUT A request to create or update the re-

source with the enclosed representation.

- Yes

DELETE A request to delete the resource at the

URI. - Yes

Table 6: List of CoAP Methods. Safe methods do not alter server state.

the standard retransmission scheme for CoAP is used until the client receives the piggybacked response. [57]

If the client is under a limitation to only send one message to the server, but would still like to receive a response, the request may be made with a NON message.

In this case the response is also sent using a NON message. This scenario could occur if for example a cellular NB-IoT device must conserve power, and uplink transmissions consume significantly more power than receiving. When compared to a CON request, the client does lose the information on whether the request or the response was lost in transit, but gains more control over it’s own power consumption.

This could be very significant for the end-nodes battery life when it is experiencing a very lossy network.

Client Server

POST, CON 2.04 Changed, ACK

Figure 7: A Confirmable request which receives a response piggy-backed to an ACK message.

CoAP options represent optional or default request and response information, and some options provide similar functionality to what HTTP headers provide. Ex- amples of CoAP options include payload content-types and accepted content-types.

CoAP URIs paths are also encoded as options. [57]

(37)

Client Server POST, NON

2.04 Changed, NON

Figure 8: A Non-Confirmable request which receives a NON response.

As CoAP is designed for constrained networks, it provides an option for the client to request that no response is sent back to it. The No-Response option, specified in RFC 7967 allows the client to specify for which response classes it does not request a response. If all response classes are not requested, the client should cease listening for any responses to the specific request. If there is only one request active, the client no longer has any obligations to the server, thus the communication is entirely one-way. [58]

An example of communication between a CoAP client and server that implement theNo-Response option is shown in figure9. Use of the option enables lower power consumption for IP connected radio end-node, but makes it impossible for the client to know the result of its request, or if it was received by the server. This CoAP option also makes it possible for IP-connected battery powered NB-IoT end-nodes to implement identical request/response patterns as in LoRaWAN and Sigfox.

Client Server

POST, NON

Figure 9: A Non-Confirmable request using the No-Response option to display disinterest in any response.

2.8.1 OSCORE

Object Security for Constrained RESTful Environments (OSCORE) is an application- layer method with the objective of securing CoAP data between endpoints. The method is an implementation of the RFCs Concise Binary Object Representation (CBOR) and CBOR object Signing and Encryption (COSE) for use only with CoAP. OSCORE is currently available as the IETF draft titleddraft-ietf-core-object- security-15. [59]

An LPWAN-agnostic application layer for the IoT in Finland