What is BLE payload filtering?

BLE payload filtering is the process of selecting only the useful data from Bluetooth advertisements before sending it over LoRaWAN, reducing airtime usage, battery consumption, and unnecessary network traffic.

Why is payload filtering important in LoRaWAN?

Payload filtering reduces LoRaWAN airtime, improves gateway battery life, lowers network congestion, and helps tracking systems send meaningful events instead of repeated raw Bluetooth packets.

Why Sending Every BLE Packet Creates LoRaWAN Network Problems

A Bluetooth beacon is chatty by design. It advertises. Then advertises again and again. That is exactly why BLE works so well for tracking badges, asset tags, key fobs, bracelets, environmental sensores, panic buttons, and motion devices. A nearby scanner does not need to connect. It simply listens, catches the advertising packet, and decides what to do with it.

That last part matters. In a BLE-to-LoRaWAN tracking system, the gateway is not just a pipe. It is a translator, a sorter, and sometimes the difference between a clean tracking deployment and a noisy one that burns airtime for no useful reason.

En Lansitec B-Móvil architecture, Balizas Bluetooth are worn by people or attached to assets, while Pasarelas Bluetooth sit at fixed locations and forward received information through LoRaWAN to the server. The server then calculates the location using gateway coordinates and RSSI.

However, in an actual complex deployment, the picture changes and quickly becomes crowded. A hospital corridor may have wheelchairs, infusion pumps, staff badges, temperature sensores, and emergency buttons all advertising nearby. A dealership may have keys, vehicles, repair bays, and gateway coverage overlap. A warehouse might have tags passing through weak signal zones, with nearby-room bleed adding more packets than the application really needs.

If the system forwards every byte from every BLE advertisement, LoRaWAN becomes the bottleneck. Not because LoRaWAN is weak. It is not. It is excellent at long-range, low-power telemetry. But it is built for small, useful messages, not raw Bluetooth packet dumping.

BLE vs LoRaWAN: Why Payload Optimization Matters

Legacy BLE advertising gives the application a compact payload area. Silicon Labs’ Bluetooth documentation describes the primary-channel advertising payload as 0 to 31 bytes, structured into advertising data elements such as flags, service UUIDs, local names, and custom manufacturer data. ⁽¹⁾

Thirty-one bytes does not sound like much. But multiply it.

A gateway may hear dozens or hundreds of advertisements per second in a dense site. The Lansitec Puerta de enlace Bluetooth compacta, for example, can receive 100 beacon messages within 1 second, whereas a single LoRaWAN package can send up to 15 beacon messages. It also supports configurable Bluetooth data filtering and payload reporting, including filtering specific data bytes from a BLE payload before reporting through LoRaWAN.

The gateway should not ask, “What did I hear?” It should ask, “What changed, what matters, and what does the server need to act?”

In most tracking use cases, the answer is much smaller than the raw BLE payload. BLE devices can advertise data such as temperature, humidity, or heart rate in iBeacon or Eddystone payloads, but LoRaWAN supports a limited number of bytes per uplink and downlink. The recommended approach is to configure the gateway to send useful information only, typically ID, parameters plus RSSI.

What Is BLE Payload Filtering?

Payload filtering is not the same as reducing the report interval. Reducing the interval means sending less often, while Filtering means sending better data, only the things you need.

A Lansitec Puerta de enlace Bluetooth can inspect the BLE payload, select the useful bytes, and forward only the parts needed by the application. In practice, that can mean:

• Beacon identity: UUID, major/minor, MAC-derived ID, or a configured asset ID
• Context: RSSI, gateway ID, timestamp, zone, or entry/exit state
• Sensor value: temperature, humidity, step count, heart rate, motion flag, panic button state, lock/unlock state
• Event logic: report only when a beacon enters, leaves, changes state, or crosses a threshold

For a key-tracking use case, the application may only need key ID + gateway ID + RSSI. 

For a cold-chain cabinet, it may need sensor ID + temperature + alarm flag. 

For a lone worker badge, it may need badge ID + panic status + RSSI + last-seen gateway.

Everything else is expensive decoration. We’ve seen this mistake in planning discussions: teams obsess over gateway range, then ignore payload design. But range gets you packets. Filtering turns those packets into usable events.

How BLE Payload Filtering Reduces LoRaWAN Airtime Usage

LoRaWAN offers long-range, low-power operation, but payload size and airtime still matter.

For EU863-870, the maximum application payload varies by data rate: 51 bytes at DR0 to DR2, 115 bytes at DR3, and 222 bytes at DR4 to DR7 when FOpts is absent. The same page notes that higher spreading factors produce lower bit rates, while lower spreading factors produce higher bit rates. ⁽²⁾

In Europe, duty-cycle rules also shape how often devices can transmit. There are ETSI sub-band limits such as 1% for 865-868 MHz and 868-868.6 MHz, 0.1% for some neighboring sub-bands, and 10% for 869.4-869.65 MHz. It is also to be noted that public network policies may add tighter limits, such as TTN Sandbox’s 30 seconds of uplink airtime per node per day. ⁽²⁾

That does not mean every private Lansitec deployment is limited by TTN’s sandbox policy. It does mean buyers should stop treating LoRaWAN uplinks as free because there is no SIM. There is no SIM, great. There is still airtime, gateway capacity, and battery to be considered in the equation.

Hospital Asset Tracking Example Using BLE Payload Filtering

Imagine a hospital wing with BLE tags on wheelchairs, infusion pumps, portable monitors, operating tables, CT accessories, staff badges, temperature sensores, and emergency call bracelets.

