Gateway GW16-2 BLE Scanner description

The main GW16-2 Gateways' feature is the detection of Bluetooth Low Energy (BLE) devices and reporting this information to Kontakt.io Cloud. In order to make the collected data more meaningful and easier to process when using Location Engine, Gateways do not send all, raw BLE packets, but instead, do some preprocessing to make the amount of data more manageable.

Acceptable BLE packets
Gateways GW16-2 scan only for certain types of BLE packets:

• ADV_IND - Connectable undirected advertising
• ADV_NONCONN_IND - Non-connectable undirected advertising
• ADV_SCAN_IND - Scannable undirected advertising
• SCAN_RSP - Scan response

Scan Window
Gateways GW16-2 collect BLE Broadcast Events in regular time windows called Scan Windows. The BLE Broadcast Event is an arrival of a BLE packet of one of the supported types. Each Scan Window lasts 1 second (currently this value is not configurable) and Gateways monitor all BLE advertising channels at that time.

Scan Window processing
Once a Gateway GW16-2 has data from a Scan Window it starts processing it:

1. Update Scan Response Cache
2. Fill missing scan responses in current Scan Window from Scan Response Cache
3. Filter RSSIs of detected packets
4. Create Observations
5. Update Kontakt.io Cloud

Scan response caching
Scan response (SCAN_RSP) is a special packet that is received during an active scanning (Gateways GW16-2 use active scanning). It is transmitted when a BLE Observer (Gateway) requests this packet in a small time window after receiving an ADV_IND or an ADV_SCAN_IND. Due to the nature of Bluetooth scanners these packets are not always received with corresponding ADV_IND/ADV_SCAN_IND packets.

To minimize random gaps in receiving scan responses, they are cached for 120 seconds. When an ADV_IND or an ADV_SCAN_IND is received without a SCAN_RSP and a Gateway already got a SCAN_RSP from this particular sender, further processing is performed as if both an advertising packet and a SCAN_RSP were received in the current Scan Window.

Filtering
Filtering is performed in 5 second windows. Scanned packets are grouped by a sender’s Bluetooth Address. In each Scan Window for each sender a median RSSI is calculated. This calculated RSSI value is used for all packets originated from that sender in the current Scan Window for further processing.

Note: Historical data needed for filtering is not altered by the filter itself. In every cycle, filtered value is calculated from real RSSI of the received packets.

Creating Observations
Bluetooth devices usually transmit more than one packet of a given type during a Scanning Window. These packets are grouped together into Observations. An Observation is uniquely identifiable by a tuple consisting of a packet type, payload bytes and a sender’s Bluetooth Address. Each Observation has properties that can change: Timestamp and RSSI.

Updating Kontakt.io Cloud
Kontakt.io Cloud is updated when a new Observation is created or when an Observation’s RSSI is changed considerably (at least 7dBm) compared to last registered observation. When an Observation is not changing (ie. RSSI is on the same level) it is also sent to API every 10 seconds (Ping Period).