{"id":19161,"date":"2026-06-24T15:57:59","date_gmt":"2026-06-24T07:57:59","guid":{"rendered":"https:\/\/www.lansitec.com\/?p=19161"},"modified":"2026-06-10T13:04:57","modified_gmt":"2026-06-10T05:04:57","slug":"ble-payload-filtering","status":"publish","type":"post","link":"https:\/\/www.lansitec.com\/es\/blogs\/ble-payload-filtering\/","title":{"rendered":"Filtrado de carga \u00fatil BLE: una forma comprobada de reducir el tiempo de transmisi\u00f3n LoRaWAN y mejorar la eficiencia del seguimiento."},"content":{"rendered":"\n

What is BLE payload filtering?<\/strong><\/p>\n\n\n\n

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

Why is payload filtering important in LoRaWAN<\/a>?<\/strong><\/p>\n\n\n\n

Payload filtering reduces LoRaWAN<\/a> airtime, improves gateway battery life, lowers network congestion, and helps tracking systems send meaningful events instead of repeated raw Bluetooth packets.<\/p>\n\n\n\n

Why Sending Every BLE Packet Creates LoRaWAN Network Problems<\/h2>\n\n\n\n

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 sensors<\/a>, 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

In Lansitec\u2019s B-Mobile<\/a> architecture, Bluetooth beacons<\/a> are worn by people or attached to assets, while Bluetooth gateways<\/a> sit at fixed locations and forward received information through LoRaWAN<\/a> to the server. The server then calculates the location using gateway coordinates and RSSI<\/a>.<\/p>\n\n\n\n

However, in an actual complex deployment, the picture changes and quickly becomes crowded. A hospital corridor may have wheelchairs, infusion pumps, staff badges, temperature sensors<\/a>, 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.<\/p>\n\n\n\n

If the system forwards every byte from every BLE advertisement, LoRaWAN<\/a> becomes the bottleneck. Not because LoRaWAN<\/a> 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.<\/p>\n\n\n\n

BLE vs LoRaWAN: Why Payload Optimization Matters<\/h2>\n\n\n\n

Legacy BLE advertising gives the application a compact payload area. Silicon Labs\u2019 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. (1)<\/a><\/sup><\/p>\n\n\n\n

Thirty-one bytes does not sound like much. But multiply it.<\/p>\n\n\n\n

A gateway may hear dozens or hundreds of advertisements per second in a dense site. The Lansitec Compact Bluetooth Gateway<\/a>, for example, can receive 100 beacon messages within 1 second, whereas a single LoRaWAN<\/a> 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<\/a>.<\/p>\n\n\n\n

The gateway should not ask, \u201cWhat did I hear?\u201d It should ask, \u201cWhat changed, what matters, and what does the server need to act?\u201d<\/p>\n\n\n\n

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<\/a> 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<\/a>.<\/p>\n\n\n\n

What Is BLE Payload Filtering?<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

A Lansitec Bluetooth gateway<\/a> can inspect the BLE payload, select the useful bytes, and forward only the parts needed by the application. In practice, that can mean:<\/p>\n\n\n\n