A gateway hears a beacon packet. Raw forwarding would pass along everything it hears. That might include fields the hospital dashboard never uses, repeated packets from devices that have not moved, and weak advertisements leaking from the next room.

A filtered event looks different:

asset_id + gateway_id + RSSI + movement_flag + battery_flag

Or, for a sensor:

sensor_id + temperature + alarm_status + RSSI

The dashboard does not need the full BLE advertisement every time. It needs to know that pump 1842 is near Ward B corridor, that freezer sensor 12 crossed a temperature threshold, or that a panic button was pressed.

Lansitec’s Solar, Macro, Micro, Compact, Indoor, and SocketSync Pasarelas Bluetooth all include configurable Bluetooth data filtering and payload reporting in the product catalog, with the recurring function described as filtering data bytes in a Bluetooth payload and reporting selected data via LoRaWAN. This is not a side feature. It is part of how BLE-to-LoRaWAN systems stay usable at scale.

How Payload Filtering Extends Gateway Battery Life

A gateway that sends fewer, smaller, better messages spends less time transmitting. That matters most on battery-powered puertas de enlace. The Lansitec Macro Puerta de enlace Bluetooth, for example, uses a 38,000 mAh Li-SoCl2 battery pack and is designed for long-term deployments where power may not be available. It features Bluetooth payload filtering, adjustable position-report intervals, heartbeat intervals, Bluetooth data compression, TDMA support, and a maximum of 15 beacon messages in a single LoRaWAN packet at SF9.

Those features work together. Filtering reduces the payload. Compression tightens what remains. TDMA and report synchronization help multiple puertas de enlace behave more predictably. Adjustable intervals let the installer decide whether the site needs near-real-time visibility or simply reliable state changes.

A busy gateway in a warehouse aisle should not report the same static pallet tag every few seconds just because it can hear it. A better pattern is to report entry, exit, last seen, and meaningful state changes.

Why More Tracking Data Does Not Always Improve Visibility

A buyer may ask, “Can we get updates every five seconds?” Sometimes yes. Pasarelas Lansitec support configurable report intervals, and several LoRaWAN models list 5s x n as the adjustable position report interval. But the better question is scenario-specific:

• Do you need a five-second location stream, or do you need to know when a tagged asset enters a restricted room?
• Do you need every bracelet advertisement, or only panic button, overstay, and zone-crossing events?
• Do you need continuous raw temperature values, or only normal heartbeat plus threshold exceptions?

This is where payload filtering becomes a product design conversation, rather than a firmware detail.

For a visitor badge, a five-second update might be unnecessary. For a forklift proximity alarm, the timing of the event matters. For a freezer sensor, threshold crossing matters more than location granularity. For car keys at a dealership, room-level presence may be enough until someone searches for a specific key, triggering a buzzer. Send the event and keep the noise local.

How BLE Payload Filtering Works in Lansitec B-Mobile Tracking

In B-Mobile, the Puerta de enlace Bluetooth is fixed, and the beacon moves. The gateway receives nearby BLE messages, restructures the data, and forwards it over LoRaWAN. Lansitec’s LoRa solution has balizas advertising UUID, major, minor, temperature, or other data, while the Puerta de enlace Bluetooth receives and restructures that data before forwarding it to the LoRaWAN gateway and application.

In this context, “restructure” means that the system can convert many raw BLE advertisements into application-ready tracking data. In practical deployments, the backend usually wants:

• Who or what was detected
• Which gateway heard it
• How strong the signal was
• Whether the state changed
• Which sensor value or alarm flag matters

B-Mobile also highlights that puertas de enlace may receive beacon signals from nearby rooms, often with much weaker RSSI, and that RSSI can vary because of 2.4 GHz interference and multipath effects. Filtering cannot magically fix RF physics, but it can stop weak, irrelevant, repeated packets from flooding the application layer.

Best Practices for BLE Payload Filtering

A good BLE-to-LoRaWAN payload plan is usually boring. That is a compliment. Start with a small event dictionary. Define what the application actually uses, then map each event to bytes. Keep the server decoder simple, versioned, and documented. In mixed deployments, clearly separate asset IDs, personnel IDs, sensor IDs, and infrastructure balizas.

Here are three practical patterns we like:

Common BLE Payload Filtering Mistakes to Avoid

There is one warning: filtering should not destroy diagnostic value.

During commissioning, you may want richer payloads: raw RSSI, multiple gateway observations, battery, firmware version, and perhaps a reason code for why an event was sent. Once the site stabilizes, you can tighten the payload.

A good rollout often has two profiles:

• Commissioning mode: more data, shorter diagnostic windows, easier troubleshooting.
• Operations mode: filtered events, lean payloads, longer battery life, fewer uplinks.

We’ve seen this pay off in projects where the first week is spent tuning RSSI thresholds, room boundaries, and gateway placement. After that, the system can quiet down and report what operations actually need.

How to Build a Scalable BLE-to-LoRaWAN Tracking System

BLE-to-LoRaWAN tracking works best when the gateway does more than listen. It should decide.

Lansitec’s payload filtering and reporting function is one of those practical details that does not always make it into the first buyer conversation. It should. Because once the site has hundreds of tags, mixed sensor types, gateway overlap, LoRaWAN payload limits, and battery-powered infrastructure, raw forwarding becomes wasteful fast.

Send the ID. Send the parameter. Send the RSSI. Send the alarm. Leave the noise behind.

Referencias y lecturas adicionales

1. Silicon Labs: Bluetooth advertising data basics
2. The Things Network: EU863-870 maximum payload and duty-cycle guidance