Koch Laboratory

UrbanMesh — resilient urban IoT networks

Six directions in low-power sensor networks that keep working when the internet and mains power are gone.

Koch Laboratory — UrbanMesh: Research on Resilient Urban IoT Networks

Alongside its research into metadata-resistant communication, Koch Laboratory runs the UrbanMesh programme — research into resilient, low-power sensor infrastructure for cities: devices that keep working even when the internet and mains power are gone. The common thread with the rest of the lab: the system aims to be fault-tolerant and trust-frugal — a single low-cost node unites three radio technologies, and data survives loss of connectivity. The directions below resolve concrete, unsolved technical problems for which no off-the-shelf solution exists. Deployment context: the NearStadt platform (local retail).

Method. Each direction runs as a process: problem statement → hypothesis → firmware prototype → field measurement → evaluation → revision. Versioned firmware (FIRMWARE_VERSION history), measurement logs and backend tests preserve the result across iterations.

Publication note (IP). Techniques that are state of the art (TTL flooding, HMAC-OTP, duty-cycling) are described; specific, potentially patentable mechanisms — in particular routing with the power class as a parameter — are withheld. Where “Construction: withheld” appears, the detail is retained as filing material.

1. Tri-radio coexistence on a single node (LoRa + BLE + WiFi)

Research question. Can continuous LoRa reception (868 MHz), cyclic BLE-iBeacon advertising and periodic WiFi uplink run simultaneously on one low-cost chip (ESP32-S3), given that WiFi and BLE share the 2.4 GHz band and the WiFi stack is blocking? Why it is hard. WiFi connection, time sync and HTTP upload take seconds — during which the device goes “radio-deaf” to LoRa. Open: a non-blocking time scheme that keeps mesh reception alive through the WiFi phase, without watchdog resets. Approach. Non-blocking radio polling instead of delay(), a controlled BLE↔WiFi switching sequence, measurement of packet loss during uplink windows. (Non-blocking patterns are good engineering practice — general level published; any non-obvious sequence optimisations handled separately.) Status: implemented; field validation in progress.

2. Offline-resilient mesh (store-and-forward)

Research question. How does data reach the backend when a node loses internet or power — via neighbouring nodes, with delivery as guaranteed as possible? Why it is hard. Delivery rate depends on unknown, fluctuating node density; collisions must be damped, the buffer protected against overflow (DoS), and a reboot survived without loss or duplication. Approach (state of the art). TTL-bounded flooding, duplicate suppression (30-message window), adaptive forwarding backoff (50–150 ms), reboot-persistent buffering in non-volatile storage (NVS) — known, published techniques. Construction of routing that accounts for a node’s power class: withheld (patent option kept open — direction flagged as sensitive). Status: implemented; validation under variable node density in progress.

3. Priority safety alert over a best-effort network

Research question. Can a safety alert (panic button) be delivered with low, predictable latency and priority over regular traffic in an inherently lossy network? Why it is hard. The LoRa mesh is non-deterministic; the alert must “overtake” regular traffic without flooding the network. Source authenticity must be secured without PKI, and the mechanism hardened against abuse/replay. Success criterion. Low, predictable alert latency with priority over regular traffic, source authenticity without PKI, abuse and replay resistance. Construction (preemption, trust distribution, emergency path): withheld (patent option kept open). Status: implemented (firmware v2.1.0); latency measurement under load in progress.

4. Hybrid authentication on clockless devices (TOTP↔HOTP)

Research question. How to generate cryptographically sound one-time codes (point-of-sale TAN) on a device with no real-time clock and no permanent connection? Why it is hard. Without network time, the device must fall back to counter-based codes (HOTP); the counter drifts offline, so the server must resynchronise it via a forward window — without opening a replay window. Approach (state of the art). On-device HMAC-SHA1 (RFC 4226/6238), seamless time↔counter switching depending on sync, server-side counter resynchronisation via a forward window — standard constructions, published. (Any non-obvious secret-provisioning elements handled separately.) Status: implemented and tested.

5. Privacy-preserving presence analytics (despite MAC randomisation)

Research question. Can a robust, aggregated footfall metric be derived from radio observations (mesh neighbours, BLE detections, RSSI) — with no personal data and despite MAC randomisation? Why it is hard. MAC randomisation (BLE/WiFi) defeats naive counting of distinct devices; a robust estimator without a stable identifier is needed, validated against a reference count, fully GDPR-compliant. Success criterion. An aggregated footfall metric with no personal data, robust to MAC randomisation and validated against a reference count; explicit GDPR assessment. Construction of the estimator and anonymisation: withheld (patent option kept open). Status: design (today only active-neighbour counting exists; the estimation layer is design).

6. Energy autonomy vs. mesh availability

Research question. How to maximise battery life while keeping the node available as a mesh relay? Why it is hard. More sleep = lower relay availability; the optimal operating point is unknown and load-dependent. Also, battery estimation without a dedicated fuel gauge (ADC only) must be robust to load and temperature. Approach (state of the art). Adaptive duty-cycling, CPU frequency scaling (80 MHz), deep-sleep/smart-standby, an ADC battery model, safe states on charging/shutdown without buffer loss — known, published techniques. Construction coupling energy state to the availability/routing decision (power class as a parameter): withheld (patent option kept open). Status: partially implemented; optimisation in progress.