It’s not every week that you see two companies in your competitive landscape acquired, in addition to the first major evolution of the standard on which your core technology is based! Amidst everything else that’s happened in 2016, perhaps we’re the only ones to remark this remarkaBLE coincidence, but it’s certainly not without significance!

In 2012, when we started reelyActive, our expected exit was an enterprise acquisition: build a better real-time location system (RTLS), raise the right eyebrows, combine agile innovation with access to the right resources. It would appear that Bluvision have done just that, which is commendable given the track record of outcomes for RTLS companies (our co-founders cut their teeth at one which inevitably failed!)

Over the past few months, we’ve shifted our immediate focus to the out-of-home (OOH) market which has a pressing need to reach and engage individuals in the real-world, in real-time, and in context (all the while measuring the results). It would appear that Gimbal and The Mobile Majority have come together to do just that for mobile advertising.

What makes this week’s coincidence so striking to us?

Where Gimbal and The Mobile Majority are headed, we’re taking our novel Bluetooth RTLS technology, like that of Bluvision.

When Bluvision CEO Jimmy Buchheim showed us his BluFi prototype in 2014, we knew we weren’t alone in developing “bring-your-own-device” (BYOD) RTLS technology allowing any Bluetooth Low Energy device, including the ones we carry and wear, to be identified and tracked throughout a space. This is the inverse (literally!) of what Gimbal and almost every other mobile-focused company is doing today with beacons.

With 4x range, 2x speed and 8x broadcasting message capacity, the enhancements of Bluetooth 5 focus on increasing the functionality of Bluetooth for the IoT.

While the Bluetooth SIG are advertising (pun intended) the above features as key to the future of IoT, what’s key to us is that Bluetooth 5 hasn’t upset the existing wireless advertising functionality (which, for us, makes it the undisputed global standard for Active RFID). This means that the growing billions of people, products and places with Bluetooth radios will retain the possibility of being discoverable on a human scale, advertising what they want, when they want and with whom they want.

Our mission is to unlock the value of the data [they] choose to share.

And the week’s events have emboldened us on that mission, affirming the value of BYOD RTLS and of reaching audiences in the real-world, while protecting and extending the wireless standard which makes our vision a reality.

On each of Notman’s three floors, there are three of our Bluetooth Low Energy (BLE) sensors (which we call reelceivers), plus an addition sensor in the adjacent OSMO Cafe.

Think of each floor as a musical note in a scale (C – E – G – C), and each wing of that floor as a pan in stereo (Left – Centre – Right).

When BLE devices “appear” and “disappear” they produce a note which encodes the location by the tonality and pan. Same thing when BLE devices “displace” from one zone to another, only these use a ping-pong delay rather than a pan.

For the hackathon, we ordered three packs of Estimote Nearables which are BLE devices that periodically transmit their temperature and 3-axis acceleration. Unfortunately, these were held up in customs and didn’t make it in time. But the web app essentially turns these into “hearable nearables” and, as you’ll pick out in the video, we could tell not only when they had arrived, but also where in the house they were:

Yes, they’re on the second floor east (right) wing. Why so noisy? As we discussed in our ObservaBLE Etiquette blog post, the Estimote Nearables cycle their identifier with every transmission. To an observer, that would be interpreted as a new device “appearing” each time. Hence plenty of appearance and disappearance notes in the web application.

To reinforce this point, have a look at the Google Analytics (GA) timeline for Notman House. Our platform pushes all the events from the house to GA (see our Google Analytics for the Physical World blog post), where each is interpreted as a session based on its identifier. The Nearables’ aggressive identifier-cycling results significantly biases the number of sessions, and hence we can tell from the edge of the high plateau when they arrived: shortly after 16h on November 15th.

We created the Notman Tonal Presence application as an example of calm technology for smart buildings. The ambient sounds allow the listener to subconsciously register foot traffic within the building while leaving their attention free for other tasks. Even the casual listener would have been gently alerted to the arrival of the Nearables, which is precisely the objective of calm technology. And, now, duly alerted, we can direct our attention towards filtering out the Nearables from GA so that their incessant identifier-cycling doesn’t saturate the session counts!

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!

