There is no cost to test the network.
Hardware For End Devices / Nodes
At a minimum, there needs to be a MCU, LoRa modem, antenna and power source. Typically there will also be a number of sensors or controllers plus a range of optional extras such as GPS, accelerometers, solar charging, etc.
To run the LoRaWAN network stack (software), there are two choices- either onboard the LoRa modem or by a single MCU running both the network stack and application software. See Developers for details.
Joining The Network
End devices or nodes have to “join” the network before being able to send data. This is detailed in the LoRaWAN specifications for public networks.
The first join option is OTAA (Over The Air Activation). The customer needs to send the Device EUI and, optionally, the App EUI and App Key, to KotahiNet for enrolling the device on the network. Alternatively, these three parameters can be generated by KotahiNet and the customer needs to configure them on the end device or node.
The other join option is ABP (Activation By Personalisation). KotahiNet will provide the customer with Device Address, Network Session Key, and Application Session Key to configure on the device.
Transmitting Data
Data can be sent as confirmed or unconfirmed transmissions. In the former case, the network acknowledges receipt of each data transmission from the end device and is therefore recommended for better reliability.
End-to-end data encryption is both supported and recommended.
For stationary devices, Adaptive Data Rate (ADR) must be enabled. This is good both for the device (longer battery life) and the network (more capacity).
The network does not permanently store data received from the device or that sent to the device after it is sent. Our server caches a number of last received messages in a circular buffer. If you suspect some uplink messages have been missed, you can query the cache and retrieve the messages at a later point.
The data payload is in hexadecimal. For reliability, it should not exceed 100 bytes (which is several times the median size so should be more than enough). However, if required, larger data payloads can be divided across multiple data transmissions.
| Data Rate | Transmit Data Speed (kbps) |
Maximum Uplink Payload Size (bytes) |
|---|---|---|
| 5 (SF_7 125kHz) | 5.47 | 242 |
| 4 (SF_8 125kHz) | 3.125 | 242 |
| 3 (SF_9 125kHz) | 1.76 | 115 |
| 2 (SF_10 125kHz) | 0.98 | 51 |
| 1 (SF_11 125kHz) | 0.44 | 51 |
| 0 (SF_12 125kHz) | 0.25 | 51 |
Data Destination
The customer needs to choose the destination and protocol for their device data delivery. Data is delivered as a JSON object (uplink object structure).
To make testing easy and quick, KotahiNet provides a free web page as the default data destination. It is automatically and dynamically updated with the customer’s data payload and also includes diagnostic information like RSSI, SNR, spreading factor, frequency, etc
To send data to the customer’s chosen destination instead of the test web page, there are two options
- Any secure communication protocol. WebSocket (details) is preferred for efficiency. Other choices are TLS Socket, MQTT, HTTPS Push (details), and CoAP Push.
- Pre-integration is available for popular cloud services- Amazon AWS IoT (details), Azure IoT Hub (details), IBM Bluemix IoT Foundation (details), PubNub, Iron.io, myDevices Cayenne, Google IoT Core (details), and AllThingsTalk (details).
Sending Data/Commands To Device
As the network is bi-directional, data or commands can also be sent the other way, to the device via KotahiNet (“downlink”). Data is delivered depending on the device class- after the next transmission from the device (Class A) or immediately (Class C).
When using KotahiNet’s free default web page, data can be sent to your device from that web page itself by filling in the Device EUI, port, and data.
If transmitted device data is being sent to your preferred destination, such as say Azure IoT Hub or any of the other pre-integrated services above, the bi-directional integration provides for sending downlink data. In addition, data/commands can be sent using https push (details).
When using any secure communications protocol to get your transmitted device data, a JSON downlink request needs to be sent to our server to send data to the device. These requests are both acknowledged and data delivery confirmed.
Also see Network, IoT Networks, Use Cases, and Technology.