•    +49 36082 8477-99   -  Mo-Fr 08-18 Uhr
  • |
  • +49 36082 8477-98

Basic Station Protocol

Until now

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.

Individuelle Konfiguration und Datenübermittlung

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:
Basic Station LNS-Protokoll - Update und Konfigurationsmanagement

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!

Automatisiertes Update und Konfigurationsmanagement mit Basic Station Protokoll

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

To documentation


What does it mean if a sensor is class A, class B or class C?

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. 

What is meant by the 1,00% duty cycle?

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.

What is in a Join Accept Message?

A Join Accept message contains the AppNonce, the NetID, the DevAddr, the DLSettings and the RxDelay.

What are the two onboarding procedures for LoRaWAN devices?

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.

Do I need to use any LoRaWAN network server, or can I just run this on my private network?

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 This LNS is completely sufficient and recommendable for private applications, as no fees are charged and a free account can be opened.

Can I prevent another gateway from receiving my data or prevent my gateway from receiving data from other sensors?

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.

I have another question and need support

You can use the support of our IoT experts request here.

You have further questions? Then contact us!

To install this Web App in your iPhone/iPad press and then Add to Home Screen.