ObservaBLE etiquette

Rules are explicit principles governing conduct. Etiquette is an expected code of conduct within social norms. When we developed and released our first Bluetooth Low Energy (BLE) device in 2013, there were rules, but there was no etiquette.

To understand why, recall that BLE was born as Wibree, introduced by Nokia in 2006, and only merged into the Bluetooth standard in 2010. That merger paved the way for the first global standard for Active RFID, as BLE allows devices to spontaneously “advertise” themselves to any and all observers (readers) in range. While the BLE rules may be a decade old, commercial deployments are far too recent to expect established etiquette, even today.

Before BLE, there were only proprietary Active RFID systems, of which the reelyActive cofounders themselves have developed two. Proprietary systems afford the designers control over both the rules and etiquette conducive to the intended application of the technology. BLE, on the other hand, established the rules for a global standard, encouraging widespread adoption, while leaving the etiquette necessarily free to (hopefully) emerge from the real-world interactions of the billion-plus devices now shipping annually from countless vendors.

Over the past three years, while we have indeed observed an emergence of etiquette, it tends to remain fragmented and lack cohesion. Moreover, we continue to be surprised by the incidence of minor rule violations. Our intent here is to formally acknowledge these shortcomings, suggest improvements and encourage all concerned parties to collaborate to ensure that the enormous potential of BLE’s unique “advertising” capability can be fully realised.

Manufacturer Specific Data: breaking the rules

A powerful feature of BLE is the ability to “advertise” a few bytes of whatever you want, whenever you want, as Manufacturer Specific Data. Simply include your 16-bit company code (list here) and send whatever data you like (sensor readings, identifiers, missile launch codes, …). Curiously, that simple rule gets broken, likely inadvertently, far more often than one might expect.

That can’t be what your Samsung wearable is advertising, the company code is invalid! Oh wait, it’s just backwards…

Yes, even Samsung can get the endianness wrong, sending 0x7800 instead of 0x0078.

Will you register with the SIG and use a companyIdentifierCode other than Ericsson’s 0x0000 in future?

That’s a line from our e-mail to Chris from TrackR after we observed that their devices were using company code ‘0’ which is assigned to Ericsson Technology Licensing. As of writing, TrackR still don’t appear to have claimed their own company code.

The most common error we’ve seen is for devices to ignore the 16-bits reserved for the company code and employ the entire space for their own data. While this and the errors presented above aren’t showstoppers per se, they nonetheless hamper device discovery due to mistaken or unknown identity. What’s going on?

It’s easy to follow the rules when they’re well documented. In the case of BLE, we feel there’s much room for improvement. In fact, we took it upon ourselves to create a software library called advlib, with explicit documentation and an online tool for interpreting advertising packets, and even presented our work as a scientific article. While we trust that these will be helpful to the community, our expectation, however, would be for the Bluetooth SIG to ensure an ample supply of developer-friendly documentation and accessible tools.

“Return of the MAC”: emerging etiquette

Another powerful feature of BLE is the option to “advertise” a random, rather than static, 48-bit identifier. A device therefore has the option to identify itself three ways, using a:

• static, IEEE-assigned identifier
• static, randomly-generated identifier
• periodically-changing, randomly-generated identifier

If we imagine the use case of a retail store “observing” the occupants via their “advertising” BLE devices, these three options offer the following possibilities, respectively:

• device can be recognised on subsequent visits, chipset manufacturer can be looked up
• device can be recognised on subsequent visits
• device cannot be recognised on subsequent visits

Indeed, the retail use case is the one for which we receive the most inquiries. Given privacy concerns, one might expect an emergent etiquette around how the devices we’re likely to carry or wear into a store identify themselves. Consistent behaviour across devices would expedite adoption in retail, however, our answer to such inquiries about identification continues to be “it’s complicated”, and here’s why.

Apple’s iOS devices, which were among the first to embrace BLE technology, can be commended for electing to change their identifier every 15 minutes or so. This ensures privacy by preventing someone from being recognised as a repeat visitor to a store, yet allows their in-store journey to be anonymously tracked for the duration of that period. For us, that strikes a healthy balance of benefits for both the client and the retailer.

Android devices originally embraced BLE technology haphazardly, tending at first to static identifiers. However, from Android 5 onwards, like in iOS, periodically-changing identifiers are employed. At the Place Conference, we asked Chandu Thota, Director of Engineering at Google, what one thing he’d like to see improve faster. His answer was the convergence of behaviour among the diverse BLE hardware and firmware in the mobile devices running Android. Indeed, without that challenge first resolved for Android, it’s unreasonable to expect any refinement of etiquette!

And then there’s Fitbit.

I bought my Fitbit Charge HR in March 2015, and 18 months later, it’s still advertising the same identifier every second-and-a-half or so.

Clearly a different approach to identification and privacy than the mobile platforms… We tweeted Fitbit about this, but the behaviour remains the same with subsequent firmware updates. Care to know where the Fitbit-wearing author of this article is right now? Simply ask our open API whereis d9:01:4f:6b:a8:b2 or what is the contextnear d9:01:4f:6b:a8:b2? We’ve seen the same from other wearables vendors such as Xiaomi, but given Fitbit’s technical know-how and dominant market share, highlighted by the number of their devices our platform detects, it’s curious that they haven’t yet moved to protect privacy by occasionally cycling their identifiers!

Finally, on the other extreme, there are devices which go so far as to change their identifier on each subsequent transmission. We’ve observed both Qualcomm’s FYX beacon and Estimote’s Nearables exhibiting this behaviour. Curiously, the latter includes a static 64-bit identifier as Manufacturer Specific Data, thereby completely voiding any potential motivation for privacy or security! The result of this behaviour is that an “observer” sees the individual device as multiple devices, appearing and disappearing in sequence. Depending on how the vendor’s BLE stack handles this case, this would likely lead to inefficient use of memory and computing resources, possibly overwhelming or even crashing the stack! Perhaps not the best etiquette!

From the examples given, it is clear that there is an emergence of identification etiquette, at least for individual vendors across their various devices. However, the fragmented approaches across vendors result in a lack of cohesion, which remains to be overcome to establish an expected code of conduct within social norms.

Realising the enormous potential of BLE’s “advertising” capability

We cannot understate our belief in the enormous potential of BLE’s “advertising” capability, just as we argued at Bluetooth World in 2014. Should it not have been obvious before, yes our platform is “observing” everyone’s devices, yes we’re checking the rules (our platform cares), and yes we’re keen to benefit from the emergence of coherent etiquette across devices and vendors. Etiquette being an expected code of conduct within social norms, social interaction among us vendors and developers is paramount! Therefore, as a community of members of the Bluetooth SIG, perhaps if we improve our efforts to look out for one another (quite literally) and openly share our thoughts and concerns, as we’ve done here, we’ll expedite the emergence of a collective etiquette which is key to the widespread adoption of the first global standard for Active RFID!