0018-9162/01/$10.00 © 2001 IEEE42 Computer

Websigns:Hyperlinking Physical Locations to the Web

First-generation mobile computing technolo-gies typically use protocols such as WAP andi-mode to let PDAs, smart phones, and otherwireless devices with Web browsers access theInternet, thereby freeing users from the shack-

les of their desktops. We believe, in addition, userswould benefit from having access to devices that com-bine the advantages of wireless technology and ubiq-uitous computing to provide a transparent linkagebetween the physical world around them and theresources available on the Web. Building on a decadeof research in this area,1,2 we are developing devicesthat augment users’ reality with Web services relatedto the physical objects they see.

COOLTOWNIn the CoolTown research program (http://www.

cooltown.hp.com) at Hewlett-Packard Laboratories,we are building ubiquitous computing systems3 thatsense physical entities in the environment and mapthem to a Web browser. To create a hyperlink betweena physical entity and a Web resource, we attachinfrared beacons, radio frequency ID tags, or bar codesto people, places, and things to associate them with anappropriate universal resource identifier, resolving theURI in the network if it is not already a URL. Thesehyperlinks rely on commonly available wireless mobiledevices to help users automatically access services asso-ciated with physical objects.

CoolTown’s current-generation directional IR bea-cons have an access range of about one meter. Toreceive a URL, users point their mobile device in thedirection of a beacon and receive periodic broadcasts.

We chose infrared technology to broadcast theURLs primarily because many of today’s handheldcomputing devices have built-in IR transceivers. Toreceive data on the client side, we use e-Squirt, a sim-ple protocol that provides a stable platform for pass-ing URLs between devices over the IrDA medium. Thedirectional nature of IR beacons also enables users toexplicitly select a physical object in an environmentgarnished with beacons.

Mechanically, CoolTown beacons are similar toindoor-location technologies such as Active Badges,4

but they have a different application space. Users wearActive Badges or attach them to objects to keep trackof their presence at a location, but beacons connectmobile users with hyperlinks to services associatedwith physical objects.

Deploying bridging devices like beacons and tagsraises scalability issues. Beacons require periodic main-tenance because their batteries run out. Also, whenURLs pointing to Web content change, the beaconsmust be reconfigured. These limitations are not a prob-lem with RFID tags or bar codes, but tags and barcodes can only be read at very short distances.

Wide-area deployment raises access-range issues. Forexample, consider a cafeteria that serves an entire uni-

HP researchers are developing handheld devices that combine wirelesstechnology and ubiquitous computing to provide a transparent linkagebetween physical entities in the environment and resources available onthe Web.

Salil PradhanCyrilBrignoneJun-HongCuiAlanMcReynoldsMark T. SmithHewlett-Packard Laboratories

C O V E R F E A T U R E

versity. Because beacons and bar codes have a limitedphysical access range, they would have to be locatedthroughout the entire campus to direct users to the facil-ity. Ideally, context, not technology, limits access range.

WEBSIGN SYSTEMWebsigns are an alternative way to map e-services

using a simple form of augmented reality.2 Typicalaugmented reality systems require users to wear a cum-bersome see-through head-mounted display to viewcomputer-generated images imposed on the physicalenvironment. In contrast, the websign system usescommonly available Internet-enabled wireless devicessuch as PDAs or smart phones equipped with clientsoftware, a positioning system such as GPS,5 and a dig-ital compass to visualize services for physical entities.

As Figure 1 shows, when the user requests newinformation, the mobile device connects to a Webserver and downloads and caches XML descriptionsof websigns in a wide surrounding area. This descrip-tion includes websign locations, their associated URLs,and other control information such as times when thebeacons are active. Websign clients thus use locallycached information to present relevant websigns in thevicinity. While moving about the designated area, userssee websigns as a result of pointing the mobile devicetoward physical objects of interest.

To avoid overwhelming the user and overloadingthe mobile device, our system limits the number of vis-ible websigns. Individual websigns have a detectablerange, and users should experience only the websignsin their horizon—the set of all the websigns a user acti-vates by being in their range.

Websigns are of two types: virtual beacons and vir-tual tags. V-beacons simulate IR beacons, while v-tagssimulate active RFID tags. Users see v-beacons onlywhen they are in the beacons’ range and point theirmobile device at physical locations. In contrast, usersautomatically trigger v-tags when they move into the

tags’ range. Activated v-tags can perform an HTTPrequest or just display a message on the device. Userscontrol all aspects of v-tags, including the option ofselectively turning them off.

Websigns can be personalized for individuals,group-targeted for users with specific interests orneeds, or universally available to anyone who wantsto use them. To facilitate class-specific filtering, wecan further categorize websigns by type—for exam-ple, restaurants, theatres, or historic sites.

