Overview

A LoRaWAN network is organized in a star-of-stars topology in which gateways relay messages between end devices and a central network server at the backend.

The frequencies used by LoRaWAN depend on the geographic region and its radio spectrum regulations: 868 MHz (EU), 915 MHz (US) and 920 MHz (Asia).

The end-device performs random frequency hopping and can use any of the possible data rates.

The datarate of the connection can be changed by modifying the spreading factor in order to adapt to the range.

The communication between the devices and the network is bi-directional, both uplink and downlink messages are possible.

All communications are secured: the messages are encrypted using AES with a key length of 128 bits.

Three distinct classes of end-devices exist in the LoRaWAN protocol. For the moment, only 2 classes are used for Watteco’s sensors:

  • Class A (sleeping devices)

Downlink frames can only be transmitted after an uplink transmission by the sensor. Once the sensor sends an uplink frame, the end-device will open two receiving windows: RX1 and RX2, the network can then send on one of these windows a frame that will be taken into account by the sensor.

When a sleeping device is not transmitting a frame it goes into a sleep mode where it does not listen to the network. This mode permits to reduce a lot the consumption of the sensor.

  • Class C (awake devices)

The network can send at any time a frame; it will be received by the sensor. The device open receive windows continuously.

lorawan

End Device Activation

In order to have a correct communication between the sensor and the network server, the server needs to know that the sensor exists, and to know its identifier on the network, and how to communicate with it. In other words, any Watteco’s sensor working on a public or private network has to be commissioned on this network. Nevertheless, there is two different ways to associate the end-device to the network:

  •   OTAA

For over-the-air activation, end-devices must follow a join procedure before participating in data exchanges with the network server.

The join procedure requires the end-device to be personalized with the following information before it starts the join procedure: a globally unique end-device identifier (DevEUI), the application identifier (AppEUI), and an AES-128 key (AppKey).

  • ABP

Activation by personalization directly connects an end-device to a specific network.

Activating an end-device by personalization means that the DevEUI, the DevAddr and the two session keys NwkSKey and AppSKey are directly stored into the end-device and shared with the LoRaWAN server.

The network address of the sensor on the LoRaWAN network (DevAddr) consists of 32 bit, it identifies the end-device within the current network. The DevAddr is set on the 25 last bits of the DevEUI, and can be configured by a specific ZCL command. The nwkID is set to 0 by default.

Its format is as follows:
DevAddr

Example

DevEUI = 70B3D5E75E000001 → DevAddr = 00000001

DevEUI = 70B3D5E75F000002 → DevAddr = 01000002

All the information above  is provided at the delivery of the products.

Watteco devices work in both OTAA and ABP. When the device is switched on, its first attempt is to be connected in OTAA. If it fails, the device sends a frame with ABP configuration.

This process of association is repeated while the device is trying to connect to the network  by following a trickle timer which is multiplied by 2 after each try.

A specific reassociation feature (Only available on "Confirmed" Uplink Mode) is implemented by default in Watteco devices after each 4 days and after 100 frames if the sensor doesn't communicate with the network. It can be configured by a specific ZCL command (LoRaWAN Cluster).

Once the device is associated to the network, it preserves its applicative configuration and its mode of association even after a reboot. At the next reboot, the device works only in OTAA or ABP mode, dependly of the previous association. In ABP mode all network paramaters are preserved after rebooting. In OTAA mode, an association is done after each reboot.

End Device Communication

It is necessary to contact the operator to understand how to send downlink frames. The procedure can differ from an operator to another.

The communication between the end-device and the network is done through Fport 125.

Since April 2018, it is important to note that the sensor doesn't ask for acknowledgement by default. It is in "Unconfirmed" mode. It is possible to change this behaviour by sending a specific ZCL command (LoRaWAN Cluster). It is possible to verify the default setting directly in the .txt file including keys.

In order to give the possibility to the network to send data, the sleeping devices use a Trickle Timer system that permits to send regularly a Uplink frame to the network if no reports or batches have been configured. The Trickle Timer directly impacts the behavior of sleeping sensors.

trickle_timer_evolution

  • When a sleeping sensor is switched on, it sends almost immediately a void frame (a LoRaWAN frame without payload) to the network server. When the sensor is commissioned on the server, it answers  the sensor and acknowledges the void frame of the sensor.
  • At the beginning, the trickle timer is at 1 min. The trickle timer is multiplied by two after each sending until it reaches 24 hours. It is the maximum value of the trickle timer. When this limit it reached, a void frame will be sent every 24 hours.
  • A void frame will be sent by the end-device following this pattern if there is no report configured. If reports are configured on the device, the void frames will be sent until the trickle timer becomes bigger than the maximum reporting interval.

