4.2. SCAP LTP features

4.2.1. Glossary

4.2.1.1. LPWAN

  • Low Power Wide Area Network, namely Sigfox and LoRaWAN for now

4.2.1.2. ULP

  • Ultra Low Power. A device may typically consume less than 1 A when idle, and less than 100 mA when acquiring data and sending it through the LPWA network

4.2.1.3. MTU

  • Maximum Transfer Unit. The maximum payload size (typically in bytes) which may be sent at once

4.2.1.4. IV

  • Initialization Vector. A value of a predefined size which but be different each time it is used.

4.2.1.5. join

  • When using the LoRaWAN networks, a device must join the network before sending messages. When a device switches from one LoRaWAN network to another, it must join the new network and forget the old one. Alternating between a LoRaWAN network and a Sigfox network does not require to join the LoRaWAN network at each uplink

4.2.1.6. REST

  • REpresentational State Transfer. Here, the REST API is a set of context-less HTTP requests using the json format

4.2.1.7. API

  • Application Programming Interface. Here, the REST API is a set of context-less HTTP requests using the json format

4.2.1.8. QoS

  • Quality of Service. Here, it refers to the received segments/sent segments ratio

4.2.2. Overview

  • End-to-end security, from device to application, independent of operators or technologies

    • AES-256 GCM encryption
    • AES-256 GCM authentication with 96-bit tag
    • Anti-replay
    • LoRaWAN automatic join renewal
  • Improved QoS

    • Automatic switching between operators without roaming (Sigfox and LoRaWAN)
    • Automatic switching between private/public infrastructures (LoRaWAN)
    • MTU setting by route (Sigfox and LoRaWAN)
    • Automatic re-join after a number of attempts (LoRaWAN)
    • Management of retries by route (LoRaWAN)
    • Best radio parameter settings (no payload limitation)
  • Improved performance and simplified development (time-to-market reduction)

    • Payload size increase thanks to an on-the-fly segmentation and recombination process (2 patents pending)
    • Optimized data structure: RAW and BIN streams
    • Downlink padding management (Sigfox)
    • Device side generic interface (API and AT commands)Precompiled binaries available for several modems : Multitech, Murata, Nemeus, Telecom Design, ...
    • Server side generic interface REST APIs, operator agnostic (Sigfox, Orange, Loriot, TTN, Actility, )
    • Block size independent encrypted payload size
  • Integration

    • Device side (~30K bytes library)

      • Ready to flash binaries (Multitech, Murata, Nemeus, Telecom Design, )
      • SDK
      • Custom binary for SOC, micro-controllers or device
      • PLD reference design

        • Server side
      • SaaS platform

      • On premises

4.2.3. Description

The LPWAN networks allow wireless sensors to communicate with cloud-hosted or on-premises applications. These networks are characterized by a low throughput which enables very-long distance communication (up to 40km), and so a frugal base station territorial coverage. The sensors are generally ULP and may last for 10 years [^1]. These two key points make the LPWA networks very low cost and well suited for widely spread applications.

The thrifty nature of LPWA networks means they lack some features required for quick and robust application development. hl2gener provides theses features on top of the LPWA networks by implementing the SCAP and LTP protocols.

These protocols add the following features: segmentation, encryption/authentication, and generic variable encapsulation.

Communication layers from the LPWAN networks to the application

SCAP and LTP are meant to work together on an IoT device and a server. For uplinks [^2], the data is encoded by the device-side SCAP and LTP, and then decoded by the server-side SCAP and LTP. In addition to the SCAP/LTP features, the hl2gener device-side library implements an advanced network provider management system, which improves the QoS and offers a downlink data queuing mechanism.

In this document, a device-side -application- is a software application using the SCAP/LTP features as a library, or communicating with an SCAP/LTP powered modem. The application is typically written by a product integrator, who takes advantage of the high-level SCAP/LTP features.

The server-side -application- is the end user application presenting data gathered by all its related devices.

This document presents the different device-side and server-side features implemented by SCAP/LTP.