Design principlesBased on our CoolTown experiences, we developed

a set of principles for simulating physical beacons andtags with virtual implementations. These principlesprovided the basis for our work on developing a sys-tem that consists of a server-side infrastructure formapping and delivering websigns and a client-sidedevice capable of detecting these hyperlinks in a wide-area physical context.

• Responsiveness. The websign client adapts tochanges in direction and user mobility. To reducelatency, the mobile device accomplishes part ofthe storage and processing.

• Robustness. The system is quite resilient to lossof connectivity. Even in the sporadically con-nected mode, the device permits user mobility forshort distances and does not restrict adaptabil-ity to a change in direction.

• Deployment and scalability. The system scaleswell both in the number of users it supports andthe number of websigns.

• Open and Web-based. The websign system oper-ates in an environment where users can fetch web-sign bindings from ubiquitous Web servers. Thesystem is open and based on Web infrastructure.

• Inaccuracy tolerance. The websign system tol-erates positioning inaccuracies and compensates

August 2001 43

Websigns

Communicationtower

Web servers

Figure 1. Detectingwebsigns with a wire-less PDA in an urbanenvironment. In thisexample, the PDA ispointed toward build-ings in San Francisco’sUnion Square, andthe red spheres indi-cate positions linkedwith websigns.

44 Computer

for them whenever possible. The better theunderlying system’s positioning accuracy, themore realistic the user’s experience. Even withselective availability turned off, ordinary GPSreceivers are accurate within eight meters.Indoors, where GPS receivers usually do notwork, location accuracy depends on local-posi-tioning technology, and it can be better or worsethan GPS.

• Platform heterogeneity. Client software has veryreasonable computation requirements for imple-

mentation on smart-phone and PDA platforms.The system uses open communication protocolsto allow diverse devices and servers to create andsend websigns.

Websign bindingsWebsigns essentially bind location coordinates, con-

trol parameters such as access range, and a service rep-resented by a URL. We use the Websign MarkupLanguage (WsML), an XML application, to express thebinding semantics. As the “Websign Markup Language”sidebar indicates, usually Web servers host WsML formobile devices to download over a cellular wireless con-nection. Mobile devices can also host WsML for otherpeer-to-peer devices. Typically, peer devices can com-municate over short-range radio networks such asBluetooth or send WsML embedded in text-message-over systems such as Short Message Service.

Websign creation serviceThe creation service provides the infrastructure for

creating and distributing websigns. Using a Webinterface lets the infrastructure remain both simpleand open. As Figure 2 shows, the Web interface pro-vides a geographical map as a reference for placingwebsigns. In the back end, a database stores the loca-tion, URL, and other binding information enteredthrough the Web interface. When users connect tothis server via HTTP and optionally post their coarsegranular location to a Web server, they are servedWsML based on the information in the database aswell as their profile. An alternative to dynamicallygenerating WsML is to statically create and host iton a Web server, but doing so removes the ability topersonalize content.

Server configurationWebsign clients can either autodiscover or manu-

ally select WsML servers. The system uses informa-tion transmitted from IR or radio beacons toautoconfigure clients to communicate with knownservers. Autoconfiguration is particularly useful in anenterprise scenario. For example, when employees orvisitors enter a building, an IR or short-range radiomessage can configure their PDAs to communicatewith a websign server. The PDA downloads WsML,which contains pointers to physical resources such asprinters and smart conference rooms and their asso-ciated services.

Manual configuration is similar to entering a URLin a typical browser’s address bar, but users can entermultiple addresses and the device aggregates the con-tent. This mode is useful for applications such as anelectronic tourist guide, in which users might want toaggregate websigns from various online sources suchas Web-based yellow pages or personal Web pages.

Unlike beacons, tags, or bar-code readers, websign-enabled devices donot sense URLs but instead look them up in a local cache. Figure A showsa snippet of the Websign Markup Language, an experimental XML1 appli-cation, that describes the binding between a physical location and aninformation source2 represented by a URL. Using WsML provides a com-pact format for transmitting this binding information over potentiallylow-bandwidth wireless networks.

For a number of reasons, we chose to define a new, simple markup lan-guage instead of using the Geography Markup Language,3 another XMLapplication, to bind complex geospatial areas to URLs. GML’s attributeset contains complex descriptions that the websign system does not need,and it cannot meet some websign system requirements. To keep mathe-matical computation manageable in a PDA, for example, we bind a URLto a simple point with a surrounding square area as the access zone. Web-signs also have temporal activation parameters, which GML normallydoes not describe. WsML is still an evolving format, and keeping it com-pact requires restricting the core language to a bare minimum.