This week we attended the Wavefront IoT Roadshow where much of this year’s hype was around LPWAN technologies which allow simple, inexpensive radio devices to communicate short messages with cellular base stations kilometers away. An excellent example of the potential of this technology is the SMOCKEO smoke detector which automatically and securely communicates status and alerts to the Internet via the SigFox LPWA network — without any network configuration required. Curious about their optimism surrounding ubiquitous LPWAN adoption, we asked the final panel of experts when they’d expect such devices to be able to connect seamlessly anywhere in the world, if ever? Crickets…

Indeed, there are several competing standards for LPWAN including SigFox, LoRa and LTE-M, and the panel shared little optimism that any single one would cover all geographies. So for all the hype around long-range IoT, it is, at least currently, still very much relegated to niche applications of early adopters in select regions. And this makes us scratch our head as to why the complementary concept of Low Power Local Area Networks (LPLAN) doesn’t even come up in a Google search! Allow us to explain.

Today there are billions of Bluetooth Low Energy (BLE) devices across the planet:

like in LPWAN, these can spontaneously transmit short messages to any receivers that might be in range

they use the 2.4GHz unlicensed global ISM band

sure, they’re limited to a range on the order of tens of meters, but

there are billions of nearby Internet-connected candidate BLE “base stations”, any recent mobile phone, laptop or set-top box is an example

In other words, there are, today, several orders of magnitude more devices technically capable of living up to the LPWAN hype, only with significantly reduced range.

Not convinced on the potential of BLE LPLAN? Consider Tile and TrackR which for at least two years now have in effect operated such (albeit siloed) networks which connect any of their devices to the Internet via their mobile app. In other words, an unpaired Tile will periodically send packets that any BLE device in range can receive and decode. It does so in the hope that the Tile app of any user will be in range, and if so, that packet will be forwarded to Tile’s cloud service.

In fact, reelyActive BLE infrastructure routinely picks up Tile transmissions and forwards them to the Internet. Chances are you’ll see a Tile here among plenty of other similar devices. Your SmartTV and mobile phone could act as BLE gateways just the same. Alas, the aforementioned tracking services are typically branded with limited scope as “crowd GPS”, when in fact, they could spearhead a much broader “crowd LPLAN” or “distributed M2M” (Machine-to-Machine communication) initiative.

The question then again is why with all the LPWAN and IoT hype, if a complementary and underexploited option based on BLE exists, should the latter be subject to such deference? We press on regardless, and look forward to forwarding the packets of the first BLE device provider to request them from us!

Posts navigation

The World Wide Web turns 30 years old today, March 12th 2019, and its inventor, Sir Tim Berners-Lee, has asked its citizens to help build a timeline of the web’s history. Given that reelyActive has existed on the Web for about a quarter of its history, we thought it’d be fun to look back at […]

What’s in store (pun intended) for 2019? The Local Search Association kicks off each year with a compilation of its members’ predictions. This is our third consecutive year submitting predictions. While our 2017 prediction proved way too optimistic, our 2018 prediction, and the two we submitted this year, resonate well among those of our peers. […]

Since the advent of the iBeacon five years ago, much effort has been spent on real-time location-based experiences through mobile. If today you were to ask “Should I develop a native mobile app?” to anyone who has invested in such efforts, you may well receive an emphatic NO. In this blog post, we’ll not […]

On the 11th hour of the 11th day of the 11th month, in Canada and in many nations around the world, a minute of silence is observed. Remembrance Day, as we call it here, is special this year as it marks the 100th anniversary of the signing of the armistice of the First World War, […]

This year marks a decade of the smartphone ecosystem as we know it. While the original iPhone debuted in 2007, it was the introduction of the App Store with the iPhone 3G in 2008 that kicked off the era of a rectangle in every pocket. Coincidentally, this month marks half a decade of Bluetooth Low […]