TrackCentral overview¶

The following are trademarks or registered trademarks of TrackNet Inc, USA and Trackio GmbH, Switzerland in the United States, or other countries, or both: Tra`ckio, TrackNet, the TrackNet Logo, and TrackCentral.

Other company, product and service names may be trademarks or service marks of others.

All information contained in this document is subject to change without notice. The information contained in this document does not affect or change TrackNet Inc. or Trackio GmbH product specifications or warranties. Nothing in this document shall operate as an express or implied license or indemnity under the intellectual property rights of TrackNet Inc. or Trackio GmbH or third parties. All information contained in this document was obtained in specific environments, and is presented as an illustration. The results obtained in other operating environments may vary. THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS IS” BASIS. In no event will TrackNet Inc. or Trackio GmbH be liable for damages arising directly or indirectly from any use of the information contained in this document.

June 1, 2018

Preamble¶

Tracknet provides most advanced smart-connectivity solutions for the Internet of Things (IoT) enabling large-scale deployments, deep analytic insights, and new business models for IoT and Low-Power Wide-Area Networks (LPWAN).

The Tracknet IoT platform utilizes standardized LoRaWAN technology with its most scalable second-generation LoRaWAN network server (“TrackCentral”) at its core. TrackCentral has been specifically architected for large-scale inside-out deployments in which hundreds or thousands of tower-top gateways are augmented by potentially millions of low-cost indoor gateways serving billions of sensor and actuator devices. The inside-out deployment model is optimal to create dense deep-indoor network coverage at all scale-outs with a low cost structure for significant price segmentation from cellular connectivity.

Next to TrackCentral, the Tracknet IoT platform further comprises a highly efficient device run-time platform, portable gateway firmware, and additional network services which are crucial for scaling deployments such as device management, firmware updates over-the-air (FUOTA), and coverage prediction. The Tracknet IoT platform is completed by holistic analytics that provide deep insight into and facilitate goal-oriented optimization of network and application performance.

Tracknet is the top engineering team in LoRaWAN and has been instrumental to its definition from its infancy.

Internet of Things Market¶

The Internet of Things (IoT) is predicted by most in the technology sector to be the next high-growth market segment to drive the industry in the next decade. IoT encompasses many applications and technologies including Wi-Fi, cellular (4G / 5G), NB-IoT, Bluetooth, LoRaWAN, and others.

Internet of Things

Each of the technologies that will run IoT volumes has different trade-offs and will serve different applications based on application requirements.

Networks

It is now widely accepted by analyst, industry experts, and major enterprises that LPWAN will make up more than 40% of the total volumes expected for IoT. The LPWAN market again includes different technology options such as LoRa, NB-IoT, Sigfox, and Ingenue. LPWAN applications are typically ones that include battery-powered sensors deployed over wide areas and most need a low device cost and low connectivity cost to achieve a return on investment (ROI). LPWAN can either be a public network for many applications to utilize, typically paying an operator connectivity fees, or a dedicated private network deployed directly by the enterprise company or application provider.

LPWAN is a new and emerging market and LoRaWAN is a relatively new technology which has evolved since about 2012. The essential elements to drive new technology adoption and capability to scale to billions of devices are standardization and a large thriving ecosystem. The LoRa Alliance is the standardization and certification body for the LoRaWAN technology. The standardization by the LoRa Alliance allows any sensor or actuator device from the ecosystem to connect into and roam between different network providers. Interoperability and multiple different providers in the ecosystem ensure the technology can scale to the expected volumes for LPWAN and IoT.

Semtech LoRa™ and LoRaWAN™¶

Most of tomorrow’s data traffic will be generated by “things” rather than by human initiations. Yet the prevalent GSM network was not designed and is not a good match for the communication characteristics and requirements of future IoT applications:

Low-throughput with a strong uplink bias;
Low energy consumption for devices operating on batteries for years;
Long wireless range to reach into basements without repeaters;
Strong interference robustness, reliability, and security to avoid and prevent interruptions and vulnerabilities;
Compatibility with mobile, nomadic, and fixed things, and
Extreme cost-effectiveness to keep both initial investments and running costs low.

For this type of applications, Semtech Corporation has developed the LoRa™ radio modulation. Its high-level benefits are long range (up to more than 20 miles), long battery lifetime (up to more than ten years), and high robustness to interference.

Semtech LoRa¶

LoRa is a chirp spread-spectrum modulation integrated in Semtech RF receivers. It efficiently improves the sensitivity of the receiver compared to existing technologies and is optimized for low data rates as low as 0.3 kbps for maximum range up to 50 kbps over shorter distances.

A single elevated gateway or base station with the LoRa technology can cover entire cities with outdoor coverage and low cost, un-optimally placed indoor gateways can cover entire neighbourhoods typically within up to a mile range. While exact range and coverage highly depend on the environment or obstructions in a given location, LoRa and LoRaWAN have a link budget greater than most other standardized communication technology whereby link budget, typically given in decibels (dB), is the primary factor in determining range and coverage in a given environment.

The laws of physics dictate that the extended range of lower data rates compared to higher data rates comes at the cost of higher power consumption and spectrum usage due to extended airtime, though. LoRa therefore instead of one single data rate at maximum range further allows to dynamically adjust its data rate to the environmental conditions a device is operating in, effectively trading range against data rate and vice versa to always hit the sweet spot.

While common modulation techniques require the desired signal to be above the noise floor or interfering signal, LoRa can demodulate even below the noise floor. This attribute, combined with integrated error correction, provides unparalleled robustness to interference. In addition, like CDMA technology when different spreading sequences are used, LoRa signals are orthogonal or noise-like to each other, which enable simultaneous transmission of multiple LoRa signals on a single channel.

Unlike other spread-spectrum techniques, LoRa utilizes a non-linear architecture which optimizes the current consumption for maximum battery lifetime even more. To maximize both the battery life of devices and overall network capacity, the LoRa network infrastructure and each device cooperatively manage the data rate and RF output power for each device individually by means of an adaptive data rate (ADR) scheme, utilizing LoRa's capabilities of trading range against data rate on a device level and lifting it to the global network level.

LoRa is primarily utilized in the Unlicensed Industrial Scientific and Medical (ISM) bands below 1 GHz. Europe utilizes the 868 MHz band, North and South America from 902-928 MHz, China 470-510 MHz, and the rest of Asia is typically in the 920 MHz band. The LoRa physical layer is integrated into transceivers and microcontroller combinations produced by — at the time of writing — Semtech, ST Microelectronics, and Microchip.

LoRa Alliance LoRaWAN¶

The LoRaWAN™ network architecture takes advantage of the LoRa modulation to create high-capacity low-power wide-area networks (LPWAN). It has been architected and is maintained by the LoRa Alliance™, an open industry alliance that fosters LoRa and the LoRa ecosystem. The LoRaWAN network architecture has been designed in conjunction with the LoRaWAN Protocol Suite not only to make device design simple and interoperable with multiple networks but also to make multiple LoRaWAN networks from different vendors and operators interoperable with each other by means of roaming.

Network Architecture¶

The LoRaWAN architecture is designed from the ground up to optimize battery lifetime and cost of sensor or actuator devices while ensuring end-to-end security of the system. While mesh networks were popular in the past and enabled the roll-out of smart-meter networks, they have proven to be difficult to deploy, capital intensive, with not enough capacity to connect many different applications to a single network. Additional challenges are unpredictable latency, extra airtime consumption, and additional load imposed on routing devices at the cost of increased power consumption. If sufficient range is available, as with LoRa, a much simpler, more efficient and more reliable star topology is optimal to avoid the overhead of a mesh topology and easily push the network management to the cloud. To make such a star network viable, a high-capacity concentrator or base station is required. Semtech enabled this high capacity by creating a concentrator chip which is a multi-channel, multi-modem receiver.

In a LoRaWAN network, for reasons of redundancy and minimum network management overhead for mobile devices, sensor or actuator devices are not associated with a specific gateway. Instead, data transmitted by a device is typically received by multiple gateways.

Each gateway will forward the received packet from the device to the cloud-based network server via some backhaul (either cellular, Ethernet, satellite, or Wi-Fi). The intelligence and complexity are pushed to the network server, which manages the network and filters redundant received packets, performs security checks, schedules acknowledgements through an optimal gateway, and performs other network management functions like data-rate adaption (ADR). If a device is mobile or moving, there is no hand over needed from gateway to gateway, which is a critical feature to optimize asset tracking applications.

Battery Lifetime¶

The devices in a LoRaWAN network operate asynchronously and only communicate when they have data ready to send, whether event-driven or scheduled. This type of protocol is typically referred to as the ALOHA method. In mesh networks or with synchronous networks such as cellular, devices frequently have to ‘wake up’ to synchronize with the network and check for messages. This synchronization consumes significant energy and is the number one driver of battery lifetime reduction. Most apple-to-apple technology comparisons including ones done by the GSMA show LoRaWAN having a 3 to 5 time advantage in battery lifetime over other LPWAN technologies.

Network Capacity¶

In order to make a long-range star network viable, gateways must have a very high capacity or capability to receive messages from a very high volume of devices. High network capacity in a LoRaWAN network is achieved by utilizing adaptive data rate and by using a multichannel multi-modem transceiver in the gateway so that simultaneous messages on multiple channels can be received. The critical factors effecting capacity are the number of concurrent channels, data rate (time on air), payload length, and how often a device transmits.

Since LoRa is a spread spectrum-based modulation, the signals are practically orthogonal to each other when different spreading factors are utilized. As the spreading factor changes, the effective data rate also changes. The gateway takes advantage of this property by being able to receive multiple different data rates on the same channel at the same time. If a device has a good link and is close to a gateway, there is no reason for it to always use a lower data rate and fill up the available spectrum longer than it needs to. By shifting the data rate higher, the time on air is shortened, opening up more potential space for other devices to transmit. Adaptive data rate also optimizes the battery lifetime of a device. In order to make adaptive data rate work, symmetrical up link and down link is required with sufficient downlink capacity. These features enable a LoRaWAN network to have a very high capacity and make the network scalable.

A network can be deployed with a minimal amount of infrastructure, and as capacity is needed, more gateways can be added, shifting up the data rates, reducing the amount of overhearing to other gateways, and scaling the capacity by 6 to 8 times. Other LPWAN alternatives do not have the same scalability as LoRaWAN.

Sensor and Actuator Device Classes¶

Sensor or actuator devices serve different applications and thereby have different requirements. In order to optimize a variety of application profiles, LoRaWAN utilizes different device classes. The device classes trade off network downlink communication latency versus battery lifetime. In a control or actuator-type application, the downlink communication latency is an important factor.

Bi-directional Devices (Class A): Devices of Class A allow for bi-directional communications whereby each device's uplink transmission is followed by two short downlink receive windows. The transmission slot scheduled by the device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). This Class A operation is the lowest power device system for applications that only require downlink communication from the server shortly after the device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink.
Bi-directional Devices with Scheduled Receive Slots (Class B): In addition to the Class A random receive windows, Class B devices open extra receive windows at scheduled times. In order for the device to open its receive window at the scheduled time, it receives a time-synchronized beacon from the gateways in its proximity. This allows the server to know when the device is listening. Due to the additional receive windows, Class B devices have higher power consumption than Class A devices yet still can be battery-powered for long periods of time up to years.
Bi-directional Devices with Maximal Receive Slots (Class C): Devices of Class C have almost continuously open receive windows, only closed when transmitting. This provides the lowest latency when downlink communication is needed at the cost of higher power consumption since the device is continuously listening. Class C devices therefore are typically either main-powered or operated in combination with power sources like solar panels in combination with buffer batteries to compensate power fluctuations.

It should be noted that devices may be dynamically switched from, say, Class A to Class C and vice versa as needed.

Device Classes

Security¶

LoRaWAN defines two different levels of cryptographic security, one to ensure message integrity and one to encrypt application data. Both make use of the Advanced Encryption Standard (AES), which is sanctioned by the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). The LoRaWAN protocol has been validated by independent security experts, and more than 600 companies have already adopted the technology, including Cisco, IBM, Comcast, Samsung, Alibaba, Orange, Swisscom and South Korea Telecom, to name just a few.

According to LoRaWAN, each device is assigned a pair of unique device-specific AES session keys when joining a LoRaWAN network, whereby these keys are derived from unique device-specific keys embedded in the device during manufacturing. One session key is used to ensure message integrity (network session key), while the other session key is used to encrypt application data (application session key). Application session keys are only known to the device and its corresponding application server. That is, whenever a device sends data, this data is encrypted with the unique device-specific application session key before actually transmitting over the air, only to be decrypted by the corresponding application server.

Network session keys, in turn, are only known to the device and LoRaWAN network server to allow the network server to perform integrity checking of any data relayed, and thereby ensure that all data is in a valid format and from a genuine device. All application data always remains encrypted during integrity checking and message relay. No other components of the network, including gateways and routers, have access to any device-specific keys, neither network nor application keys. Gateways and routers merely pass encrypted data on to the LoRaWAN network server and have no association with a specific device or any ability to decrypt and view application data.

In short, when a device sends data, it is encrypted with a unique device-specific application session key and henceforth stays encrypted from the device to the application server. Even in the unlikely event of someone intercepting or listening into a transmission, the unwanted eavesdroppers will only observe encrypted data. Each device further can only be associated with a single account. The device-specific keys of any device also have no value to other devices since only one session key pair per device is valid in the network at any point in time ensuring no duplicate devices in the network.

There are many trade-offs in every technology choice but the LoRaWAN features in network architecture, device classes, security, scalability for capacity, and optimization for mobility address the widest variety of potential IoT and LPWAN applications that need to be low cost and battery powered.

Target Applications¶

LoRaWAN is optimal for applications that need battery powered, low cost sensor or actuator devices that need to last for years without (battery) replacement. The LoRa physical layer is optimized for small amounts of data every few minutes or a few times per hour. It is not optimal for sending large amounts of data frequently. Applications that the LoRa technology serve well include (but are not limited to) logistics, supply chain, asset tracking, smart cities, smart building, home automation, smart metring, smart agriculture, and smart consumer.

Deployment Models¶

LoRa and the LoRaWAN network architecture specifically enable different deployment models. With a link budget greater than cellular technologies, existing tower locations can be utilized to deploy a LoRaWAN network, whereby only relatively few gateways are needed to achieve decent outdoor coverage in most countries. Indoor coverage in general, and deep indoor coverage for underground sensor locations like basements in particular, is quite costly to achieve with a pure tower deployment, both in terms of capital expense (CapEx) and operational expense (OpEx).

For deployments aiming at indoor coverage, a more effective strategy both in terms of CapEx and OpEx is an inside-out hybrid deployment model. Outdoor gateways installed on towers still provide light outdoor coverage as a basic service while a significantly larger number of LoRa indoor gateways, possibly combined with other radio technologies such as Wi-Fi, provide deep-indoor coverage. Furthermore, those indoor gateways still contribute to network density and overall outdoor coverage and, if deployed sufficiently dense, allow more devices to use higher data rates and shorter on-air-times for a better utilization of the radio spectrum, increased overall downlink capacity, and additional redundancy.

TrackCentral Architecture and Design Principles¶

TrackCentral is a most scalable LoRaWAN Network Server (LNS) that connects LoRaWAN-compliant devices to application backends in a star of stars topology. It is the first of a new generation of LoRaWAN Network Servers specifically designed along the following guiding principles:

Carrier-grade robustness and security according to the latest industry standards in a true multi-tenancy architecture;
Proven multi-dimensional scale-out both for devices and gateways to facilitate large-scale (country-wide) traditional tower-based deployments as well as hybrid deployments following the inside-out deployment model with potentially millions of gateways;
Future-proof modular low-latency design that allows applications to respond to uplinks in real time, and replace or augment key algorithms like for data-rate adaptation as the network evolves; and
High degree of deployment flexibility in both dedicated and hosted environments (LoRa Network Server as a Service, LNSaaS) facilitating a broad range of customer requirements.

Gateways, so-called Stations in TrackCentral parlance, are connected to TrackCentral via standard, secured IP connections while devices use single-hop LoRaWAN communication to one or many Stations. TrackCentral, in turn, relays messages between Stations and any number of application backends. It further provides a network operator with all the network management functionality required for large-scale (country-wide) deployments.

Core Components¶

TrackCentral consists of the following core components: TrackCentral Station on-gateway packet forwarder (“Station”), TrackCentral Dispatch LNS core (“Dispatch”), TrackCentral IO application router (“IO”), and TrackCentral Terminal management console (“Terminal”).

Core Components

TrackCentral Station¶

TrackCentral Station is the TrackCentral on-gateway packet forwarder software, which

bi-directionally relays traffic between devices and Dispatch, adding operational meta-data such as timestamps, received signal-strength indicators (RSSI), and signal-to-noise ratios (SNR);
protects the backhaul link between the Stations and Dispatch as well as Dispatch itself from malicious traffic.

Stations can be remotely managed including firmware upgrades via Terminal and a dedicated gateway management system (“CUPS”).

TrackCentral Dispatch¶

TrackCentral Dispatch bundles all the core LoRaWAN network management functionality, allowing for multi-dimensional scale-out both at the device and gateway level. As such it

ensures the integrity of messages received from devices, relaying only those messages that are cryptographically verified as genuine to the respective IO instances serving as proxies for device-owning application backends;
schedules all downlink communication initiated either from within TrackCentral (Dispatch, IO, or Terminal) itself, or from application backends in accordance with the regional regulations imposed on transmitting downlink messages;
optimizes device connectivity per device and across the overall device population by performing dynamic data-rate adaptation for devices mounted at fixed locations or nomadic devices during periods of rest;
manages the security and compliance of the infrastructure and devices deployed by performing regulatory sanity checks, blacklisting misbehaved devices, and issuing new cryptographic keys on demand in cooperation with the respective join servers;
collects and (pre-)aggregates usage data for network operation and billing.

Although shown as a single component, Dispatch internally is built from a larger number of sub-components for horizontal scale out on demand.

TrackCentral Dispatch

TrackCentral IO¶

TrackCentral IO instances are representatives of application backends interfacing with Dispatch for connectivity, typically (but not necessarily) under the control of the application owner. Conceptually there is one IO instance per application backend that

relays traffic between Dispatch and the customer application backend;
performs all application-level cryptographic encryption / decryption operations on behalf of the application backend.

Separating the IO functionality from Dispatch is key for the true multi-tenancy infrastructure of TrackCentral. In contrast to integrated solutions, with TrackCentral the network operator is never given access to device-specific application keys and decrypted application payloads unless explicitly authorized by the application owner. Limiting access following a strict need-to-know model protects both the network operator and the application owner likewise.

TrackCentral Terminal¶

TrackCentral Terminal is the management and administration component that

provides maintenance and operational interfaces for network operators;
provides operational statistics and deep-inspection tools for network management and optimization across all components;
allows device and gateway management including remote gateway configuration and firmware updates for network operators and application owners.

TrackCentral Services¶

Besides the aforementioned core components, TrackCentral further comes with a couple of support services such as

TrackCentral Gateway Management System (“CUPS”): Remote gateway configuration and management for connecting TrackStations;
TrackCentral Join Server: Implements the join-server functionality of LoRaWAN 1.1 and authorizes new devices towards different LNS instances (including TrackCentral) in response to over-the-air activation requests;
TrackCentral Coverage Prediction: Provides coverage estimates for hybrid LoRaWAN deployments of both indoor and outdoor Stations;
TrackCentral OTA Firmware Updates: Remote over-the-air firmware updates for devices with corresponding ready-to-use on-device library.

Design Principles¶

TrackCentral has been designed from ground up along the lines of multiple design principles, which should be considered essential of any LNS for large-scale (country-wide) LoRaWAN deployment. It thereby is the first of a new generation of LoRaWAN network servers built to meet not only the requirements of today's but also of tomorrow's large-scale LoRaWAN deployments.

Carrier-grade Security with Multi-tenancy¶

A key guiding principle of any large-scale multi-user infrastructure must be to separate the operator (owner) of an infrastructure from the users of that infrastructure as much as possible. Certain information necessarily must be exchanged and shared to allow, for example, the operator to verify that connecting user devices are genuine and that the integrity of messages routed through the infrastructure is preserved. Other information, though, is purely application-specific and shall never leave the hands of the user unless explicitly authorized.

The LoRaWAN MAC protocol already has been designed with multi-tenancy in mind by separating per-device network session keys from application session keys, yet not all LNS implementations follow that design and still require the application owner to share application-level keys with the network operator, often under the disguise of added convenience. Such an integrated approach bears several risks, though. From a user's perspective, plain application data is in the hands of the network operator and may be used for data harvesting and analytics beyond pure message routing. A network operator having access to plain application data, in turn, runs a much higher risk that user data may leak or is stolen, possibly facing severe financial risks and reputation damages. It further becomes vulnerable to lawful intercept requests from authorities.

TrackCentral therefore has been architected to strictly separate the network operator from the users of the network by its separation of LNS core functionality and application-router functionality in separate components, namely Dispatch and IO, respectively. Application owners can deploy their private IO instances on their premises and completely under their control, so no plain application data is ever leaked to the network operator. For less privacy-sensitive applications, though, the network operator still can offer to host a user's IO instance for convenience but at least knowingly enters into the responsibilities coming along with such an arrangement.

Hybrid Deployments with Proven Scalability¶

With a pure tower-based deployment aiming mainly at providing outdoor coverage, the number of gateways in any given LoRaWAN network is comparatively small, ranging from a couple of thousands to maybe a couple of ten-thousands for even the largest countries. While feasible for smaller territories, moving from outdoor to deep indoor coverage becomes already more challenging, if only from a cost perspective. For larger territories, a pure tower-based deployment for deep indoor coverage even becomes prohibitively expensive.

The hybrid inside-out deployment model, which combines basic outdoor coverage by tower gateways with extended outdoor and deep indoor coverage contributed by indoor gateways, therefore is most compelling for almost all but the smallest territories. Yet, while financially attractive, such a hybrid infrastructure has its own set of technical challenges, which must be properly reflected in the architecture of the LNS.

First, for mid-size to large territories the absolute number of gateways connected to the LNS can easily grow beyond what first-generation LNS were designed for. A single cable operator in the US, for example, could easily end up with 20 million connected gateways, which is way more than originally anticipated for purely tower-based LoRaWAN deployments. Next to the connectivity itself, this further demands not only a much more elaborate gateway management infrastructure but also must be reflected across all network management algorithms and schemes like dynamic data-rate adaption.

Second, the performance characteristics of the backhaul used by indoor gateways may become very unpredictable in terms of latency, bandwidth, and possibly general availability. Indoor gateways very often will just get a free ride on some consumers Internet connection, which is very cost-attractive but introduces a high degree of variance to gateway backhaul management compared to a pure tower-based model. This requires special care by the LNS when, for example, scheduling downlink messages to hit downlink receive windows and managing receive window delays.

TrackCentral is atop of all these requirements from the ground up. Its scalability further has been proven and is constantly re-validated by a large-scale simulation and load-generation environment through which hundreds of thousands of simulated gateways and millions of simulated devices with varying traffic patterns can be run against a TrackCentral instance.

Future-proof Modular Low-latency Design¶

For devices of Class A, downlink opportunities are potentially rare and valuable. Consider a smart water meter only checking in once a month. Missing the two downlink windows (of which the first one is highly preferable due to its channel diversity) after an uplink means that the next downlink opportunity is 30 days away. It is therefore crucial to minimize the data-path latency from the receipt of an uplink message by a gateway to its delivery to at the application server, and vice versa.

TrackCentral is utilizing a fast-path architecture in which not only data-path processing is kept at a minimum, but also operations such as uplink de-duplication are handled asynchronously to the application server uplink. The preferred connection method to the application server further is a web socket, although other connection methods such as MQTT are also offered for non-latency-sensitive applications.

Lots of in-the-field experience further has made it clear that for certain key algorithms and policies there is no “one size fits all” solution. A typical example is data rate adaption, which obviously should work very different for stationary devices reporting rarely versus mobile trackers with uplink intervals as short as 30 seconds when in motion. Network density is another parameter to factor, possibly requiring data rate to be adapted differently in urban areas with dense coverage versus more rural areas just served by just a few tower gateways.

In TrackCentral therefore all key algorithms are factored out in a modular way to be easily adjusted or replaced independently without affecting other components of the platform. In addition, multiple policies can be installed next to each other and assigned to devices or groups of devices as needed based on parameters like device type or deployment location.

Deployment Flexibility¶

With LoRaWAN deployments moving beyond pilot and trial phases, LoRaWAN network operators will be confronted with an increasing variety of demands from prospective network users. The simplest users just will ask for basic connectivity at the lowest cost with hardly any performance guarantees. The most demanding users, in contrast, will require dedicated compute resources within the LNS or possibly even like to in-source certain functionality on their own infrastructure. To accommodate such a broad range of requirements a high degree of flexibility must be designed into the architecture of the LNS at all levels, from the gateway connectivity layer to the LNS cores to the application backend integration, which inherently will replace today's often monolithic LNS implementations with federated LNS implementations like TrackCentral.

TrackCentral Station¶

Gateways are bi-directional wireless connection relays between devices and LoRaWAN network servers such as TrackCentral. For this, each gateway is equipped with one or multiple LoRa gateway modules per supported band (e.g., 868 MHz, or 915 MHz). TrackCentral Station is the on-gateway software of TrackCentral and compatible with a broad range of current and future commercially available LoRa gateways from different manufacturers.

Message Relay¶

TrackCentral Station connects to TrackCentral Dispatch via an IP link, typically reusing an existing wired, Wi-Fi, or cellular backhaul link. All communication over this IP link is TLS protected using certificates to ensure that both Station and Dispatch are genuine (i.e., cryptographically authenticated to each other), and that all traffic between TrackStation and Dispatch is encrypted.

Uplink messages from devices forwarded by Station to Dispatch are accompanied by operational meta data such as a receive timestamp, the received signal strength (RSSI), the signal-to-noise ratio (SNR) as well as the channel and spreading factor (SF) used by the device for the LoRa radio transmission of the uplink message. Since a device is typically in the range of multiple gateways, each LoRa uplink message is eventually relayed by multiple Stations to Dispatch, which performs de-duplication of uplink messages yet aggregates all meta data.

If an acknowledgement for a LoRa uplink message has been requested by the device or if some downlink data is pending for a device, Dispatch schedules a downlink communication based on the meta data provided by the different Stations for the latest uplink message received from the device and under consideration of any applicable radio emission regulatory requirements such as duty-cycle limitations of all the gateway candidates. Dispatch then sends a fully formatted LoRa downlink message (potentially with no application payload if the downlink communication is just an acknowledgement or consists solely of LoRa MAC commands) to exactly one Station of its choice together with a relative timestamp describing at what time the gateway shall transmit that downlink message. The timestamp is set by Dispatch to be in line with one of the two receive windows every device opens after sending an uplink message. The Station selected will buffer the LoRa downlink message until it must be sent. This way, latency fluctuations on the backhaul link between Station and Dispatch are mitigated for as long as the latency does not exceed a certain threshold. If latency exceeds this threshold, downlink messages are dropped because they cannot be sent on time by Station.

Security¶

Station itself further does not accept any external connection requests but only operates on connections initiated by Station itself. Dispatch and CUPS, in turn, only accept connection requests from TrackStations with properly issued and still valid certificates.

Station further uses TLS with certificates to connect and authenticate to Dispatch, and to encrypt any communication between Station and Dispatch. For initial deployment, each Station is either pre-personalized with an IP address and matching certificate for some specific Dispatch instance or CUPS, TrackCentral's gateway management and configuration service. When first powered up, Station then uses this pre-personalization information to establish an initial connection and retrieve its actual configuration before becoming fully operational.

Uplink messages from devices with no designated application owner registered with a given Dispatch instance and which do not qualify for roaming can be cut off already by Station. For this, Dispatch may distribute a whitelist or blacklist of globally unique device identifiers to Station, identifying those devices that shall be allowed or forbidden to communicate via these gateways, respectively. Any other traffic then will be discarded by the receiving Stations without further notice.

TrackCentral Dispatch¶

TrackCentral Dispatch comprises all LoRa Network Server core functionality distributed across a couple of internal components each of which again may be present in multiple instances. Most prominently Dispatch contains a De-Mux Fabric (“Fabric”) for connecting gateways and multiplexing uplink and downlink messages, LNS Engines (“Engine”) for the actual processing of all message exchanges and the maintenance of device states, and Downlink Orchestrators (“Orchestrator”) per territory scheduling all (potentially competing) downlink messages from different Engines for that territory.

De-Mux Fabric¶

TrackCentral is designed not only to support tower-based LoRaWAN network deployments with a moderate number of tower Stations but specifically for hybrid LoRaWAN network deployments with potentially multi-million indoor Stations. All Stations therefore do not connect directly to LNS Engines for the actual message processing but rather to a De-Mux Fabric that multiplexes and de-multiplexes uplink and downlink messages from and to a given device. Each Fabric instance connects to all the Engines responsible for each particular device, and all the Orchestrators of the territories from which the Fabric instance connects Stations. Stations are configured with at least two separate De-Mux Fabric instances for fail over recovery.

Message Relay¶

TrackCentral Dispatch receives uplink messages from devices indirectly via Stations and its internal Fabric whereby each message itself is typically received multiple times depending on the number of Stations a device has in its proximity. To facilitate arbitrary scale out as well as being flexible in terms of distributing devices across different physical or virtual hardware, message processing within Dispatch is handled by a dynamically growing number of LNS Engines across which the total device population is distributed. For each incoming message, the Engine responsible for the device the message is received from performs several steps such as

dropping message duplicates received via different gateways;
cryptographically verifying the integrity of the message;
performing sanity checks to ensurethat the device is behaving properly;
collecting meta data for downlink message scheduling; and
collecting usage data for network operation and billing

before eventually forwarding the message to the TrackCentral IO application router associated with the device during activation.

If the device asks for an acknowledgment upon reception of an uplink message by Dispatch, or there is a downlink message pending for a given device, Dispatch decides which Station shall transmit the downlink communication and the time when this downlink message shall be sent (i.e., at the beginning of the first or second receive window of the respective device). Since this decision can become increasingly complex with the number of Stations deployed as in hybrid LoRaWAN deployments, Dispatch is using a separate component to orchestrate downlinks. These so-called Downlink Orchestrators have certain territorial understanding which influences the choice of a particular Station from the overall set of Stations that have received the last message under consideration of all potentially competing downlinks from all Engines. The decision is further governed by several parameters including the latest reported signal strengths (RSSI), signal-to-noise ratios (SNR), and any applicable regulatory requirements such as duty-cycle limitations of all the gateway candidates. Furthermore, if some application data from the application router is pending or some MAC commands are outstanding for the device, acknowledgments may be piggybacked with that message.

Device and Network Management¶

Beyond message relaying and scheduling, Dispatch is also responsible for participating in over-the-air activation of devices in conjunction with the join server responsible for a given device and dynamic data-rate adaptation.

For devices that are activated after deployment over the air, Dispatch participates in the join procedure of the over-the-air activation. For incoming join requests, Dispatch ensures that the join server corresponding to the join-server identifier embedded in the join request is known and genuine; otherwise the join request is dropped. It then forwards the join requests to that same join server and, if the join server grants the device access to the network, Dispatch schedules the downlink message from the join server to the device like for any downlink message as described before, and registers the new device under its device address together with the network session key provided by the join server. In addition, it passes on the encrypted application session keys as provided by the join server to the corresponding IO instance of the application owner.

Depending on the signal-strength indicators (RSSI) and signal-to-noise ratios (SNR) of uplink messages received from a device, Dispatch may request the device to participate in data-rate adaption to improve the signal quality and data rate, optimize overall bandwidth utilization, and reduce the power consumption of the device. The data-rate adaption scheme, as described in more detail in the LoRaWAN MAC protocol specification, essentially moves devices to the spreading factor with the highest data rate and shortest range feasible for a given device. To become eligible for data-rate adaption, a device must declare itself as having a fixed position which could either be due to the device being mounted at a fixed position indeed, or due to the device being actually mobile but predicated to stay in the same position for a longer period of time (i.e., be nomadic).

As a side effect of the data-rate adaption scheme, the number of Stations that receive messages from a single device is kept at a minimum further maximizing usage of the bandwidth available, unless a minimum redundancy (i.e., a device is in reach of a minimum number of Stations) must be preserved on behalf of the network operator. That is, the cell size of the network is dynamically optimized, allowing for on-demand densification of the Station infrastructure by deploying new Stations specifically where needed as the number of message exchanges increases and the demand for bandwidth exceeds the capacity of those Stations installed. For this Dispatch keeps track of the bandwidth used by each individual Station and signals potential bandwidth shortages.

Security and Alarms¶

Dispatch plays an important role in the security model underlying LoRa networks, especially considering that devices themselves generally cannot be considered tamper-resistant. That is, it must be assumed that a skilled adversary may extract or replace device-specific keys of a single device with moderate effort, or may replicate a device. Furthermore, the impact on the normal network operation from traffic initiated by malfunctioning devices or malicious devices with non-valid keys must be minimized and isolated.

For uplink messages, the sanity and security checks performed by Dispatch include:

validating the device address of the sending device;
cryptographically validating the integrity of the message with the device-specific network session key for that same device;
validating that the device adheres to any applicable regulatory requirements such as duty-cycle limitations to detect traffic from misbehaved devices.

Devices whose messages have repeatedly failed any of the aforementioned checks, or devices performing over-the-air activation and having repeatedly issued join requests with an unregistered join server or that have been rejected by the designated join server may be blacklisted by Dispatch at the Stations. Blacklisting of individual devices is reported to the network operator via the alarm interface of TrackCentral Terminal. Devices that are blacklisted are also reported to their IO application router (if any) for the application owner to take corrective measurements.

It should be noted that the network cannot reasonably protect itself from denial-of-service attacks against or radio jamming of individual gateways. That is, one must assume that it is always possible for a skilled attacker to effectively take Stations out of the network. The network in response tries to isolate the impact of such attacks on the backhaul link between the Stations under attack and Dispatch, and Dispatch itself. Yet the ability to perform data-rate adaption enables devices to regain connectivity to the network via Stations farther away than their "preferred" Stations if those becomes unavailable. It should be acknowledged, though, that a coordinated jamming attack against all Stations serving one region can effectively block LoRa communication in that region. In such case Dispatch can only notify the network operator of such attacks.

Deployment and Scale-out¶

The architecture of Dispatch is primarily driven by two objectives: Deployment flexibility and multi-dimensional scale out. By splitting Engines, Orchestrators, and Fabric into separate entities, which can be deployed on different physical or virtual machines, a broad range of different deployment scenarios can be realized, from single large networks to multiple co-existing networks of different sizes that only share the Fabric, to co-located devices of multiple application owners on the same Engine. This is somewhat like common web-hosting offerings nowadays.

Allowing each component to scale-out individually on demand, that is, Engines, Orchestrators, and Fabric likewise, TrackCentral can scale out not only in terms of number of connected devices but also in terms of number of connected gateways, and even geographically in terms of territory covered with certain components being dedicated to certain sub-territories.

Definitions and Acronyms¶

Acronym	Definition
AbP	Activation by Personalization
ADR	Adaptive Data Rate
AES	Advanced Encryption Standard
CAPEX	Capital Expenditure
DC	Duty Cycle
DR	Data Rate
ETSI	European Telecommunications Standards Institut
HSM	Hardware Security Module
IoT	Internet of Things
KPI	Key Performance Indicator
LoRa™	Long Range
LPWAN	Low Power Wide Area Network
MAC	Medium Access Control
M2M	Maschine to Maschine
MTBF	Mean Time Between Failure
NAT	Network Address Translation
OPEX	Operating Expense
OtA	Over the Air
PER	Packet Error Rate
PKI	Public Key Infrastructure
PoC	Proof of Concept
REST	REpresentational State Transfer
RF	Radio Frequency
RSSI	Received Signal Strength Indicator
SaaS	Software as a Service
SF	Spreading Factor
SMTP	Simple Mail Transfer Protocol
SNMP	Simple Network Management Protocol
SNR	Signal to Noise Ratio
SSH	Secure SHell
TLS	Transport Layer Security
VPN	Virtual Private Network