The LTP (Lightweight Transmission Protocol) protocol lies directly on top of the LPWAN protocols. It handles the differences between network types, and provides high level uplink and downlink buffers with application-defined sizes.

The LTP layer is between the LPWAN layer and the SCAP layer

4.2.4. LTP-Segmentation

The MTU of the underlying networks ranges from 4 bytes to 235 bytes. This MTU depends on the network type (Sigfox or LoRaWAN), the region, and the dynamic link quality. The LTP segmentation allows an application to send up to 2K bytes [^3] of data regardless of the underlying network MTU. The segmentation is transparent: the application sends arbitrary data to the LTP layer, and the segmentation is computed on the fly. If no segmentation is required, none is performed. Otherwise each segment size is computed upon sending the segment, because the underlying MTU may vary with each uplink attempt.

4.2.4.1. Timings

The patented segmentation method [^4] relies on timing profiles. When a device sends a segmented message, the server needs additional information to recombine the complete message: it needs to know which segments are a part of a complete message and how to sort the sequence of segments. Instead of adding segmentation overhead in the LTP header, the device encodes the segmentation information in the inter-segment delays. The device uses specific timings between the following segments:

  • The first segment and the last one, when a message is sent in 2 segments

  • The first segment and the next one, when a message is sent in 3 or more segments

  • The second to last segment and the last one, when a message is sent in 3 or more segments

  • A middle segment to a middle segment, when a message is sent in 4 or more segments

  • The last segment of a message and the first segment of the next message. Two message sendings may not be closer than this.

Two segments

Three segments

More than three segments

Several messages

Knowing these timings, the LTP server is capable of reassembling the original message even if:

  • Several base stations send a copy of the same message

  • A segment is kept by an unreachable base station: the message is reassembled when the base station becomes reachable again and releases its stored segments.

The LTP server is also capable of detecting that a segment is missing, and no data may be reassembled.

The value of these timings is shared between the device and the server. The timings are given in second and may not overlap, a margin (in green below) should be used, for example:

Example timing profile definition

4.2.4.2. Example

A device has to send a message S which size fits in 3 segments. The devices sends the following segments:

  • The first segment s0 at t0

  • The second segment s1 at t1 = t0 + FTMD

  • The third segment s2 at t2 = t1 + MTLD.

Example of timing encoded segmentation

When the device sends the segment s0 at t0, the gateway receives it virtually immediately. It means that the message timestamp on the gateway is t0. The LPWAN gateway sends this timestamp along with the message s0 to the server. From t0, t1 and t2, the server is able to compute the time deltas x1 and x2.

x1 and x2 are the inter-segments delays. Knowing the predefined timing profile, the server computes that x1 is a "first to middle" delay and that x2 is a "middle to last" delay. the server deduces that s0, s1 and s2 are a complete message and that nothing is expected later, the server is able to reassemble the message S.

4.2.4.3. Side notes

A segmented message will take a longer time to be sent than a single-segment message, so less segmented messages may be sent than unsegmented messages in the same period of time. The timing profiles should also be computed to comply with the frequency usage rules. hl2gener provides canonical timing profiles which comply with the Sigfox and LoRaWAN networks.

Since LTP takes care of the uplink scheduling and the optional LoRaWAN join process, this protocol may induce a difference between the application schedule and the network schedule. Some care may be required when designing a time-critical application. LTP may only delay an uplink for the following reasons:

  • Segmentation timings

  • Frequency usage limitations

  • LoRaWAN join handshakes.

This advanced segmentation feature works for uplinks only. Downlinks are replied to uplinks and may not be scheduled at a specific time, thus it is impossible to implement this segmentation algorithm. Downlinks use a more traditional segmentation mechanism.

4.2.5. Encryption & authentication

The SCAP (Secure Constrained Application Protocol) protocol lies on top of LTP Segmentation and offers several application level features. It is independent of LPWAN-specific constraints, but induces a very small overhead.

The SCAP layer is between the LTP layer and the Application layer

