Internet of Things (IoT) and Industrial IoT (IIoT)

Hello. We have written a websocket application to receive and parse BLE messages from BLE forwarding in AOS 8.10.

At the controller, we are filtering BLE devices to iBeacon only, with Per frame filtering. We also filter on specific UUID's that our application cares about. We are testing using beacons with public, static and private addresses.  Our application doesn't care about the address type and needs to work with all types.

My question has to do with the "data" part of the bleData, highlighted in the sample message below (pardon the lack of json formatting):

"bleData": [ { "mac": "a0e6f82c09c9", "frameType": "adv_ind", "data": "0201061aff4c0002154152554ef99b4a3b86d0947070693a7800000000b5", "rssi": -58, "addrType": "addr_type_public", "apbMac": "204c0339e22c" } ]

That BLE data should normally be 30 bytes. In some cases, we are getting 27 bytes. When we get 27 bytes, the first three bytes - the iBeacon prefix/flags (0x020106) is missing. The rest of the data is present and correct. This *seems* to be happening only with private address beacons. I says seems because I am not sure that's all there is to it.

We are testing with 4 types of beacons. Here are properties of each type:

• Type 1 - physical beacon: frameType: adv_ind ; addrType: addr_type_static
• Type 2 - physical beacon: frameType: adv_nonconn_ind ; addrType: addr_type_public
• Type 3 - android app: frameType: adv_scan_ind ; addrType: addr_type_private_resolvable
• Type 4 - windows app: frameType: adv_nonconn_ind ; addrType: addr_type_private_non_resolvable

For Types 1 and 2, we are getting all 30 bytes in "data". For Types 3 and 4, we are not getting the iBeacon prefix. We are getting only the remaining 27 bytes in "data".
All 4 beacon types are properly scanned/detected by beacon scanning apps such as nrfConnect and others.

My question therefore is why is the iBeacon prefix missing from the data of BLE forwarding messages, in some cases?

Thanks.

Hi Kan - I received the following information from our technical team.  I hope this answers your question:

The first 3 bytes are the Bluetooth flags element. They are very common in Bluetooth advertisements, but they do not actually contribute to iBeacon functionality.

As it turns out, some devices include the flags element and others don't. Not clear why. If you read apple's iBeacon spec, it does mention the flags element, so sending an iBeacon frame without the flags element technically does not meet the iBeacon standard. However, in practice this flags element is not needed.

I would suggest that you enhance your server code to check for the presence of the flags element and just strip them off. I assume your server has no use for the flags element anyway.

Tim

Thanks for the response and confirmation from your technical team Tim. We have already handled this condition. I just was curious if Aruba was for some reason stripping those flags in certain cases, but it appears you're just forwarding the BLE data as received from the devices.

Sure, I'd be happy to ask you a question about the issue you mentioned regarding the missing first 3 bytes (the prefix/flags) of iBeacon data in some cases. Here's my question:

Can you provide more details about the specific scenarios or conditions in which the first 3 bytes of iBeacon data are missing? Are there any patterns or common factors among the cases where this issue occurs?  YourTexasBenefits Application