Implementing an indoor localization system such as Fieldtracks includes designing a network infrastructure for transporting and processing sensor data. This blog post outlines its design and challenges.

Components

From a bird’s-eye view, the Fieldtracks system consists of several components, illustrated in figure 1:

Components in Fieldtracks
Fig. 1: Components in Fieldtracks

Typically, users access the system using smartphones and laptop computers:

  • When using a smartphone, users broadcast their position using Bluetooth Low Energy (BLE) beacons. These beacons are received by JellingStone when scanning.
  • The graphical user interface (Fieldmon) is accessible using https. Optionally, Fieldmon can be installed as a Progressive Web Application (PWA).

BLE scanning and additional beaconing is implemented by JellingStone using ESP32 µControllers.

Message Queuing Telemetry Transport (MQTT) is used as a distributed middleware system. It provides publish and subscribe interfaces to JellingStone and Fieldmon and takes care of data propagation and retaining scanning results.

Besides MQTT, a nginx service is used to provide basic storage functionality. This includes serving Fieldmon’s artifacts and assets. It is not used for scanning data or results.

Flashtool and StoneAggregator are the two backend processes used in Fieldtracks.

  • The Flashtool is installed on portable computers (e.g. Raspberry Pi) to provision ESP32 devices plugged in locally. It is controlled using Fieldmon.
  • The StoneAggregator provides data transformation. Data received from MQTT is aggregated and distributed using retained messages.

Network architecture

In essence, the network has to be designed to provide MQTT-connectivity in a robust and scaleable manner. A few requirements exist for the network, that have to be reflected in its architecture:

  1. The network must provide IP-connectivity for ESP32 devices using wireless lan (IEEE 802.11). Focusing on indoor deployments, the network is also utilized by users accessing Fieldmon.
  2. The network has to scale according to the people taking part in a field exercise. It has to handle up to ~1000 devices.
  3. Smartphone users roam between regions with and without cellular connectivity (3G / 4G / 5G). Fieldmon and MQTT have to be accessible using the public internet as well as a local on-site network.
  4. Labyrinthine environments (e.g. old mines) are rather unfriendly radio environments shadowing stations. Thus, the network has to deal with highly unstructured mesh connections resulting in potentially large layer-2 segments.

Figure 2 illustrates the networking architecture. It contains cloud- and on-site services, an on-site network and a vpn.

Networking architecture
Fig. 2: Networking Architecture

The on-site network is a heterogeneous mesh network. It connects mobile terminals (e.g. smartphones) and JellingStone sensors (not shown). Different technologies can be used for implementing the on-site networks. Due to providing IP-connectivity, it can be built using ethernet cabling (e.g. Cat5) and more eccentric technologies such as 802.11s, vlans, MPLS or DSL. IPv4, DHCP and NTP services are provided within the network.

If a site has internet connectivity (e.g. LTE / DSL), an on-site vpn uplink is used, to connect the on-site network to additional servers in the cloud. If multiple, distinct uplinks are available, the vpn is used to support roaming within the on-site network.

MQTT and WebDAV can be hosted on site (on-site-services - e.g. using a raspberry by) or cloud-based (cloud services) using virtual machines or both in parallel. This creates an unified, omni-channel view. Mobile Terminals can seamlessly access Fieldmon using any network.

Network design and implementation

Implementing the actual network has both simple and challenging tasks. On the one hand, using just MQTT and WebDAV, there is no need for a sophisticated middleware including many services. On the other hand, integrating cloud- and on-site services while providing a consistent and unified view is challenging.

In its simplest form, a Fieldtracks network consist of a commercial, of-the-shelf LTE hotspot connecting a dozen of ESP32 devices to a MQTT-Broker running on a cloud based virtual machine.

Gluon appears to be a promising framework for implementing the on-site network. Using batman-adv, 802.11s and VPN-services Fieldtrack’s requirements are reflected in many Freifunk networks. It also focus on non-expert users. However, its single channel mesh approach introduces limits on client density.

Summary

Using just MQTT and WebDAV, Fieldtracks poses rather simple requirements to the network infrastructure. Deploying a scalable network for a field exercise is a challenging task, still. MQTT’s distributed capabilities make it interesting for hybrid cloud- and on-site deployments.