References1. Extensible Markup Language (XML); http://www.w3.org/XML/.

2. S. Pradhan, “Semantic Location,” Personal Technologies, vol. 4, no. 4,

2000, pp. 213-216.

3. Geography Markup Language; http://www.opengis.net/gml/00-029/GML.

html.

<?xml version="1.0"?><websign>

<vbeacon id="ID" href="url" label="title"><location>

<lat>lat</lat><lon>lon</lon><range>range</range>

</location><time>temporal activation parameters</time>

</vbeacon><vbeacon …>

…</vbeacon>

</websign>

Figure A. Websign Markup Language snippet. WsML provides a compact formatfor transmitting binding information over a low-bandwidth wireless network.

Websign Markup Language

Prototype deviceWe implemented the current client in C++ on an HP

Jornada 548 pocket PC, but we could have used anyother reasonably robust hardware platform such asthe Palm or Epoch. For wireless connectivity, the sys-tem uses IEEE 802.11B indoors and cellular digitalpacket data wireless modems outdoors. The proto-type positioning hardware includes a magnetometerthat serves as a sensor for the digital compass, a GPSreceiver, and a peripheral interface controller micro-processor to control the sensors and to multiplex thesensor data into a single stream. The prototype posi-tioning hardware uses a standard RS-232C serial linkto communicate with the Jornada.

Client architectureFigure 3 illustrates the websign client architecture.

The positioning hardware provides information aboutthe user’s current location and direction to the websignkernel. The horizon filter uses this location informa-tion to determine the user’s exact horizon, whichincludes all active websigns. The vectoring filter thenselects the websigns that are in the user’s direction vec-tor. Finally, the user interface displays the labels of rel-evant websigns for the user to select.

In addition to functioning as a client-side softwarecomponent that controls functions such as communi-cation, power management, and compass calibration,the websign kernel also serves as a hardware abstrac-tion layer. This is important because different appli-cations can use various configurations. For example,if a corporate environment only needs an indoor posi-tioning system, the system design can omit the GPSreceiver.

The kernel also refreshes the websigns in the inter-nal cache. When the user makes a request, the kernelqueries the positioning hardware for the current loca-tion, fuzzes it to protect privacy, queries Web servers,and stores the WsML response in the internal cache.

In response to changes in the user’s location, the ker-nel invokes the horizon filter. The horizon filtering algo-

rithm uses the current location to query websigns inthe internal cache and aggregates websigns with a rangethat spans the current location into the horizon set.

The kernel invokes the vectoring filter in responseto changes in the compass readings. When the userpoints the viewing device, the vectoring filter selectswebsigns in that direction and forwards them to theuser interface. As the “Vectoring Filter Algorithm”sidebar explains, this algorithm is quite efficientbecause the horizon filter has already reduced the setof websigns through which it iterates.

The vectoring filter forwards the final set of web-signs to the user interface, which displays them on themobile device’s screen. To avoid screen flicker, the fil-ter discards the result of the current search if it isunchanged from the previous iteration.

The user interface supports two selection modes:physical browsing, which is the default mode, and

August 2001 45

Positioning hardwareWindows CE platformWireless network

Websign kernelWeb browser

User interfaceHorizon filter

Vectoring filterCache Buffer

Figure 2. Websign service. The user enters a postal address of the websign’s generaldeployment location, views and selects the exact location on the displayed referencemap, and specifies rudimentary binding properties such as a label, an access range,and a URL to associate with that location. The system then enters this information intoa database.

Figure 3. Websign client architecture. Cascading filters select websigns relevant to the user’s direction vector.

46 Computer

casual capture. As Figure 4 shows, the user presses abutton on the mobile device, and the user interfacecontinues to refresh and display the labels of appro-priate websigns. Clicking on a label invokes a Webbrowser. Casual-capture mode is useful for collectingwebsigns for future reference because the device aggre-gates all the websigns as the screen displays them.

OTHER APPLICATIONSWhile the websign system is appropriate for applica-

tions such as electronic tourist guides, we anticipate amore general use as a digital interface that enables usersto see and interact with services associated with physi-

cal objects. We could likewise deploy websigns at pop-ular tourist spots to show maps of the area, but the mapswould also provide hyperlinks to services. Websigns arealso compatible with applications such as “virtual Post-its”6,7 that allow users to annotate physical locations,much like posting an adhesive note on a physical object.

Research on smart spaces or intelligent environmentshas become popular at many universities and corpo-rate research facilities. Interactive space managementsoftware such as the Web Presence Manager8 aims toconnect computers and computation resources to thereal world. However, the beacons, tags, and trackingcameras that these systems typically use as sensors usu-