Applicative layer

The application layer protocol implemented in Watteco’s sensors leverages on ZCL binary format. This combination of ZCL on top of a low power LoRa network should not be confused with “ZigBee®” technology, which uses its own network layer, not based on LoRa and operating at 2.4GHz. Watteco sensors range can be up to 20 times the range of typical ZigBee® sensors.

Cluster

A cluster is a related collection of attributes and commands, which together define a communications interface towards the distant device. It is an application message, which may be a container for one or more attributes.

Different clusters has been implemented in order to manage Watteco sensors.

Attribute

This is a data entity which represents a physical quantity or state. This data is communicated  using commands.

In order to communicate with clusters and atttributes, it is possible to send generic commands.

End Point

The application protocol implements the notion of “Endpoint number” to enable multiple instances of each cluster type on a given device. Different clusterIDs may share a common endpoint number but two instances of a given clusterID must have different endpoint numbers.

The “Endpoint number” bits are distributed in the first byte of LoRaWAN payload as described below. Therefore an endpoint number can take 32 different values.

Fctrl (Frame Control) bitfield is encoded as follows:

Endpoint number (0-31)Reserved (Must keep these value)Endpoint number (0-31)!Batch report
bit 7bit 6bit 5bit 4bit 3bit 2bit 1bit 0
EndPoint_bit 2EndPoint_bit 1EndPoint_bit 0 (LSB)10EndPoint_bit 4 (MSB)EndPoint_bit 30: Batch
1: others

The following table gives the corresponding Fctrl to each Endpoint number:

FctrlEndpoint
0x110
0x311
0x512
0x713
0x914
0xB15
0xD16
0xF17
0x138
0x339

Two types of reports exist in the applicative feature of Watteco sensors:

Standard report

It sends a report on a periodicity or on a variation of the measure.

Three  fields are important to configure a standard report:

Minimum reporting interval: minimum elapsed time since last “sending”, to accept “sending” a new sample.

Maximum reporting interval: maximum time without “sending” a new sample. When this time is elapsed, a new sample is automatically “sent”.

The minimum and maximum interval fields are on two bytes and define an interval in minutes or seconds depending on the first MSB bit as defined below:

minmax

Reportable change: minimum change on which a sample is sent.

To disable the configuration of a device, change the value of the minimum and maximum sending interval and the delta to 0.

A codec tool is available in python to decode the Standard report.

Batch report

It is used to concatenate, horodate and compress several samples of measure in the same reporting frame.

Discriminating usual zcl frames from batch report frames is done through the bit0 of Fctrl:

• 1: Usual ZCL frame (report or not)

• 0: Batch report frame.

The important fields to configure a batch report, are considered as below:

Field index: Each batch configuration is associated to a specific cluster/Endpoint/Attribut, however some clusters have multifield reportable attributes. The “Field index” parameter allows selecting the field to be reported in the attribute.

Most of the time this 1 byte “field index” is 0, like in clusters Temperature, Humidity, Binary, … But sometime it is necessary to define the requested field inside the attribute like in clusters Configuration, Simple metering or TIC.

Minimum recording interval: minimum elapsed time since last “recording”, to accept “recording” a new sample.

Maximum recording interval: maximum time without “recording” a new sample. When this time is elapsed, a new sample is automatically “recorded”.

The batch report is done on the minimum of the Maximum record interval of all batch’s configuration.

If “Batch” is set on more than one Cluster/Attribute/Endpoint then the effective “Maximum reporting interval” of the batch is configured to the minimum of them.

Recordable change: minimum change on which a dated sample is recorded. The Data type of this field is the same than the reportable value itself.

Resolution: it has the same format of the Recordable change and specify the resolution of the returned measure.

Tag value: it defines the “Label” representing the compressed measure in the “batch reporting” frame.

This field is one byte decomposed in two fields: 0bxxxxxzzz: zzz are the number of bits used for the Label size. The Label itself is contained in xxxxx, it is defined by a specific Endpoint/Cluster/Attribute/Field.

Even if a batch reporting could contain up to 6 different tags (different reported values), it will be pertinent to have only a few attributes values for a batch reporting. It is necessary to  limit this according to the overall radio

performances, current protocol, sampling parameter requirement and physical profile measurement.

Tag requirements according to reports measures in a batch:

–All Tags have to be the same size

–All defined Labels have to be different than those that already exit.

–To make a new configuration, it is necessary to use the same label of the specific measure.

–It is important to dimension the size of the Tag related to the number of measures which will be batched. Longer the tag is, bigger the “batch reporting” will be.

