Content uploaded by Scott Jenson
Author content
All content in this area was uploaded by Scott Jenson on May 09, 2016
Content may be subject to copyright.
Building an On-ramp for the Internet of Things
Scott Jenson, Roy Want, Bill N. Schilit
Google Inc.
1600 Amphitheatre Parkway
Mountain View, California, USA
{scottj, roywant, schilit}@google.com
Robin Kravets
University of Illinois, Urbana Champaign
Department of Computer Science
1304 W. Springfield Ave, Urbana, Illinois 61801
rhk@illinois.edu
ABSTRACT
The Internet of Things (IoT) is in its infancy, similar to the state
of the Internet before the World Wide Web made it an
indispensable tool for communication, business and
entertainment. A similar revolution is needed for the IoT to
become really useful. This paper identifies some important
problems with today’s IoT involving discovery and control, and
proposes some solutions based on a concept we call the Physical
Web, an integration of the IoT with Web technologies.
Categories and Subject Descriptors
H.5.2 [Information Interfaces and Presentation]: User
Interfaces—Input devices and strategies.
General Terms
Management, Design, Security, Human Factors, Standardization
Keywords
IoT; Physical Web; UriBeacon; Discovery; Bluetooth Low
Energy
1. INTRODUCTION
The Internet of Things (IoT) is rapidly being integrated into our
everyday lives. From connecting to a single smart device, such as
a thermostat, to an ensemble of devices [1], such as the lighting
system in an office building, we can interact with the environment
around us. The availability of these devices is growing rapidly,
with an estimate of 26 billion devices by 2020 [2]. However,
interaction with so many diverse devices will quickly become
intractable using the current model for native apps.
Whether dealing with a single device or an ensemble, there needs
to be an easy-to-use interface to present to the user. Current
solutions for interacting with IoT devices have relied on the use of
smartphone apps. For use cases ranging from allowing a person to
walk into a room and turn up the heat, to controlling the set of
lights in a building, developers can design and implement a
custom app and give the user control. Given the ubiquity and
power of smartphones, building such apps is a good start in the
right direction.
The trend, however, is that the number of smart devices and
ensembles is growing, and along with this growth, there is a
growing diversity of apps to interact with them. Furthermore,
demand for IoT is moving beyond private and corporate spaces,
and into the public world. People will be interacting with IoT
devices in stores, airports and bus stops. While users may be
willing to install relevant apps for their home or work spaces,
which they interact with on a daily basis, installing an app for
every IoT device they encounter during the day will quickly
discourage them from ever using public IoT infrastructure.
Instead, a lightweight solution where people could just walk up
and use a device, without having to install any app, could
overcome the hurdle of a ‘difficult to use’ IoT experience.
In the following sections we describe how IoT devices can be
merged with Web technologies, and enable the traditional Web
browser to become a single point of IoT interaction for users. We
describe how every IoT device can have an associated Web page
and broadcast a URL using standard RF protocols. Smartphones
receiving multiple URLs can process them to produce a page-rank
of nearby IoT devices using proximity as a guiding principle. IoT
status monitoring and control is then achieved by direct
interaction with the corresponding Web server.
2. WEB BROWSING, SEARCH AND IoT
To understand how to manage the massive increase in scale
expected from the integration of IoT apps and devices, it is
interesting to look back to how the scalability was handled in the
early Internet and Web [3]. In the early 1990s the World-Wide-
Web was born on top of the Internet. Early solutions for
managing scale were not effective, for example, single pages that
attempted to catalog the entire Internet. It was quickly realized
that a Web browser needed to integrate a search mechanism
resulting in the familiar browser and search toolbar we use today.
This scalable paradigm has become widely used and is the
foundation of many Internet companies based on the Web today.
As a result, the Web browser, plus search paradigm, is familiar to
anybody that uses a networked computer.
The IoT is likely to increase the scale of the Internet as much as
100x, and there is no reason to move away from the browser and
search paradigm. However, today many IoT products enable
action through proprietary solutions, which introduces several
problems. First, the user needs to install a specific app on their
mobile device. Second, the app’s GUI may be unfamiliar to the
user and non-intuitive to use (native apps often have more
Permission to make digital or hard copies of all or part of this work for personal
or classroom use is granted without fee provided that copies are not made or
distributed for profit or commercial advantage and that copies bear this notice and
the full citation on the first page. Copyrights for components of this work owned
by others than ACM must be honored. Abstracting with credit is permitted. To
copy otherwise, or republish, to post on servers or to redistribute to lists, requires
prior specific permission and/or a fee. Request permissions from
permissions@acm.org.
IoT-Sys 2015, May 18, 2015, Florence, Italy.
Copyright 2015 ACM 978-1-4503-3502-7/15/05…$15.00
http://dx.doi.org/10.1145/2753476.2753483
3
diversity than, for example, Web pages). Finally, installing an app
for every device, or even an ensemble of devices, does not scale
to the thousands of IoT devices that a user may encounter every
day. To make the IoT intuitive to use and universally accessible
to everybody, we believe a Web browser paradigm is a strong
contender for the single user-facing app solution. To realize this
solution, devices must be able to advertise a URL and the user’s
smartphone, or ensemble of wearable devices, must be able to
manage the hundreds of device URLs that it may discover in any
given environment. Furthermore, the Web is open, and isn’t the
product of any one company. The Web is a standard, and URLs
can be resolved without a single company controlling the gateway
(e.g. DNS [4]), making it possible for unencumbered innovation.
3. PROXIMATE DISCOVERY
The first step for effectively solving the ‘IoT walk up and use’
problem is to automatically identify devices, or things, that are
nearby, and use these identifiers as a means to query and control
them. There are many technologies that have been explored in
earlier research, but all have limitations that make them
unsuitable, e.g. RFID (due to a lack of mobile readers), QR codes
(labor intensive, and can only identify one device at a time), GPS
(only works outside, and lacks precision). However, the relatively
new Bluetooth Low Energy (BLE v4.0) standard [5] provides a
mechanism for each device to periodically emit an RF packet with
an identifier that can be received by any modern smartphone since
about 2011. The standard allows great flexibility in the
information encoded in it, from UUIDs in devices known as
iBeacons, to URLs in the UriBeacon open standard [6]. In the
context of a Web-based IoT, UriBeacons can provide
smartphones with a list of nearby IoT devices with associated
Web pages and control functionality. We call this the Physical
Web [7], which is the integration of the IoT with Web technology.
UriBeacons signal the presence of nearby IoT devices up to 10
meters away; therefore a smartphone in a smart environment
might receive large numbers of UriBeacon packets. A practical
system could filter this list, if it could estimate the distance of
each device using RF ranging.
When working with a smartphone, one of the most common
approaches to determine range is to subtract the received signal
strength (RSSI) from the originating transmit power to yield path-
loss, and then translate path-loss into a distance estimate. In an
ideal world, this would be a simple translation, since the wireless
signals follow well-known physical rules. Essentially, the strength
of a transmitted signal roughly attenuates with the inverse square
of the distance. Unfortunately, we do not live in a vacuum,
transmit antennas are not point sources, and wireless signals
experience multipath interference in a building, all making it
difficult to directly translate path-loss to distance. In the end, for
an app that requires precise ranging information, path-loss has
limited accuracy.
However, despite these challenges there is a trend between path-
loss and range. Assuming a transmit power of about 0 dBm, a
strong correlation between path-loss and range exists for small
distances on the order of 0.5m. The correlation gets noisier
between 0.5m and 2m, and very noisy beyond 2m. Given this
finding, validated experimentally, we can use the path-loss
parameter as a rule of thumb to determine whether a UriBeacon is
in one of four defined regions: Nearest, Near, Mid, and Far. For
the purposes of a Physical Web browser application, this
differentiation is sufficient.
Although Wi-Fi could be used instead of Bluetooth LE in some
situations, many Wi-Fi networks are secured with a passcode and
are not accessible to mobile devices that happen across them. This
is one reason Bluetooth LE broadcasts are so important; it allows
devices to advertise information in a way that requires no prior
association or pairing. Essentially, the advertisements are public
broadcasts and can be received by all. By including the signal
strength (Tx-Power) in these transmissions, any receiver can
estimate the range/region of a remote device. This virtual
identifier, formed from the combination of a URL and ranging
data calculated using path-loss, makes it possible to build our
Physical Web solution based on today’s smartphones and existing
standards. However, we would like to note that if a wireless local
area network is available and accessible, multicast solutions [8]
provide additional augmentation of the discovery mechanisms
described here.
4. EPHEMERAL INTERACTION
Allowing each device or ensemble to offer up a modest Webpage
is often met with skepticism because native smartphone apps are
considered superior. However, most of these smart devices have
very straightforward needs, such as a simple on/off switch, or the
ability to scroll through a short list of information. The Web is
perfectly fine for this. In addition, the Web is ultra-lightweight:
walk up to a device, view its Web page and interact or move on.
The entire interaction becomes ephemeral.
Such interaction turns the entire native application model on its
head. Native apps are in effect caches of functionality that can be
used over and over again. By using this ephemeral approach, the
Physical Web assumes short, one-time Web-based interaction
with a device, allowing the Web app to clean up after itself once
the user has moved on. Of course, users can easily save a
Webpage if they wish and new Web technologies like Service
Worker [9] make this especially powerful. However, even if a
user interacts with, for example, a particular bus-stop on route to
work each day, this Web-like flow requires only a few finger taps
and is not a heavy burden on the user experience.
Furthermore, we would argue that this switch to ephemeral
interaction has a much bigger effect; it redefines what it means to
be a smart device. If every device is capable of having a virtual
flash card giving the user more information or interaction, it will
change what it means for devices to be smart.
The Physical Web’s primary value is to enable a device to place
at users’ fingertips anything from a tiny piece of location-based
information, to a full-blown Web app.
As a result, devices or objects that may have been previously
considered dumb now become smarter. If anyone can peek into an
object’s virtual flash card, it makes it nearly impossible for it to
be lost. For example, luggage and pet collars can now offer up a
phone number, movie posters can offer up previews and ticket
sales, malls can offer kiosk style maps anywhere in the space.
None of these devices are inherently smart, but they all allow for
much smarter interaction.
Each of these examples, taken individually, is moderately useful.
Taken as a whole, however, they imply a vast “long tail” where
anything can offer information and utility.
5. IoT SEARCH
In practice, browsers in combination with search engines do more
than provide us with a list of textual URLs, they also provide us
4
with a useful and intuitive user interface with snippets of each
page, filtered content, and rank ordering of the list. In a Physical
Web browser we would expect similar features that are expanded
on below:
Snippets: a URL is often a textually obscure reference to a
Webpage and difficult for a user to interpret. In practice, it’s
better to pre-fetch data from broadcasted Websites in order to
provide a user with not only the URL, but a title and snippet of
the referenced Web page to guide users to the required
information. For the Physical Web, this would be acheived using
an additional proxy service. In the case of IoT devices, the snippet
may contain identifiable information about the device, such as
type, name, model, and its status. Simple graphical controls could
be provided within the snippet to reduce interaction time e.g. up
and down buttons to change a room’s temperature setting.
Filtering: Search engines also protect us from nefarious Websites
and reduce a user’s exposure to spam sites that are designed to
grab your attention when they don’t actually contain the
information you were looking for. In this case they serve as useful
filters for the Web. The IoT is no different, and will soon be
polluted by nefarious devices and services that are so common on
the Web. Although the Physical Web browser is the user facing
interface for UriBeacons, the information it shows can be
preprocessed by a proxy service using a crowd-sourced database
of nefarious device URLs, and can filter accordingly.
Ranking: Probably the most important user facing feature of a
search engine is its ability to rank its search results based on
relevance to the search term and the user. In other words, as a
heuristic, the most relevant items are at the top of the list. As
stated earlier, the IoT benefits from proximity ordering, which can
be approximately determined by RF signal strength. However,
this is not the only parameter that can be considered. Other
parameters include related information that also exists on the Web
e.g. related products, companies offering value added services,
vendors of the device, companies offering replacement parts,
history of prior IoT interactions, and the state of an IoT device
e.g. a carbon monoxide sensor detecting a critical reading. The
algorithms for ranking have always been interesting [10], and
even controversial as companies vie for placement at the top of
the rank list. For IoT there are more dimensions to consider, and
the rank algorithm will be a subject of future research.
6. SEMANTICS AND IoT CONTROL
If the Physical Web understands the content of Webpages, then it
can create rich snippets and quick actions for nearby things. Rich
snippets are detailed information that can help users answer
specific needs. For example, the snippet for an exercise machine
at a gym might show the muscle groups and level of difficulty of
use. These snippets help users understand when a thing is relevant
to them. At the next level is Quick Actions that give users a path
to interacting with the Internet of Things. For example, the quick
action for a treadmill machine might be to share the user’s weight,
duration, and course preferences with the machine over
Bluetooth, or a connected cloud service.
Figure 1: Structured Data for Web Snippets
5
Figure 2: RSVP actions from Structured Data in Gmail
Both rich snippets and quick actions are enabled by structured
data within the content of Webpages. Structured data for the Web
is already well established [11], so we believe the use of
structured data for the Physical Web should be relatively
straightforward. In today’s Web, major search engines use
structured data for search results: to show recipe details,
musician’s songs, restaurant ratings (Figure 1). Structured data is
also used in email to RSVP to a calendar invite, check into a
flight, or view package delivery information (Figure 2).
These and other mechanisms use schema.org definitions. The
schema is a common way for Webmasters and email senders to
add information to HTML pages that can be understood by search
engines and email programs.
Structured data within Webpages of IoT devices can also enable
use cases at a machine-to-machine level. For example, by
automatically dimming lights in a home as a person leaves the
room. The rich description of a device and its interfaces can all be
stored in Webpages. In some protocol stacks, such as Universal
Plug and Play (UPnP) [12], the descriptions of devices, their
control points, and events, are provided directly by UPnP-enabled
devices. In our Physical Web vision, defining the Web as the
intermediary for IoT has the advantage of connecting these
devices to a vast array of existing Web-based tools and services.
7. CONCLUSION
The Internet of Things needs the ability for people to just walk up
and use devices. The current model of requiring an app for every
possible device just doesn’t scale. By enabling proximate
discovery through the UriBeacon standard, any number of devices
can be easily found nearby. This creates an extension of the
conventional Web to include the physical world, and we call this
the Physical Web. Because the Web is open, the Physical Web
will have all the properties that have allowed the conventional
Web to grow unabated. By broadcasting simple URLs it
decentralizes the entire system. There is no central server, no
gatekeeper. This is unlike nearly every other commercial smart
device system today.
In addition, it opens up a new type of ephemeral interaction,
where any device can sprout a virtual flash card of simple
information, or if necessary, more complex interaction. By
making this universal so every device can read it, from
smartphones, to tablets, or eventually heads-up displays, it means
that everything has the potential to be smarter, and nearly any
device can offer a virtual interface.
But by far the most important aspect of the Physical Web
approach is that it can be built upon easily using the flexible
format of the URL is to grow and adapt. Furthermore, using
semantic tools like schema.org, the way IoT devices can be
controlled and organized can also continue to evolve. Just as the
Web has grown and evolved over the last 25 years, we expect the
Physical Web to adapt to the expanding reach of the IoT for many
years to come.
8. REFERENCES
[1] Schilit, B. N., Sengupta U., Device Ensembles, IEEE
Computer, vol. 37, no.12, (Dec 2004), pp. 56-64,
doi:10.1109/MC.2004.241
[2] Gartner, Newsroom, Gartner Says the Internet of Things
Installed Base Will Grow to 26 Billion Units by 2020, (Dec
2013), http://www.gartner.com/newsroom/id/2636073
[3] Berners-Lee, T., Cailliau, R., Luotonen, A., Nielsen, H.F.,
Secret, A., The World-Wide Web, CACM, 37(1994), pp. 76–
82.
[4] Homes, D., The Dynamic Domain Name System (DNS)
Infrastructure, http://www.f5.com, (June 2012).
[5] Heydon, R., Bluetooth Low Energy, Prentice Hall, 2013,
ISBN-13: 978-0-13-288836-3.
[6] The UriBeacon Open Standard, (Apr 2015)
http://uribeacon.org
[7] Want, R., Schilit, B.N., Jenson, S., Enabling the Internet of
Things, IEEE Computer, vol. 48, no.1, (Jan 2015), pp. 28-35.
doi: 10.1109/MC.2015.12
[8] Antonini, M., Cirani, S., Ferrari, G., Medagliani, P., Picone,
M., Veltri, L., Lightweight multicast forwarding for service
discovery in low-power IoT networks, IEEE Software,
Telecoms. and Computer Networks (SoftCOM 2014), pp.133-
138, (Sept. 2014), doi: 10.1109/SOFTCOM.2014.7039103
[9] The World Wide Web Consortium, Service Worker, W3C
Working Draft, http://www.w3.org/TR/service-workers/, (Feb
2025).
[10] Page, L., Brin, S., Motwani, R., Winograd, T., The PageRank
Citation Ranking: Bringing Order to the Web, Stanford
University, Technical Report, 1998.
[11] What is Schema.org? (March 2015), http://schema.org.
[12] Universal Plug and Play (UPnP) Device Architecture 1.1,
UPnP Forum, (Oct 15th 2008).
6
