IoT over LoRaWAN/Sigfox

Supported device types and versions
Communication line configuration
Communication line parameters
Communication station configuration
Station parameters
I/O tag configuration
Literature
Document revisions

Supported device types and versions

The protocol allows communication with devices communicating using the LoRaWAN and Sigfox protocols.

The LoRaWAN protocol is a protocol designed for occasional, energy-efficient wireless transmission of a small amount of data called payload (typically several bytes) over long distances between linked objects - in LoRaWAN terminology called mote (typically battery-powered sensors) and LoRaWAN gateway.
The gateway can then communicate directly with the D2000 COM process or send the payload to the network servers or to the cloud, where data processing is performed (deduplication, filtration), followed by the data sent to the D2000 COM process. In any case, the payload is packed in an envelope (e. g. such as a field in a JSON message or in a CSV file) and transferred up to the D2000 COM process. The payload is decoded there (using Base64 encoding or Base64 + Base16 encoding) and processed.
Payload processing is dependent on device type (defined in parameter of Device Type protocol).

The communication was tested between sensors and LoRaWAN gateway Kerlink IoT Station 868. It was, depending on the installed firmware:

• sending data directly to the D2000 COM process (JSON messages in UDP packets)
• sending data to the cloud TheThings.Network, from where it was read by D2000 KOM process (JSON messages in MQTT protocol through TCP connection)
• sending data to the cloud Loriot.io, which was forwarding them via MQTT to iot.eclipse.org, from where it was read by D2000 KOM process (JSON messages in MQTT protocol through TCP connection)

The Sigfox protocol is similar to LoRaWAN, and it uses different frequency bands. It uses the infrastructure built by Sigfox and its partners and messages (with a maximum payload size of 12 bytes, and a maximum frequency of 140 messages a day) are transmitted to the cloud (backend.sigfox.com) from which they can be obtained through the REST API.

The communication was tested between sensors and the Sigfox cloud using curl utility to retrieve data via https.

Communication line configuration

Configuration for LoRaWAN protocol:

• Communication line category: SerialOverUDP Device Redundant, TCP/IP-TCP, File I/O.
• Configuration of SerialOverUDP Device Redundant line:
• Local port: port, where the D2000 KOM process receives UDP packets
• Primary / Backup Device: IP address LoRaWAN gateway
  (pre Connection Type=Kerlink IoT Station SPN)
• Port: port, where the LoRaWAN gateway receives UDP packets (currently unused, as there is no implemented record)
• Configuration of TCP/IP-TCP line:
• Host: IP address of server, to which the D200 KOM process connects or redundant addresses separated by a comma or semicolon
  (for Connection Type=MQTT client)
• Port: server port, to which the D200 KOM process connects

Configuration for Sigfox protocol:

• Configuration of File/IO line:
  • Input file: name of the directory where data (JSON files) downloaded from the Sigfox cloud will be located. A symbolic constant #APPDIR#, which specifies application directory, may be used, e.g. #APPDIR#\Sigfox_input (or #APPDIR#/Sigfox_input in case of Linux).
  • Archive: name of the directory where data files will be moved after being processed. The KOM process will move the data files after processing to the subdirectories of this directory, which will be named according to respective stations (e.g B.Sigfox_1) and it will adds a time stamp indicating the processing time (e.g. a file msg_21FDA7.txt) may be archived as msg_21FDA7_2018-10-26 -06-26-08.txt).
    Similarly to the input file, a symbolic constant #APPDIR# may be used, e.g. #APPDIR#\Sigfox_archiv
    Note 1: Invalid files or files for which no station has been identified will be moved to the subdirectory BAD after processing.
    Note 2: If the archive directory is not specified, all files will be deleted after processing.

Communication line configuration

Communication line - configuration dialog - Protocol parameters tab.
The parameters influence some optional protocol parameters. The following protocol line parameters can be used:

Table 1

Line parameters tested for Connection Type=Kerlink IoT Station SPN towards Kerlink IoT Station 868 with firmware SPN

Line parameters tested for Connection Type=MQTT client towards TheThings.network

Line parameters tested for Connection Type=MQTT client towards Loriot.io with following setup:

• Output via protocol MQTT
• MQTT broker: iot.eclipse.org
• MQTT topic: com/ipesoft/iot

Line parameters tested for Connection Type=MQTT client towards LoraLINK Slovanet:

* Note.: Timestamp is sent in local time. Station time settings are to be configured accordingly.

Communication station configuration

• Communication protocol "IoT over LoRaWAN".
• Station address: the address of the station is the identifier of the specific device (mote) that is in the Mote Field Name field.
  
  • for Connection Type=Kerlink IoT Station SPN is address a text representation of 8 byte LoRaWAN address (e.g. 00-00-00-00-21-1a-e3-c8)
  • for Connection Type=MQTT Client the address may be a text representation of 8 byte LoRaWAN address (e.g. 0018B2000000147D) or a symbolic address defined within MQTT server (e.g. fieldtestdevice)

Station parameters

Dialog station configuration - Protocol Parameter field.
They affect some optional protocol parameters. The following station parameter parameters can be entered:

Table 2

I/O tag configuration

Possible value types of I/O tags: Ai, Di, Ci, TxtI, Qi, TxtO.

{ 
  "rx": {
    "moteeui": "00-00-00-00-00-1e-fc-1d", 
    "userdata": {
        "seqno": 77, 
        "port": 1, 
        "payload": "NzM3RjAwZTgwMA==", 
        "motetx": {
            "freq": 868500000,
	    "modu": "LoRa",
	    "datr": "SF7BW125",
	    "codr": "4/5"
	}
     },
     "gwrx": [
        {
         "time": "2017-07-05 16:06:52",
	 "chan": 2,
	 "rfch": 0,
	 "rssi": -33,
	 "lsnr": 7.5
        }
     ]
  }
}
	

{
  "app_id":"ipesoft-test",
  "dev_id":"fieldtestdevice",
  "hardware_serial":"0018B2000000147D",
  "port":2,
  "counter":549,
  "payload_raw":"niNJElVwAYQ5UBYfBBBN",
  "metadata":{
    "time":"2017-08-10T08:12:26.06860368Z",
    "frequency":867.5,
    "modulation":"LORA",
    "data_rate":"SF7BW125",
    "coding_rate":"4/5",
    "gateways":[
      {
        "gtw_id":"eui-000000000003080b",
	"timestamp":705621508,
	"time":"2017-08-10T08:12:26.434682Z",
	"channel":5,
	"rssi":-34,
	"snr":7.8,
	"latitude":49.20927,
	"longitude":18.73184,
	"altitude":359
      }
    ]
  }
}
	

Literature

Links
Official website of LoRaWAN alliance https://www.lora-alliance.org/technology
Official website of MQTT protocol http://mqtt.org

Specifications and Standards
MQTT 3.1.1 specification http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html
ISO/IEC 20922:2016 http://www.iso.org/standard/69499.html

Descriptions of Data Formats and API
www.loriot.io - Application API Data Format https://www.loriot.io/home/documentation.html#docu/app-data-format
www.thethingsnetwork.org - API Reference https://www.thethingsnetwork.org/docs/applications/mqtt/api.html

Document revisions

• Ver. 1.0 - August 10th, 2017 - Document creation.
• Ver. 1.1 - August 25th, 2017 - Extended line configuration (Frame Type, Time Mask - UNIX, UNIXMS, PayloadEncoding - Base16), support of AdeunisRF LoRaWAN TEMP device and communication with Loriot.io.