On The New Edge Network and The Future of Local Commerce
In networking there’s a saying called the last mile problem. It goes as follows: the last mile—or ‘edge’—of the network is the hardest to reach. In mobile, distributing intelligence to the edge has posed an even greater challenge. Why? Because mobile users are always roaming, their location constantly changing in relation to the network. The mobile network supplies plenty of bandwidth, but the network has little idea where you actually are.1.
This fundamental lack of context about mobile users has almost completely blocked intelligence required to attribute online actions with offline behavior. It has basically been impossible to close the data attribution loop. But an elegant technology called iBeacon is about to change this, and it has massive implications for the future of online to offline commerce. Here’s why:
- Intelligence at the network edge is now mobile; there is no longer a true network edge. The best way to compare mobile networks is to think about the way it used to be. In the desktop era, PCs were the edge of the Internet. You sat at your desk and that was it. Today, intelligence at the network edge is no longer fixed to your desk. There is no longer a true edge. Humans are the new ‘edge network’. In fact the network is now alive and breathing, dynamic and changing, just as you are as a person, walking through your city. But the network doesn’t know how people or objects are moving in relation to each other. This has really tilted the intelligence toward the network core.
- Because the network edge is nearly always indeterminate, smartphones are basically blind to their surroundings. People love to declare how intelligent their iPhone or Nexus 5 is. But why does your smartphone have no idea when you arrive at a movie theatre after buying tickets in the Fandango app? Or sit down to eat at your neighborhood restaurant that you just searched for? Yes, smartphones connect to fast networks and access the cloud, but they are missing a context that humans take for granted—’sight’. Do this: close your eyes for a second. Right away you immediately and totally lose context for how far away that wall is in front of you is, and can no longer read that sign helping you navigate. You become blind to your surrounding environment, just as your phone is today.
- Apple’s iBeacon has been talked about a lot, but its essence is much deeper than the marketer’s wet dream of pushing coupons to nearby users. iBeacon is actually the digital equivalent of ‘sight for your smartphone’. Think of it this way: a freeway sign is installed once, has no intelligence and simply advertises a message ‘exit Page Mill Road’, allowing millions of people to follow the right path. You read that freeway sign 100 yards away and know how to navigate and exit. Likewise, your smartphone listens to a beacon on the wall 50 feet away that says “I’m inside the coffee shop you just searched for and arrived at”. So iBeacon really is the digital equivalent of something we all take for granted: analog human sight.
- Because up until this point smartphones have had no idea what is around them, closing the attribution loop in online-to-offline commerce has been impossible. And solving this is a trillion dollar problem. No company has ever had success (monetarily) with online to offline search or discovery, because you can’t go to an app and carry that discovery process to your offline environment. Yes, you can absolutely use a search query to find a place to go, but when you get there no one knows you arrived because of that service. In fact, your phone has no idea you arrived! Your smartphone is actually contextually dumb, blissfully going about its job missing this fifth sense.
- Beacons close this attribution gap by distributing intelligence between the client (smartphone), the beacon, and the cloud to create a new ‘sign’ that your phone can read. A new network edge. And they distribute intelligence through the network while being low cost ‘commodity’ hardware. Beacons are really an extension of the network. A beacon verifies nodes on the network and receives data attribution that any transactions follow the rules of your application. But of course because this is a network element inside a venue, it needs to be secured, managed and future proofed, so both the value and cost is in the services.
- So iBeacon is not a hardware play. It’s actually a way to distribute software to create the first API layer for the physical world. And here’s the magical part: it’s completely free of charge from a power perspective. Beacons use effectively zero power themselves, and soon will last forever2. But even more importantly, scanning for beacons at the OS level also uses zero power. Think about that for a second: with iBeacon, Apple made a way for your phone to constantly ‘see’ signs (i.e. scan for BLE signals), all the time even when on standby, without using any power at all3. This is truly a remarkable breakthrough for location technologies. Beacon IDs are all individually unique (as unique as IP addresses). So in actuality, beacons can be thought of as place URLs for the real world.
- The real cost to deploy this technology is the cost to acquire the merchants and to access a trusted physical space, not the cost to distribute the beacons. Beacons are a commodity in the classic sense; they are made with low cost hardware. But the installation of a beacon into a physical space has an additional cost (the cost to acquire the merchant), and an implied security cost (no one wants their venue ‘hacked’, so beacons need to be managed and secured). Beacon hardware itself will cost mere dollars in the future. A company could literally blanket all 20 million SMBs in the US for less than $100M. This is absolutely nothing at a time when tech companies are paying billions to acquire companies. When you do the math it’s quickly apparent that neither the cost nor the value is in the hardware. It’s in something entirely different: extending network services and accessibility to transactional value at the app layer.
- But offline retail is not a winner take all market. Just as consumers are not going to download an app for every retail store on their phone, merchants are not going to put a beacon for every service in their venue. The physical world is the long tail. You may shop at Amazon almost every time you buy something online but you will likely never dine at the same restaurant 10 times in a row. And whether you arrive at a venue via OpenTable, Google Maps, Yelp or the next breakout mobile startup, beacons should be deployed as a platform that developers can access. Imagine for a second if beacons were distributed at scale to merchants, and all they had to do was hang them on a window. It’s very probable that they will be distributed by someone who has a combination of (a) an at-scale consumer footprint and (b) acquisition of merchants at scale. And the company distributing the beacon has an opportunity to open this as a platform. The trend toward single-purpose experiences in mobile further suggests this should happen. Almost all have mobile payments, almost all are mobile only or mobile first, and all would elegantly tie into a beacon to close data attribution. Imagine if Uber placed a beacon in the car to automatically alert the driver that, yes, it’s indeed you who opened the door.
- As such, beacons will serve as the new network edge, enabling context to be unlocked by developers to make physical places smarter. Metaphorically speaking, an iPad will be running the restaurant or venue. And apps will be ‘installed’ on venues. In order for this to work, it needs to be neatly exposed for developers as an authenticated / trusted beacon that belongs to a venue owner and is authorized by them, opt-in for the consumer. The developer will effectively ‘install’ their app on the venue (for example, OpenTable could immediately power auto arrival check-in to the host and payments). The developer will get some basic information about the beacon you’re nearby—where it is located, name of the venue, venue type (store, restaurant, stadium), tying the event to CoreLocation in iOS. If the beacon is inside a secure venue, then the venue will install the app because they get something in return—foot traffic, more loyal customers and insight into how their physical venue is utilized.
- By unlocking location at this level for any authorized app to use, the edge of the mobile network finally becomes smarter. If developers are allowed to globally authorize beacons in a network framework, apps must trust the beacons and be agnostic to how they interpret location IDs, on both iOS and Android. Indeed, iBeacon (and Android’s equivalent) will bring a certain ‘block chain’ like effect to the physical world, allowing innovations like transaction mapping and time-stamping to be combined with location authentication. This is an abstract analog, but just as the bitcoin block chain ledger provides checks and balances which allow the network to police behavior around transactions, iBeacon will enable a sort of physical world identity verification that was computationally expensive or impossible beforehand. For example Yelp could only allow you to create a verified review if the app knows you dined there. I can tell you firsthand that all of this potential is now mobilizing the developer community like crazy.
Most people don’t yet get it, but beacons as a platform are really a wedge into ‘appifying’ the physical world. They give context to a physical space. They are a way of actually extending the network intelligence to the edge again, something that has been missing since the desktop era. Beacons are truly a way of giving your smartphone eyes—place dumb signs around you and let your phone discover and read them.
As this new edge network that’s arriving finally converges the online and physical worlds, it has the potential to make your life as a consumer radically better and completely change mobile behavior. We are in inning one of connecting a person’s unique identity to offline devices, people, objects and physical places and it’s very clear that the most exciting times yet for mobile lie ahead.
Sure GPS and Wi-Fi give context, but really only at the city block level, not indoors. Innovative companies like Moves have been employing proprietary data science and sensor fusion to solve these problems, but it’s imperfect, proprietary, and not extensible between apps at a platform level ↩
New chips can be sub 5mA peak power, way below what’s deployed today. Cortex M0 based SoCs target extremely low sleep states, approximately 5mA and below peak power. And additional energy harvesting techniques will make it possible to not even use a battery and completely power the system off energy harvesting. ↩
Ranging, which better approximates exact location of the beacon, uses a small amount of power, so Apple has restricted it’s use for 10 seconds after beacon discovery ↩
The scary part is the manifestation of that context layer, and the growth of an active ecosystem on top of it, is dependent on the standard staying open enough that a diverse set of use cases (apps and devices) can hook in. You wrote “iBeacon” 8 times and “BLE” once. iBeacon was just Apple’s proprietary way of re-branding the iOS method they layered on top of an open protocol. It was probably necessary marketing– Bluetooth had failed with consumers in many ways. But I’d hate to see Apple take that sentiment further and fork their implementation of BLE to the point where it can’t play nicely with other bluetooth-based devices.
First of all, iBeacon is more than branding/marketing. It’s a standardized BLE signal format that includes the beacon ID and (specified) location. Sure, it’s nothing fancy, but implementing iBeacons is only a few lines of code. Without the iBeacon API, all of the above article still may be true, but without an easy to implement standard no one would bother to implement it.
Also, iBeacons are deeply integrated in iOS 7. The OS continuously scans for iBeacons with zero power usage (as explained in the article). This is something only Apple could do.
Third, any BLE device can scan for iBeacons. Not just iPhones. Currently, there is no BLE “beacon” standard. Anyone (Android?) can adopt the Apple standard (again, which is nothing more than a pre-specified format for BLE signals).
Apple is simply trying to make it easy for developers to use BLE (a simple technology with huge potential). No one else is doing that. Imho, you should be applauding Apple for trying to make a new technology accessible to a large crowd of customers (isn’t that what innovation truly is about?) instead of criticizing Apple for it.
Apple’s efforts have definitely made BLE more accessible to developers, just like Estimote’s and Google’s. I didn’t mean to dismiss those efforts, only to suggest they started down a path that could result in a forked, closed set of services– a move not without historical precedent for Apple. “Anyone can adopt the Apple standard” sort of reinforces my point here.
I’m not trying to antagonize Apple. I’m just say, yet again, we are heading down a path to an ecosystem whose openness, accessibility and rules are centrally controlled by a private entity. I hope they choose to be benevolent, but that’s a risk I’d prefer not to be so exposed to.
I disagree. iBeacon is simply applied BLE. They’re different things. The competion doesn’t even have an alternative. I still think your concern is unjustified.
BLE in its current form is unusable.
I wonder if this is the sort of breakthrough that wearable-computing is waiting for…
Steve, how far advanced do you think Apple’s and Google’s thinking is regarding iBeacons? Do you think Apple realizes the possibilities of this technology, and do you think their thinking is as far long as yours is?
Nearables, not wearables. Nice.
And it plays into Apple’s finest unknown feature, its superb crypto engine. All this ambient info from wrists and walls will need a safe place to reside. Ad agencies need not apply.
The points about trust can’t be understated. Need a system that ensures a beacons’ location information, the street signs of this new edge context, can be trusted and are accurate, otherwise system falls apart. Not sure how this is done now, but hope it could be accomplished without requiring a central entity like a trusted registry. I’d like to the block-chain concept fleshed out in more detail.
Also I’ve got a theory the Customer Hijacking is possible in retail, briefly mentioned here: http://streethawk.com/blog/2014/04/23/3-things-i-hate-about-the-ibeacon-hype/ have not thought about it too much but seems possible.
Great breakdown of the power of beacons. I understand why everyone is focused on commerce – it’s all about the money. We’re focusing on Open Houses: colleges, universities, new store openings, museums, art galleries, etc. Possibilities are endless: http://openhouses.do. More information on the implementation, how it works, etc. can be found on our Kickstarter campaign: http://kck.st/1h2zbWG.
It will be interesting to see where beacons get adoption. They will be huge, but it may not be retail. Take NFC – it was ‘meant’ to be driven by the payments industry. Wave and pay. But it’s greatest use is now in public transport.
The idea of getting endless notifications is terrifying. Context and personalisation with be critical if its to add value to the consumer. Otherwise, why happens if ‘innocently’ wander by the lingerie section? https://www.youtube.com/watch?v=beN7FftWNCM
Barry – I agree with your point about the endless notifications.
Beacons could be a victim of their own success. Receiving a notification in every shop, restaurant, bowling alley, park and cinema will be a terrible customer experience.
I fear it’s one of those technologies which has been designed to be more suitable for businesses than consumers.
That being said, there are some interesting concepts for ubiquitous Beacon use, such as indoor mapping and payments.
Great long-term thinking Steve. We should be making that clear, repeat as many times as possible that beacons are a means to provide contextual awareness – they do not track, are not very good at indoor positioning and definitely using them to drive people crazy with push messages is the worst application of this technology. The applications that will make this technology are the ones that empower the consumer and create new experiences – contextual museum exhibits, smart cities, intelligent barriers at stations, airports etc, intelligent transport to name a few, or in general: context at your fingertips.
Your analogy that a beacon is a virtual sign is a really powerful one – with the catch that it is Apple that decides who sees the sign! A physical sign can be seen by anyone, whereas an iBeacon can be seen only if you specifically subscribe to be notified about it – making this an interesting play when it comes to owning the iBeacon world infrastructure deployment.
Disclaimer: I run BlueSenseNetworks.com and we are a full stack iBeacon solution provider.
I think your conclusion that Apple decides who sees the virtual sign is incorrect. Anyone can see the sign, only Apple is specifying a certain message format to use on the sign so that phones can automatically read them. I hardly see Apple’s fault here. Without a BLE specification, it would practically be impossible for developers to actually use the technology. Unless there already exists some powerful BLE specification that Apple is ignoring, I can only applaud Apple’s work for bringing BLE to the mass.
Unfortunately, Apple enforces a 20 UUID monitoring limit at any given time (on iOS) so you pretty much need to know what you’re looking for. Unless someone comes up with a hybrid solution that scopes UUIDs along GPS regions and gets everyone to adopt that, the reality is that beacons will be held hostage to specific apps for some time to come.
The current iBeacon implementation in iOS 7+ requires your app to register to receive notifications when a beacon with a specific UUID shows up in range. The app needs to know the UUID of the iBeacon it wants to get notified of – it is not possible to see all iBeacons around you. The BLE stack underneath detects all BLE devices in range and distinguishes the iBeacons, but let’s you get notifications only from the ones you already know about.
That’s what I had in mind when I said that Apple controls who sees what – as opposed to a real sign that can be seen by anyone, regardless of who put it there!
In fact Apple make the approach pretty clear here: https://developer.apple.com/library/ios/documentation/userexperience/conceptual/LocationAwarenessPG/RegionMonitoring/RegionMonitoring.html “Be judicious when specifying the set of regions to monitor” AND “As the user’s location changes, you can remove regions that are now farther way and add regions coming up on the user’s path.”
I assume you reply was targeted more at Michael Brill’s reply, than at mine. What you are saying is correct, I was merely trying to make a point that you still need to know the region UUID in advance.
I agree with your ‘last mile’ interpretation of this but I’m confused as to the ‘appification’ I don’t understand how apps are going to work in this new model. I will only get this nearable interation if I already have the app installed. That’s a bit like saying I won’t see a website unless I have it’s page cached.
I think we’re pretty much in agreement with the nearable concept but are just a bit different on execution. I would think something that points to a website is significantly more flexible and much much easier to use as it requires no install (and no deletion)
Of course that native > web argument is always there and I won’t fight that. But as these nearables proliferate, what they do will become simpler and simpler: calling a phone number, showing me a bit more info (like the next train). I don’t *need* an app for many of these nearables, a basic web page is MORE than enough.
Is there anyway we can have *both*? An app experience if you want AND a web site for the very simple, info based apps? That really would blow things open.
Great write up Steve. One of the absolute best around about the (can’t even say “potential” because we’re way past proving that hypothesis) huge power sight for smartphones and tablets brings, and the first wave of truly contextual products and services. When will the first mapping system be driven not off GPS but by beacons?!
“beacons should be deployed as a platform that developers can access”
I love the sentiment but unfortunately the nascent beacon world is heading in the opposite direction. iBeacon APis that discourage this type of global accessibility; beacon manufacturers are building lockdown mechanisms into the beacons/SDKs; large retailers are terrified of being showroomed by outside apps and will lock down access (this is 100X the problem that potential spoofing provides); existing app providers that add beacon support will certainly adopt a land grab mentality if they have to do the evangelical work of getting venues to install hardware; etc.
It strikes me that things will have to get really messy first before people realize why we need this openness. And for that to happen, there has to be a bunch of compelling beacon implementations. However, since beacons aren’t really very usable for indoor positioning and it’s not clear if they ever will be, we’re sort of left with macro location use cases where frankly most of those can be done with GPS. And the added advantage of GPS is that it is exactly the open platform you describe (and accurate enough for most – not all – scenarios).
But a great write-up… thanks for doing it!
As wonderful as this article is, I’m still having trouble envisioning the killer experience this gives a customer. On a basic level, can someone answer; what is the beacon’s relationship with the smartphone from the UI? Is it just some shitty little text that snaps your lock screen? How is this technology experienced, how does it manifest into actual customer value? I’ve heard stuff about helping you find your seat in a sports stadium but is there a potential killer use case for this technology that the average customer will want it for? I wish Steve could help illuminate this stuff…
I think there’s more abstract hope than compelling examples so far. But this wouldn’t be the first technology whose world-changing implementation wasn’t envisioned at the start.
Decent chance it just ends up being a productivity enhancer (e.g., you get on a beacon-enabled bus, your phone then grabs the latest schedule, sees you’ll be dropped off from your next meeting where you’ll be 10 mins late so it sends an automatic notification to meeting members). Stuff like that. Maybe not earth-shattering but you start to put that into all of our daily workflows and maybe it becomes indispensable.
Personally I’m still enamored of retail… not the shitty little offer variety but connecting venue inventory based on location within venue, user intent and external buying expertise – an advice model alternative to advertising. Problem is, iBeacons lack real-world precision necessary to make this scale (plus all the openness issues Steve wrote about).
Some of the numbers and units are wrong.
BLE advertising (ibeacon) is low power but not ZERO power. We use the Nordic 51822 which can vary the TX output current between 5.5mA and 16mA (16mW and 48mW @ 3V respectively). BLE advertising is low power because it has a very low duty cycle (e.g. 2.6ms/1s = 0.3%), otherwise everything is powered off.
The idle current of the Nordic 51822 (including M0) is on the order of 2uA with state retention. The max current of the M0 is about 4mA.
So you can run 5mA continuously for only 48h on a typical 240mAh CR2032 coincell. But with a 0.3% dutycycle you can run about 2y. It is realistic to use energy scavenging (e.g. indoor solar) for this average 10uW power consumption for effectively infinite battery life.
I’d say it’s closer to hearing than to sight.
Giant Elephant Speaking (your phone’s battery) – I don’t care how low-powered this thing is going to be. If it will require the user to keep their bluetooth in the ‘on’ position all day, it will kill their batteries. Take a poll, what percentage of smartphone users keep their bluetooth on all day? I keep mine off unless I am using it in my car (where I also plug it in). Our devices are getting more processor demanding and doing more things. Meanwhile, the batteries aren’t improving (they’re getting thinner!).
I keep mine on all day no problem. Sounds like you need a phone that has BLE. If you don’t have it today your next phone will and soon everyone will.
Your site’s design makes it impossible to read.
Brilliant reasoning ! A comment on 6: App sensing of iBeacon proximity is in fact not free. Each app need to exercise a scanning thread where the frequency of doing this will affect phone battery charge. Developers are devising app tricks such as using GPS in combination with Bluetooth LE to determine when the phone arrives at a place where scanning for the iBeacons is a worthwhile idea.
But with tech evolution the proximity awareness process will likely become managed by the hardware and power usage refined.
Uber wouldn’t even have to place a beacon in the car / deploy hardware — the driver’s device or Uber driver app respectively could just advertise an iBeacon, right?
@stevedcheney:disqus question pls: as i understand it, only in-app can pick up coupons, not at an OS level. i understand OS level scans but i have been told that if you want coupons to be read, you will need an extra software layer, therefore an application. is this correct?