Label numberTag labelTag size
1 or 20/11
3 or 400/01/11/102
5 or 6 or 7 or 8000/001/010/011/100/101/110/1113
.........

Procedure to define the tag value

 

•Define the number of measures to include in the batch report → Tag size

•Choose a label for each measure → Tag label

•Choose a resolution for each measure, the more it is small, the less measures will be compressed.

Uncompress batch tool

 

In association with the sensors, Watteco provides a software tool useful to uncompress the batch report payloads send by the Watteco’s sensors.

This software is provided as an executable and is called br_uncompress on a Linux OS or br_uncompress.exe on a Windows OS.

Usage

br_uncompress [-a] tagsize "taglabel, resolution, sampletype" "..."...

-a: The utility br_uncompress is called with the option -a, it says to the program to consider the buffer as ASCII hex bytes.

tagsize: the number of bits used for the label

The last triple argument list: each element of this list corresponds to an attribute which is batch reported. The parameters are:

–The label used to identify the attribute reported

–The resolution of the attribute

–The sample type of the attribute (it is specified in each cluster).

Interpretation of the uncompress tool results

After executing the command, the tool will give back a lot of text as answer. The results of the uncompression will be at the end of this answer after the label “UNCOMPRESS SERIE”:

UNCOMPRESS SERIE

cnt: number of counter

Timestamp

Timestamp  Label  Value

The first value is the frame counter of the batch frame sent by the sensor, it allows to identify a frame.

After the counter, all the other results can be seen as a column:

–The first column gives timestamps: the one in the first line corresponds to the sending time  in seconds of the batch frame; after this one, all the others are the sampling time of the corresponding values.

In order to know the absolute sampling time for all the attribute values it is recommended to use the timestamp of the frame sending as a reference.The time of reception is known by the client, therefore from these two data and by doing a difference with the timestamp of each sample it is possible to find out the absolute sampling time for each value.

–The second column contains the label of each batch reported attribute.

–The third column contains the values of the batch reported attribute.

Download the br_uncompress tool

Generic commands

For each command, there is a generic format for the different features, it is listed as below:

  • Read attribute request
FctrlCmdIDClusterIDAttributeID
1 byte0x002 bytes2 bytes
  • Read attribute response
FctrlCmdIDClusterIDAttributeIDStatusAttribute typeData
1 byte0x012 bytes2 bytes1 byte1 byte-
  • Configure reporting

Standard command

FctrlCmdIDClusterIDReservedAttributeIDAttribute typeMinimum reporting intervalMaximum reporting intervalReportable change
1 byte0x062 bytes0x002 bytes1 byte2 bytes2 bytes-

Batch command

FctrlCmdIDClusterIDBatch AttributeIDField indexMinimum recording intervalMaximum recording intervalDelta recordable changeResolutionTag
1 byte0x062 bytes1 byte2 bytes1 byte2 bytes2 bytesThe size depends on the attribute typeThe size depends on the attribute type1 byte
  • Configure reporting response

Standard command

FctrlCmdIDClusterIDStatusReservedAttributeID
1 byte0x072 bytes1 byte0x002 bytes

Batch command

FctrlCmdIDClusterIDStatusReservedAttributeID
1 byte0x072 bytes1 bytes0x012 bytes
  • Read reporting configuration

Standard command

FctrlCmdIDClusterIDReservedAttributeID
1 byte0x082 bytes0x002 bytes

Batch command

FctrlCmdIDClusterIDReservedAttributeID
1 byte0x082 bytes0x012 bytes
  • Read reporting configuration response

Standard command

FctrlCmdIDClusterIDStatusReservedAttributeIDAttribute typeMinimum reporting intervalMaximum reporting intervalReportable change
1 byte0x092 bytes1 byte0x002 bytes1 byte2 bytes2 bytes-

Batch command

FctrlCmdIDClusterIDStatusBatchAttributeIDField indexMinimum recording intervalMaximum recording intervalDelta recordable changeResolutionTag
1 byte0x092 bytes1 byte1 byte2 bytes1 byte2 bytes2 bytesThe size depends on the attribute typeThe size depends on the attribute type1 byte
  • Report attribute

Standard command

FctrlCmdIDClusterIDAttributeIDAttribute typeReportable change
1 byte0x0A2 bytes2 bytes1 byte-

Batch command

Fctrl 
0b.......0Use br_uncompress to decode the frame
  • Write attribute no response
FctrlCmdIDClusterIDAttributeIDAttribute typeData
1 byte0x052 bytes2 bytes1 byte-
Print Friendly