The SCAP payload may optionally be encrypted and authenticated. An encrypted and authenticated message will be called a secured message in the following. The security mechanism is based on the AES GCM 256-bit algorithm. Both uplink and downlink messages may be secured. The application may, or may not, encrypt each message independently.

This added security induces a 15 bytes overhead, which implies automatic segmentation in some cases (when Sigfox is used for example). This overhead is composed of a 24 bits unique IV [^5]. This offers anti-replay protection, but limits the total number of secured messages to 224 (about 16.7 million messages). The rest of the overhead is a 96-bit authentication tag. The total SCAP payload size is limited to 2048 bytes [^6]. This is to prevent authenticated message forging, by leaking the smallest possible quantity of information. Note that the payload size may be any value from 1 bytes up to 2048 bytes, it is not restricted to a multiple of a block size. The security is active from the modem to the SCAP server [^7]. The modem and the SCAP server share a per-device, 32 bytes pair of uplink and downlink keys, which may be set on the production line or by the modem integrator.

The following table sums up the different security key points:

Feature Sigfox LoRaWAN SCAP
anti replay low medium high
authentication low medium (32 bits CMAC) high (AES-GCM 96 bits)
encryption low and optional medium (AES-128) high (AES-GCM-256)

4.2.6. Generic variable encapsulation

The SCAP protocol encapsulates variables. This payload is called a stream. 2 stream modes are provided:

Name Mode Type
RAW unstructured binary a single byte array
BIN structured binary 1 to 32 common scalar variable (e.g. a 32-bit integer)

4.2.6.1. BIN

A BIN stream contains 1 to 32 scalar variables and an ID ranging from 1 to 16.

The stream ID allows a device to send different kinds of messages.

The scalar variable data types are a subset of the C datatypes:

Type Range Comments
BOOL 0 - 1 boolean value
UINT8 0 - 255 8 bit unsigned integer
UINT16 0 - 65'535 16 bit unsigned integer
UINT32 0 - 4'294'967'295 (4e9) 32 bit unsigned integer
UINT64 0 - 18'446'744'073'709'551'615 (18e18) 64 bit unsigned integer
INT16 -32'768 - 32'767 16 bit signed integer
INT64 -9'223'372'036'854'775'808 - 9'223'372'036'854'775'807 (9e18) 64 bit signed integer
FLOAT32 -3.402823e38 - 3.402823e38 IEEE754 floating point number

4.2.6.2. A stream, its ID and its variables, contains the structure and the values but not the meaning of these values.

When a server receives a stream it is able to decode the ID value, each value data type and value but is not able to tell wether a variable represents a temperature, a distance or whatever. A mapping must be defined to tell the server that e.g. the first variable of the stream ID 1 is a temperature.

4.2.6.2.1. Use case example

Taking advantage of the edge computing, we are building a fridge monitoring device. Instead of measuring and sending the temperature every 10 seconds, the device acquires the data every 10 seconds (low current consumption) but send data (high current consumption) only when necessary.

To do so, the device send the following streams:

  • A periodical (once a day) stream containing the fridge temperature quartiles (C) and the battery level (%).

  • An alert stream if the temperature rises above a predefined level. This stream contains the temperature and the temperature slope (C/s) [^8]

  • An alert stream if the fridge door is left open for a predefined amount of time. This stream contains the temperature and the estimated time before the temperature rises above the predefined level based on the slope (s)

One possible implementation is:

  • Stream 1: ID=1

    • Var1=(FLOAT32, temperature min)

    • Var2=(FLOAT32, temperature Q1)

    • Var3=(FLOAT32, temperature median)

    • Var4=(FLOAT32, temperature Q3)

    • Var5=(FLOAT32, temperature max)

    • Var6=(UINT8, batteryPercent)

  • Stream 2: ID=2, var1=(FLOAT32, temperature), var2=(FLOAT32, slope)

  • Stream 3: ID=3, var1=(FLOAT32, temperature), var2=(UINT16, time)

On the server side, the temperature from the three streams may be merged on the same chart. A hook (SMS alerting for example) may be triggered when an alert is raised.

