Skip to main content

Architecture Overview

Overview​

TEKTELIC KONA Core Network Server connects your LoRaWAN® gateways to your own systems. Between them, a few parts each do one job: they accept gateway connections, process LoRaWAN messages, decode the data and deliver it. When you know which part does what, you know where to look when data doesn't arrive.

This article describes what each part does, not how KONA Core is deployed. To set up each part, follow the guides linked in each section.

How it works​

The parts of KONA Core​

PartWhat it doesWhere you see it
Gateway connectionAccepts the connections of your gateways, over MQTT or UDP. Gateways forward the devices' radio messages through it, and receive the downlinks to transmit.Gateways: the Online and Activity columns
Network serverRuns the LoRaWAN protocol for each device: it checks each uplink, tracks the frame counters, runs ADR and schedules downlinks in the device's receive windows.The device's Advanced network settings and Real-time packets tabs
Join ServerHandles the join of OTAA devices. The UI calls it the "JS component of the NS": during the join, it and the device derive the device's session keys.The device's Activation tab
ApplicationsGroup devices. Each device belongs to exactly one application, and the application decides where the device's data goes.Applications, Devices
Payload convertersIn the UI: Data converters. A data converter is JavaScript code that decodes the raw bytes of an uplink into data, and encodes data into bytes for a downlink.Data converters
IntegrationsDeliver the decoded data of an application to your system, and accept downlinks from it. Each integration belongs to one application and uses one data converter.The application's Manage integrations page
Gateway managementSends commands, configuration and firmware to gateways over MQTT. Both MQTT and UDP gateways provide events and statistics; UDP gateways don't produce MQTT-specific events.The gateway's details panel, Gateway logs
Alarms and eventsRecords events and alarms for gateways, devices and integrations, with or without alarm rules. Sends notifications by the alarm rules you set.Alarms, the Events tab of a gateway
ManagementThe web UI and the REST API, with the tenancy levels System, Provider, Customer and Sub-Customer. Each level sees and manages only what it owns.The whole UI, and the API Reference

A Sub-Customer works with its own applications and devices, and applications assigned by its Customer. It has no gateway pages. For what each level sees, see Tenancy Model.

How gateways connect​

A gateway connects to KONA Core in one of two ways. You allow each way per gateway, with the options Allow UDP connection and Allow non TLS MQTT connection.

MQTTUDP
Used byKONA gateways, with the TEKTELIC MQTT Bridge on the gatewayThird-party gateways, with the Semtech packet forwarder
SecurityTLS by default. A connection without TLS works only when Allow non TLS MQTT connection is selected. KONA gateways use port 8883 with TLS and port 1883 without TLS. TLS has been required by default for new gateways since release 2.6.13.No TLS. Uses UDP port 1700. Works only when Allow UDP connection is selected.
Sign-inUsername and password, set in Manage credentials for the gatewayNo sign-in.
Device dataUplinks and downlinksUplinks and downlinks
Remote managementCommands, configuration and firmware upgradesNo gateway commands, configuration or firmware upgrades.
Events and statisticsGateway events and statistics, including MQTT eventsThe same events and statistics, except MQTT-specific events.

We recommend MQTT with TLS whenever the gateway supports it. It encrypts the connection, and only an MQTT gateway can take gateway commands.

Each hosted region runs its own network server, and each gateway connects to the host of its region. For the host values and the gateway configuration, see Onboard a KONA Gateway via MQTT and Onboard a Third-Party Gateway via UDP.

The full path​

An uplink passes the parts of KONA Core in this order:

  1. Device: sends an uplink over LoRa® radio.
  2. Gateways: every gateway in range receives the uplink and forwards it, with radio data such as RSSI and SNR, over MQTT or UDP.
  3. Network server: checks that the uplink comes from a known device, has a valid MIC and isn't a replay. It keeps one copy when several gateways received the same uplink (deduplication).
  4. Application: the network server passes the uplink to the device's application.
  5. Integrations: each integration of the application takes the uplink.
  6. Payload converter: the integration's data converter decodes the bytes into data.
  7. Your system: the integration delivers the data, for example as an HTTP request or an MQTT message.

A downlink goes the other way:

  1. Your system sends data to an integration, or you add the downlink in the UI or through the REST API.
  2. Payload converter: for a downlink through an integration, the data converter encodes the data into bytes.
  3. Network server: puts the downlink in the device's downlink queue and sends it in one of the device's receive windows.
  4. Gateway: transmits the downlink over LoRa radio.
  5. Device: receives the downlink.

Logical KONA Core data path with gateway connections, network server, application, integration and data converter, plus the Join Server for OTAA

For each step in detail, with the checks, queues and timings, see Uplink & Downlink Data Flow.

Where payload converters and integrations sit​

Payload converters and integrations sit after the network server, at the application level. The data converter is the part that turns the bytes into values.

  • One application, several integrations. An application can have several integrations, for example one HTTP and one MQTT. Each integration gets every uplink of the application that passes its filters.
  • One data converter per integration. You select the Data converter when you add an integration. Two integrations of the same application can decode the same uplink in different ways.
  • Filters per integration. Allow messages with ports limits the integration to uplinks on the ports (FPort) you choose, or Allow all ports. Send empty payload decides whether uplinks without data are delivered.
  • Integration types. In Type, you choose how the data leaves KONA Core. The types are HTTP_V2, MQTT_V2, MQTT_BROKER, the legacy HTTP and MQTT, and types for specific IoT platforms.

The integration types differ in who connects to whom:

TypeHow the data leaves KONA Core
HTTP_V2KONA Core sends an HTTP request to the address and port of your server.
MQTT_V2KONA Core connects to your MQTT broker and publishes to the Push Topic.
MQTT_BROKERYour system connects to the MQTT broker of KONA Core. Credentials and topics are created when you save the integration.

We recommend the V2 types for new integrations. HTTP and MQTT are the legacy V1 types: see Migrate from V1 to V2. To compare the types and choose one, see Integrations Overview. For the converters, see Payload Converters Overview.