This feature is only available on Wirnet iBTS gateways.

Fine timestamps are the nanosecond accurate dates at which a packet are received by the gateway. Fine timestamps are generally used for Geolocalization algorithms.

1. An end-device sends a packet.
2. The Gateway:
   • Receives the packet from the end-device.
   • Retrieve the date at which it received the packet thanks to its GPS chip.
   • Splits the date (e.g. 2017-10-23 13:37:45 186ms 118µs 527ns) in two parts :
     • The classic timestamp: Contains the GPS time, number of milliseconds since 06 Jan.1980 (e.g. 1192801083186)
     • The nanosecond number: is the number of nanosecond elapsed since the last raw second of the classic timestamp (e.g. 186118527).
   • Encrypts the nanosecond number with an hardcoded AES key.
3. The Packet Forwarder:
   • Retrieves the classic timestamp and the nanosecond number.
   • Sends them to the LNS.
4. The LNS:
   • Decrypts the nanosecond number.
   • Sums the nanosecond number with the classic timestamp.

There is one specific AES key per LoRaLOC module. Without it, data cannot be deciphered. Contact support@kerlink.fr and provide them with the serial number of each gateway. They will provide you with the AES key of each LoRaLOC of each Wirnet iBTS.

The GPS is used by the gateway to retrieve fine timestamps. GPS synchronization (fix) can be monitored through NMEA frames and especially $GNGGA frames.

To see the NMEA frames coming from the GPS chip, issue the command cat /dev/nmea2.
parameters:

• 7th field - GPS fix 0=no fix, 1=fix GPS.
• 8th field - Connected satellites number of connected satellites (4 in following example).

$GNGGA,132911.00,4809.08287,N,00135.18250,W,1,04,4.47,96.1,M,47.7,M,,*69

A GPS fix value equal to 1 is required to use the fine timestamp feature.

When lorad is started with the -vv extra args, if the GPS synchronization is lost the following trace is logged If fix value is not equal to one, the following error will be displayed in the packet forwarder log:
Feb 13 11:18:24 klk-lpbs-050789 local1.info lorad[1390]: <6> PPS is disabled

International Atomic Time (TAI, from the French name “Temps Atomique International”) is a high-precision atomic coordinate time standard based on the notional passage of proper time on Earth's geoid.
As of 31 December 2016, when another leap second was added, TAI is exactly 37 seconds ahead of UTC.
TAI clock is obtained once the GPS synchronization is achieved. Note that it can take about half an hour.
A gateway uses TAI clock to retrieve fine timestamps whenever it is possible.

To check if TAI clock is OK, run the following command and check that both clocks have a difference of at least 37 seconds.

$ taiclock -d
CLOCK_REALTIME: res: 0. time:1550158205.428239230
CLOCK_TAI:      res: 0. time:1550158242.428243230

By default, fine timestamps are deciphered by the Application server of the LNS.
For debug purposes, fine timestamps can be directly deciphered from the gateway. Please note it should not be used in production environments.

To activate deciphering from the gateway, edit the frequency plan (in /user/etc/lorad/):

• “aes_key”: “00112233445566778899AABBCCDDEEFF”,
• “fine_timestamp_decrypt_enable”: true,

Packets received by gateways are sent to the LNS along with their meta-data in a JSON array as below:

{
  "rxpk": [
    {
      "aesk": 0,
      "brd": 23,
      "codr": "4/5",
      "data": "QCYAJQAAhHcZ3njAQQQ7+Qzqhdp2Qogmxw==",
      "datr": "SF7BW125",
      "freq": 868.5,
      "jver": 2,
      "modu": "LORA",
      "rsig": [
        {
          "ant": 0,
          "chan": 7,
          "etime": "7xkP+6rs/F/Y845JaB5pnQ==",
          "foff": 2944,
          "ftdelta": 0,
          "ftstat": 0,
          "ftver": 1,
          "lsnr": -3,
          "rssic": -116,
          "rssis": -122,
          "rssisd": 0
        }
      ],
      "size": 25,
      "stat": 1,
      "tmms": 1192801083186,
      "tmst": 64679556
    }
  ]
}

• tmms: classic timestamp: GPS time, number of milliseconds since 06 Jan.1980. This field is only present when GPS synchronization and TAI clock are OK.
• time: “time”:2017-10-23T13:37:45.570488Z. This field replaces the tmms field when GPS synchronization or TAI clock is not avaialble.
• etime:“etime”:“uONILwcR/z8069OwdklfaQ==”. nanosecond number - encrypted time.
• ftime: This field replaces etime when fine_timestamp_decrypt_enable is true. It contains the decrypted number of nanoseconds.

The AES Key is used to decypher the etime field.

AES key:

• Algorithm: AES-ECB.
• Key length: 128 Bits.

Hereunder is an example of script that decrypts the nanosecond number using OpenSSL.

This example is presented as is. It is not written to cover every possible exception. It is up to the user to adapt it to his needs.

openssl version

The etime field is an hexadecimal value which has been 64 base encoded. To retrieve the actual number of nanosecond from the etime value, the value needs to be divided by 32.

etime_dec.sh

#!/bin/bash
 
#checking parameters
if [[ $# -ne 2 ]];then
    echo 'Usage : ./etime_dec.sh <etime value> <AES 128-ecb-key>'
    exit
fi
 
ETIMEFIELD=$1
AESKEY=$2
 
# OpenSSL decyphering (convert from base64 to decimal, decypher, convert from bin to hex, remove trailing '0'
RESULT=$(echo -n $ETIMEFIELD | base64 -d | openssl enc -d -aes-128-ecb -K $AESKEY -nopad | xxd -u -p | sed 's/^0\+/0x/')
 
# Display data
echo "etime decyphered = $RESULT"
echo -n "etime real value = "
printf "%d / 10^9 / 2^5\n" $RESULT | bc -l

The following is an example of decyphering using the script mentioned above. For etime and ftime values refer to the previous JSON message:

 "etime":"7xkP+6rs/F/Y845JaB5pnQ==" 

chmod u+x etime_dec.sh
dos2unix etime_dec.sh
./etime_dec.sh 7xkP+6rs/F/Y845JaB5pnQ== 5FEAFD3647351BEB423F93CEF14A5DDB
etime decyphered = 0x162FE2FEE
etime real value = .18611852743750000000

The LoRa API takes place between a single server (lorad), which drives all LoRa related devices, and multiple clients (e.g. lorafwd) wanting to interact with these devices. Its main purpose is to provide abstraction of the LoRa devices to other processes.

The LoRa API allows three ways of communication:

• Receive data from lorad (uplink).
• Send data to lorad (downlink).
• Control lorad configuration (control).

The LoRa API defines a transport layer and a data exchange format.

• CPF 1.2.4: LoRa API
• CPF 1.2.1: LoRa API

• CPF 1.1.6: LoRa API

• CPF 1.0.9 for iFemtoCell: LoRa API
• CPF 1.0.9 for iBTS: LoRa API
• CPF 1.0.6 for iFemtoCell: LoRa API
• CPF 1.0.6 for iBTS: LoRa API

To compile one of the daemons, refer to the toolchain page and to the README.md included in the sources.

A tool to edit the lorafwd configuration is installed at the same time than the lorafwd. It can be used instead of editing manually the configuration file.

Examples:

• To enable database:
  • lorafwdctl database.enable true
• To configure GWMP node and services:
  • lorafwdctl -s gwmp.node foobar.example.com
  • lorafwdctl gwmp.service.uplink 1234
  • lorafwdctl gwmp.service.downlink 1234