4.2.6.3. RAW

A RAW stream contains 1 byte array variable and its implicit ID is 0. The RAW mode does not have an explicit stream ID in order to reduce its optimized payload.

A server side decoder is generally required to parse the raw payload.

4.2.6.4. Use case example

We want a presence detection system to check every 10 seconds if a presence has been detected and this system has to work with Sigfox. The duty cycle [^9] forbids to send more than 1 message per 12 minutes on average.

The system stores a bit representing the presence (1 = presence, 0 = no presence) for each bin of 10 seconds. A parallel task triggers every 12 minutes the sending of this buffer (12m * 60s / 10s = 72 bits = 9 bytes).

On the server side, an application receive this buffer from our device management server and it is up to this application to analyze this data.

Along with the part_title and part_title layers, SCAP/LTP also comes with side-features enabling fast and robust application development.

4.2.7. Configuration

A device contains several configuration fields. The configuration is typically set once, on the production line, but may be set later and overwritten several times. It is possible to lock some of the configuration fields. If locked, every field may be read but not written unless otherwise specified below.

The number of write cycles is limited by the media on which the configuration is stored (typically flash or EEPROM), 10K is the usual lower value. Some parameters are known to be modified often, these parameters are stored on a separated wear leveled space.

4.2.7.1. AES keys

The device contains the 32 bytes uplink and downlink keys. When locked, it is not possible to read or write this field. A key is any random 32 bytes value. A key should not be reused for another device.

4.2.7.2. UUID

UUID (Universally Unique IDentifier) is a 128-bit number used to uniquely identify something. Each device has its own ID. The ID is a UUIDv4 (random) value.

4.2.7.3. Timing profiles

The LTP segmentation relies on timing profiles. These 5 values are stored in the configuration as tenth of seconds. A timing profile is also identified by a 64 bits EUI. These EUIs and the timings they refer to are meant to be shared among all devices and servers. A device may store up to 5 timing profiles.

4.2.7.4. Routes

A device application communicates with a server through one or several network providers (Sigfox, Orange, Loriot, ). Following is the schematic of the global workflow:

Messages from devices may flow through several routes

A network provider, together with some parameters, is called a route. A maximum of 2 Sigfox and 4 LoRaWAN routes may be registered on the same device.

Here are all the fields of a route on the device side:

  • A name

  • A region for frequency limitations (e.g. EU or US)

  • A timing profile EUI

  • A "secured stream" flag

  • The MTU

  • For Sigfox:

    • The TX power (up to 14 dBm in the EU region)

    • The downlink strategy (see below)

  • For LoRaWAN

    • The AppEUI

    • The AppKey

    • The class mode (only class A is implemented for now)

    • The retry count, the TX power, and the datarate for each retry

    • The ACK strategy (see below)

    • The join timeout

    • When to perform a new join depending on the total number of sent messages and the consecutive failed uplinks

The downlink strategy specifies when to request a downlink. A downlink necessarily follows an uplink. A device requesting a downlink will not get any if it has not been prepared by the server. The following strategies have been designed with segmentation in mind. If the uplink is not segmented, these strategies may be reduced to "always request a downlink/never request a downlink".

Strategy Description
never never request a downlink
while available a downlink is requested for the first segment. Request a downlink as long as a downlink is served for the previous segment
last request a downlink for the last segment
always always request a downlink

The "while available" strategy is typically useful when requiring a segmented downlink, because it will request a lot of downlinks, except when it is known that no downlink is available. The "last" strategy is typically useful when requiring one downlink per uplink. Since the downlink takes a long time, this allows to use shorter timing profiles than the "while available" strategy. Note that Sigfox downlinks are very limited (up to 4 downlinks a day).

The LoRaWAN ACK strategy is similar to the Sigfox downlink strategy. A LoRaWAN ACK always contains a downlink if a downlink is available on the server. A device may request an ACK or not, and a server may reply an ACK or not. The following ACK strategies are available :

Strategy Description
never never request an ACK
first request an ACK for the first segment
always always request an ACK

