A lone Bluetooth Beacon is just a radio shouting packets into the air. The actual value — location, presence, telemetry — is created by the gateway and edge layer that listens, filters, and forwards those packets. This article covers how a Beacon-to-gateway pipeline is architected, where to put compute, and how to keep bandwidth and latency sane at scale.

What the gateway actually does

A gateway is a BLE scanner with an uplink. For every advertising packet it hears it must:

1. Deduplicate (same MAC + sequence can arrive on 3 overlapping gateways).

2. Timestamp with a synchronized clock (NTP/PTP) so trilateration is consistent.

3. Normalize RSSI (each radio has a different front-end gain).

4. Aggregate per-tag over a window (e.g. 1 s) into one record.

5. Forward over the uplink.

Edge vs cloud

Doing all of this in the cloud means shipping every raw packet. With 500 tags at a 1 s interval you generate ~500 packets/s. Pushing all of that cross-site is wasteful. The edge gateway should emit *one aggregated record per tag per second*, cutting volume by the number of gateways hearing each tag.

Data flow

<strong><a href="https://www.tecksay.com/category/products/bluetooth-beacon/">Beacon</a></strong> ADV ──▶ Gateway (BLE scanner)
├─ dedupe + timestamp
├─ RSSI smoothing (Kalman / moving avg)
└─ aggregate 1 Hz record
│
▼
MQTT broker  (topic: site/floor/tag/uid)
│
▼
Cloud ingestion ──▶ dashboard / alerting

Edge filtering math

Dedupe key = (mac, seq). Keep a sliding set; drop repeats within T_dedup (say 5 s). RSSI smoothing per tag:

rssi_smoothed = α·rssi_new + (1-α)·rssi_prev     (α ≈ 0.3)

This removes single-packet spikes that would otherwise fake a position jump.

Uplink protocol

MQTT is the natural fit: gateways publish to tecksay///beacon/, the cloud subscribes once. HTTP POST is simpler to debug but needs a kept-alive connection. CoAP suits very constrained gateways.

Bandwidth math

Say 500 tags, 1 Hz, gateway hears each on avg 2.5 radios, payload 120 B after aggregation:

  • Raw to cloud: 500 × 120 B × 2.5 = 150 KB/s (wasteful, duplicated).
  • Aggregated at edge: 500 × 120 B = 60 KB/s, single copy.

That 2.5× saving grows with gateway density.

Latency budget

Event at tag → gateway hears within one advertise interval (≤1 s) → edge aggregate 1 s → MQTT hop ~50 ms → dashboard. End-to-end typically 2–3 s, dominated by the advertise interval, not the network.

Buffering when cloud is down

Gateways must not drop data. Keep a local ring buffer (e.g. last 1 h). On reconnect, replay with exponential backoff. Mark replayed records so the cloud can dedupe by (gateway, seq).

Security

  • TLS for the uplink; don’t ship plaintext RSSI off-site.
  • Per-gateway auth token (not shared secret).
  • Sign each record `sig = HMAC(k, payload)` so a spoofed gateway can’t inject fake positions.
  • Rotate gateway keys on a schedule.

Deployment topology

Overlap gateways by ~20–30% so a tag is always heard by ≥2 radios (needed for trilateration). More overlap = better accuracy but more dedupe load. Handoff between gateways is implicit: the cloud just fuses the latest records from whichever radios heard the tag.

Checklist

  • [ ] Gateway clock synced (NTP, ±50 ms)
  • [ ] Dedupe key = mac+seq, T_dedup set
  • [ ] RSSI smoothed at edge
  • [ ] Aggregated 1 Hz record, not raw packets
  • [ ] MQTT with per-site topic hierarchy
  • [ ] Local ring buffer + replay on outage
  • [ ] TLS + per-gateway signed records
  • [ ] 20–30% gateway overlap