Basic Station Protocol
Previously
There is no uniform update and configuration management. Providers of IoT platforms and LNS servers each use their own developed interfaces. Thus, experts are always needed to integrate gateways into a network.
Current with Basic Station
With a CUPS server and the CUPS protocol, update and configuration management is already significantly simplified. The Basic Station is implemented on the gateway, which includes the CUPS protocol and the LNS protocol. The gateway with Basic Station establishes a connection to the CUPS server and configures itself using the CUPS protocol. The protocol then regularly requests and carries out updates. On the LNS server or an extra server, for example, the station2pkfwd package is integrated, which acts as an interface between the Basic Station LNS protocol and the LNS server.
station2pkfwd package integrated on an intermediate server:
Future possible with Basic Station
If the Basic Station LNS protocol is implemented as an interface on the LNS server, data packets can thus also be transported without the diversions via the station2pkfwd converter, thus clearing the way for a future plug'n'play of LoRaWAN!
Why is the Basic Station available and what are its advantages?
The Basic Station is an implementation for LoRaWAN gateways with centralised update and configuration management. Without this, gateways have to be installed "by foot" and it usually takes an expert to do this. With the Basic Station, a big step has now been taken towards plug'n'play solutions for LoRaWAN. The next step is the implementation of the Basic Station LNS protocol via Connector on the LNS servers.
Advantages:
- The commissioning of gateways becomes much easier
- Portable C code that depends only on the GNU libc
- Brings two powerful backend protocols with the LNS protocol and the CUPS protocol.
- Support of LoRaWAN classes A, B and C
- Authentication via client certificate or authentication token possible
- Easy handling with Linux-based gateways and embedded systems
FAQ`s
The differences lie in the data transmission, which is partly limited to save energy (very often long-lasting battery).
Class A works according to the ALOHA method, the sensor sends the data packets to the gateway, followed by two reception windows. During these reception windows, the sensor can receive data. Outside of these reception windows, the data goes into the void.
Class B opens reception windows at set times, for this the sensor and the gateway must be synchronised in time.
Class C is permanently open and receives data. Class C sensors often need more energy than the devices of the other two classes
The 1.00% duty cycle means that only 1.00% of the past hour can be used for the time window of the data transmission.
A Join Accept Message contains the AppNonce, the NetID, the DevAddr, the DLSettings and the RxDelay.
OTAA (Over The Air Activation) and ABP (Activation By Personalisation), read more: Join procedure via OTAA or ABP
A packet multiplexer can be used to distribute LoRaWAN packets from a gateway to several network servers. However, this is only recommended for non-critical applications.
A self-powered Gateway can also be directed to your own LNS/backend, which runs on a Raspberry PI or even on the gateway itself, for example. This must then simply pass on the measured values via MQTT or similar. For processing the data via third-party gateways, you need a LoRaWAN network server (LNS). Here we recommend thethingsnetwork.org. This LNS is completely sufficient and recommendable for private applications, as no fees are charged and a free account can be opened.
No, this cannot be avoided. However, since your data packets are encrypted and your Sensor is not known to the foreign LNS, the risk is manageable. If you transmit critical data via LoRaWAN, we can advise you on further data protection measures.
You can call on the support of our IoT experts inquire here.