The websign vector filtering algorithm addresses three mainperformance issues: jitter, depth and size perception, and inac-curacy tolerance.

In the early prototype trials, we observed a strong screen jit-ter primarily in websigns on the edge of the aperture—the angu-lar range through which a mobile device can rotate whilecontinuing to “view” a websign. (The aperture is not a globalvalue and varies by websign.) Minor changes in direction, typi-cally attributable to a user’s unsteady hand, caused these bor-derline websigns to vacillate in and out of the display list. Thevectoring filter corrects this aberration by artificially introduc-ing hysteresis. The idea is to make it a little harder to drop a web-sign from the aperture after capture. The vectoring filter initiallycomputes a websign’s aperture from several parameters and,upon display of the websign, adds a small hysteresis angle. Thismakes the websign appear in a wider angular range. Once thewebsign falls out of the angular range, the vectoring filter resetsthe aperture.

Humans perceive depth by interpreting binocular visual cuesfrom the environment. To a human eye, the size of an objectappears to be inversely proportional to the distance. To preservethis depth and size perception, the vectoring filter computes theaperture as a property of the distance between each websign andthe user’s device. Because the aperture is inversely proportional

to the distance between a websign and the user, websigns nearerto the user have a wider aperture, while those further away havea smaller aperture.

The underlying GPS receiver is usually accurate within eightmeters. While this level of accuracy is adequate for distant web-signs, accurately positioning those in the user’s immediate vicin-ity can be difficult. For example, in the prototype’s early stages,we placed a websign at a bus stop just outside HP Laboratories.We walked near the bus stop and pointed the Jornada pocketPC in its general direction, but no websign appeared. Scanningaround with the device, we found the websign in the exact oppo-site direction, an aberration caused by a positioning error of justa few meters.

The positioning inaccuracy of the GPS can cause consistencyproblems. While the GPS may indicate that the websign is at agiven location, it could be at any location ρ anywhere in a circleof inaccuracy Γ around that point. As a result, the PDA’s visionν—the set of all active websigns within the cone-shaped poly-gon formed by the aperture angle—shifts, and the websign is nolonger visible. To counter this consistency problem, the PDAneeds an extended vision VE , which is the union of the visionscomputed for each individual point in the circle of inaccuracy.Figure B illustrates the possible visions that might arise due toGPS positioning inaccuracies.

(1)

Γ GPS location

Websign 2

Websign 1

Aperture

(2)

Γ Potential userlocation ρ

Websign 1

(3)

Γ

VE

Websign 2 (displayed)

Websign 1(not

displayed)

Websign 2

Figure B. Extended vision. (1) Location and vision of a user as reported by GPS. (2) The user could be anywhere in the circle of inaccuracy (Γ). (3) Extended vision (VE) is the union of the visions at all locations inside the circle of inaccuracy.

Vectoring Filter Algorithm

ally limit their use to room-sized areas. Adding web-sign v-beacons and v-tags to augment this gamut of sen-sors would make it possible to create large-scale smartenvironments. For example, a websign system user whois sitting in a restaurant could point a mobile device inthe direction of a nearby theatre to get informationabout what movies are playing.9

F or users to find them of value, bridging tech-nologies like websigns must be convenient andtransparent. The websign system relies on a

diverse set of positioning technologies to support bothindoor and outdoor use. Making this location diver-sity transparent is one of the usability challenges.

The websign system’s scalability depends on theunderlying positioning system. Few would disagreethat for an outdoor system, GPS is very scalable interms of the potential number of both users and web-signs. For indoor applications, the choice of locallydeployed positioning technology is an essential factorin ensuring that the system also scales well.

Privacy is clearly important to users. To protect pri-vacy, websign clients do not divulge precise users’ loca-tion. Unscrupulous services may attempt to associatea unique URL with users’ presence at a websign loca-tion, thereby linking them to a specific place at a giventime. However, users can bookmark a URL on the firstvisit and revisit a Web site without physically beingpresent, making it difficult for such services to makea positive distinction between users’ physical and vir-tual presence.

From a deployment perspective, the system is morescalable for outdoor applications than using physicalshort-range beacons. The lack of commonly availableand deployed indoor positioning technologies hashindered indoor deployment, but we are currentlyevaluating a promising technology10 from the Massa-chusetts Institute of Technology for use as the under-lying indoor positioning system. We are also con-

ducting further user studies exploring how to betteraugment reality with virtual beacons and tags. ✸

AcknowledgmentsDeveloping the websign prototype turned out to be

