“Advertise” yourself with The Physical Web, and beyond…

Would you wear a t-shirt that advertises a webpage?

Attend any tech conference and you’d be hard pressed not to spot one. In fact, most of us advertise company brands every day by much more than just the clothes we wear.

Now, would you wear a t-shirt that advertises YOUR webpage?

Why not? You are your own brand. Perhaps a t-shirt isn’t your preferred communication channel? How about a mobile app?

There you have it: within 30 seconds, you can be advertising your personal brand as a webpage via an Android application. And, more importantly, there’s a non-negligible chance that someone Nearby will take notice!

For those interested in the technology (or the nerdy featured image), it’s all standard: Android can advertise URLs in Eddystone packets over Bluetooth Low Energy. And our open source json-silo accepts the profile of any Person, Product or Place as schema.org and JSON-LD, and returns an Eddystone-friendly URL. When queried, the json-silo returns the profile name as the title, and the profile description in the meta, both of which are used by The Physical Web to present contextual notifications on mobile.

Contextual Notification on Nearby

In our previous blog post, we predicted:

this will be the year that a major social network empowers their users to “advertise” themselves in exchange for personalised everyday experiences

It’s technically possible. And the moment businesses start listening and responding to such ads, the incentives for both parties become undeniable. We’ve been preparing for that moment for a long time.

We are advertising!  The devices we carry and wear are already anonymously advertising our presence, and personalisation is inevitable. Here’s the question:  Are you listening?

OOH! A social media prediction for 2017

In 2016, we postulated that the Internet of Things may very well prove to be a personal brand ambassador for each and every one of us, given that the devices we carry and wear make it possible to “advertise” our digital selves to the physical places we visit. When the Local Search Association asked us and 50 experts about the future of location-based marketing and media we replied:

our prediction for 2017 is that the first major social network will empower their users to experiment with this feature

Technology is no longer the blocker, as you can “advertise” yourself with reelyApp using established standards as we described in detail months ago.

And we can already push the concept quite far in everyday life. We proved, with our partners, measurable ROI in retail with a live deployment that even triggers contextually-relevant videos on displays to shoppers:

Now extend that capability across a city. In anticipation of programmatic advertising, out-of-home (OOH) media companies are scrambling to adopt technologies that can measure real-world audiences in real-time. Such technologies will enable citywide marketplaces for the data you choose to share, as we presented at a recent Ericsson Smart Cities event:

All the emerging marketplace is missing is a critical mass of individuals with the incentive to “advertise” their digital selves. And a major social network is the ideal candidate to bring exactly that to the table.

We’re working to kindle that marketplace, engaging both sides of the table, and recently adding key enabling features to our Pareto platform, including programmatic content triggers. We even memed the personalised advertising scene from The Minority Report (2002) to serve as the default video content.

15 years ago, would you have predicted that we would today choose to carry and wear personal identification devices?

Are we right to predict that a major social network will empower such users to share what they want when they want in exchange for personalised everyday experiences? Let’s see what 2017 has in store, pun intended!

A remarkaBLE week in Bluetooth

The headlines:

  • 01 12 16 — HID Global Acquires Bluvision to Expand With Bluetooth Solutions for the Enterprise Internet of Things Market (press release)
  • 05 12 16 — Gimbal is Joining The Mobile Majority (press release)
  • 07 12 16 — Bluetooth 5 Now Available (press release)

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.

But what about the future? To us, advertising is backwards, as much for brands as for Bluetooth packets! Which brings us to Bluetooth 5.

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.

Hearable Nearables

Imagine you could “hear” Bluetooth devices moving through a building. In anticipation of last weekend’s #HackTheHouse hackathon for smart buildings, hosted at Notman House where we’ve had our technology deployed since 2012, we created the Notman Tonal Presence web application to do just that.

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!

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.

TrackR as Ericsson

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!

FYX and Nearables cycling 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!

LPLAN as amenaBLE to M2M as LPWAN

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.

LoRa and SigFox versus Bluetooth Low Energy

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.

Three years ago we published a scientific article entitled Towards a simple, versatile, distributed low-power wireless M2M infrastructure which unveiled our vision of this concept. We’ve tweeted Tile about this. Ditto for FitBit and Flic. We shared our vision with the Bluetooth SIG’s committee on IoT. We created an open library for low-power wireless advertising packets and then published our work in another scientific article entitled Low-Power Wireless Advertising Software Library for Distributed M2M and Contextual IoT. One would be hard pressed to argue that we’ve kept this to ourselves!

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!