A device application may perform no ACKs because it is a paid service, for example. If no ACK is requested, the device automatically sends redundant uplinks. The redundancy count is dynamically defined by the LoRaWAN network.

4.2.7.5. Auto route

When a stream uplink is called, the stream may be sent through a specific route or using the "auto" routes: the first "auto" route is used, and if it is not reachable (an ACK has been requested but not received) the next "auto" route is used, until the message has been successfully sent or all "auto" routes are exhausted.

This list of automatic routes of a device must be defined before the device is able to use this auto route list. The auto route list may contain up to 6 routes.

If a route does not request an ACK, an uplink using this route is considered successful. Each time a LoRaWAN uplink is performed, the used route must have been joined. Switching from one LoRaWAN route to another implicitly joins the new route.

The auto route list is in the wear leveled space.

4.2.7.6. Sequence numbers

The uplink and downlink sequence numbers are used by the SCAP encryption. Each time an encrypted uplink is prepared, the uplink sequence number is internally incremented. Each time a complete encrypted downlink is received, the downlink sequence number is set to the received value (the IV of the SCAP header) after being checked for replay attacks.

The sequence number may range from 0 to 224. This is generally never used by the application. The single use case of initializing this to a non null value is to limit the number of transmission (e.g. set it to 224 - N - 1) to limit the number of transmission to N.

The sequence numbers are in the wear leveled space.

4.2.9. Degraded mode

If SCAP/LTP must be by-passed (demo, test, etc.) it is possible to use the degraded mode. In this mode, no SCAP/LTP specific features are available. In order to use this, construct a RAW stream and enable its "degraded" flag.

This chapter provides some hints concerning the design of an application. In order to illustrate these general hints, some example applications are used.

4.2.10. Improving the QoS

In this example, the goal is to maximize the chances of transmitting a message, ie. to improve the QoS. To do so, the application uses 3 routes : Objenious, TTN and Sigfox, and sets these routes to "auto" once in the modem life cycle. Both the Objenious and TTN routes require an ACK to detect when an uplink failed. When an uplink is requested, the following fallback actions occur:

  • The uplink is sent using the Objenious route

  • If the ACK times out, a retry is performed according to this routes retry profile

  • If all retries failed, the modem switches to the second "auto" route: TTN. The modem joins the route and tries to send the uplink using it.

  • If all TTN retries are exhausted, the modem tries to send it using the Sigfox route. No ACK is requested on this route, the modem stops checking if the uplink succeeded.

4.2.11. Sending a large message

In this example, the application sends a custom RAW payload (a byte array) of 57 bytes. Once again, the primary link is a LoRaWAN network - Loriot - and the backup link is Sigfox.

Reminder:

  • In the EU region, the LoRaWAN payload may vary from 44 bytes if the radio link is poor to more than 150 bytes 10 if the radio link is excellent.

  • The Sigfox payload is fixed to 12 bytes, and a maximum of 5 uplinks per hour are allowed.

If the message is sent using LoRaWAN, it will be segmented into 2 segments in the worst case. Using the hl2gener defined timing profiles, the Sigfox segmentation will result in 5 segments sent approximately every 45 s.

Note that only one message segmented in this way is allowed per hour.


  1. Depending on the communication rate. A sensor typically sends data 1 to 4 times a day 

  2. When data flows from a device to a server, this is called an uplink, When the data flows from a server to a device, this is called a downlink 

  3. The 2K bytes limitation comes from a security reason explained in the encryption related chapter 

  4. Patent numbers FR1655526 and FR1655527 

  5. Initialization Vector. A nonce. 

  6. In practice, the device RAM size may induce a lower maximum payload size 

  7. The encryption from the end user to the SCAP server is covered by other mechanisms, such as SSL 

  8. This is a simplified example, the temperature rising most likely follows an asymptotic curve 

  9. Radio usage regulatory limitation 

  10. The LoRaWAN documentation specifies that the maximum theoretical payload size is 235 bytes, but some providers apply a 177 bytes limit