more complex than originally estimated. We thankBill Serra for explaining the intricacies of the PocketPC operating system. Jeff Morgan, Marcos Frid, BillSerra, and John Schettino developed and demon-strated the concept of URL beacons, which has had astrong influence on the websign system’s design. Wealso thank Patrick Scaglia, Gary Herman, Gita Gopal,Fred Kitson, Venky Krishnan, Jean Tourrilhes, GlennSteiner, Patrick Goddi, Tim Kindberg, John Barton,John Grundbäck, Jan Gugala, and our anonymousreferees for helpful discussions and suggestions.

References1. J. Sphorer, “Putting Information in Places,” IBM Sys-

tems J., Sept. 1999, pp. 602-628.

2. R. Azuma, “A Survey of Augmented Reality,” Presence:Teleoperators and Virtual Environments, vol. 6, no. 4,

1997, pp. 355-385.

3. M. Weiser, “The Computer for the 21st Century,” Sci-entific American, vol. 265, no. 3, 1991, pp. 94-104.

4. R. Want et al., “The Active Badge Location System,”

ACM Trans. Information Systems, vol. 10, no. 1, 1992,

pp. 91-102.

5. Interagency GPS Executive Board; http://www.igeb.gov.

6. P. Brown, “The Electronic Post-it Note: A Metaphor for

Mobile Computing Applications,” IEE ColloquiumMobile Computing and Its Applications, 1995; http://www.

cs.ukc.ac.uk/projects/mobicomp/Fieldwork/Papers/.

7. P. Brown, “Triggering Information by Context,” Per-sonal Technologies, vol. 2, no. 1, 1998, pp. 1-9.

8. D. Caswell and P. Debaty, “Creating Web Representations

for Places,” Proc. 2nd Int’l Symp. Handheld and Ubiquitous

August 2001 47

(a) (b) (c)

Figure 4. Websigndisplay transition.The user points the PDA, (a) views a list of websigns,(b) selects one, and(c) sees the associ-ated service.

48 Computer

Computing (HUC2k), Lecture Notes in Computer Science,

vol. 1927, Springer, Bristol, UK, 2000, pp. 114-126.

9. R. Want et al., “Bridging Physical and Virtual Worlds

with Electronic Tags,” Proc. ACM Conf. Human Fac-tors in Computing Systems (CHI 99), ACM Press, New

York, 1999, pp. 370-377.

10. N.B. Priyantha, A. Chakraborty, and H. Balakrishnan, “The

Cricket Location-Support System,” Proc. 6th Ann. Int’lConf. Mobile Computing and Networking (Mobicom 00),

2000; http://nms.lcs.mit.edu/papers/cricket.html.

Salil Pradhan is a research scientist at Hewlett-Packard Laboratories, Palo Alto, Calif., and the tech-nical lead of the websign project. His research interestsinclude ad hoc peer-to-peer networks, location-basedservices, mobile computing, and ubiquitous comput-ing. Pradhan received an MS in computer science fromNortheastern University. Contact him at salil@hpl.hp.com.

Cyril Brignone is a research intern at Hewlett-PackardLaboratories, Palo Alto, Calif. His research interestsinclude human-computer interaction and ubiquitouscomputing. Brignone is currently a master’s student

at Ecole Centrale de Lyon, France. Contact him atCyril.Brignone@ec12001.ec-lyon.fr.

Jun-Hong Cui is a PhD student at the University ofCalifornia, Los Angeles, and worked on the websignproject as part of her internship in summer 2000. Herresearch interests include Internet routing, quality ofservice, mobile computing, and ubiquitous comput-ing. Cui is an IEEE student member. Contact her atjcui@cs.ucla.edu.

Alan McReynolds is an engineer at Hewlett-PackardLaboratories, Palo Alto, Calif. His research interestsinclude very lightweight and wireless personal devices.McReynolds received a BA in computer science fromthe University of California, Berkeley. Contact him atmcreynol@hpl.hp.com.

Mark T. Smith is manager of the Appliance PlatformsDepartment at Hewlett-Packard Laboratories, PaloAlto, Calif. His research interests include future digi-tal media technology and next-generation fixed andmobile communicating information appliances. Smithreceived a PhD in bioengineering from the Universityof Utah. Contact him at msmith@hpl.hp.com.

CareerService Center

• Certification

• Educational Activities

• Career Information

• Career Resources

• Student Activities

• Activities Board

computer.org

Career Service Center

Introducing theIEEE Computer Society

Career Service Center

Advance your careerSearch for jobs Post a resume

List a job opportunityPost your company’s profile

Link to career services

computer.org/careers/