Basic Station Protocol
There is no uniform update and configuration management. Providers of IoT platforms and LNS servers each use their own specially 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 connects to the CUPS server and configures itself using the CUPS protocol. Then the protocol requests and performs updates on a regular basis. For example, on the LNS server or an extra server, 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:
Possible in the future with Basic Station
If the Basic Station LNS protocol is implemented on the LNS server as an interface, data packets can thus also be transported without the detour 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 a centralized update and configuration management. Without this, gateways have to be installed "by foot" and it usually takes an expert to do it. With the Basic Station a big step towards plug'n'play solutions for LoRaWAN has been done. The next step is the implementation of the Basic Station LNS protocol via connector on the LNS servers.
- 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
The differences lie in the data transmission, which is partly limited to save energy (very often long-life battery).
Class A works according to ALOHA procedure, the sensor sends the data packets to the gateway, followed by two receive windows. During these receive windows the sensor can receive data. Outside of these receive windows, the data goes into the void.
Class B opens receive windows at specified times, for this the sensor and the gateway must be synchronized in time.
Class C is permanently open and receiving data. Class C sensors often require more energy than the devices of the other two classes.
The 1.00% duty cycle is understood to mean 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 Personalization), read more: Join Verfahren via OTAA or ABP
A packet multiplexer can be used to distribute LoRaWAN packets from a gateway to multiple network servers. However, this is only recommended for non-critical applications.
A self powered Gateway can also be directed to an own LNS/backend, which runs e.g. on a Raspberry PI or even on the gateway itself. This then simply has to 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 unknown to the foreign LNS, the risk is negligible. If you transmit critical data via LoRaWAN, we can advise you on further data protection measures.
To install this Web App in your iPhone/iPad press and then Add to Home Screen.