The Implications of Pervasive Computing on Network Designbobbriscoe.net/projects/2020comms/pervimp/pervimp_bttj04.pdf · The Implications of Pervasive Computing on Network Design

The Implications of Pervasive Computing on Network Design

Bob Briscoe<[email protected]>

BT Research,B54/130, Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK

18 Jul 2004

Abstract

This paper concerns concerns the impact that perva-sive computing will have on how we design network-ing. We identify the pressure points where pervasivecomputing will push current approaches to their limits,covering both technical and business implications. Weuse a broad definition of communications technology, toinclude not only infrastructure equipment and services,but also communications facilities within computing de-vices themselves.

We outline progress in redesigning the Internet for per-

vasive computing. We cover components of communi-

cations such as transport, routing and security. But

we also consider how the industry will be arranged;

explaining why new modes of communications (e.g.

publish-subscribe) will become prevalent, where func-

tions will be placed and how their deployment will hap-

pen. We give the rationale behind the most respected

approaches being adopted. We give reasoned, if some-

times controversial, views of what should happen, built

on our own research. We dispel some myths and out-

line the research agenda that still stands between us

and realisation of the vision of pervasive computing.

1 Scope

Mark Weiser’s late 1980s vision of an age of calmtechnology with pervasive computing disappearinginto the fabric of the world [1] has been temperedby an industry-driven vision with more of a feelof conspicuous consumption. In the modified ver-sion, everyone carries around consumer electronicsto provide natural, seamless interactions both withother people and with the information world, par-ticularly for e-commerce, but still through a perva-sive computing fabric.

Based on cost trends, trillions of devices globallyhave been predicted. Using a high-level economicargument we predict that most will be globally con-nected, at least at a rudimentary level. To a casualoutsider, a global network of either form of per-vasive computing would seem to require a major

re-design of the world’s communications systems.However, to a reasonable extent, assumptions madeduring the development of the Internet’s architec-ture took into account the more obvious issues thatpervasive computing would raise. For instance thepacket abstraction allows for brief one-way data-grams which are ideally suited for reporting changesin the physical environment, and IPv6 has suffi-cient address space for perhaps 1018 addresses persquare metre of the earth’s surface1. Also, the In-ternet protocol is deliberately designed to abstractaway from the creation of new link layer technolo-gies (IP over everything), such as those appropriatefor wireless links to battery-powered sensors or de-vices in hostile environments.

However, when one delves a little deeper, prob-lems surface. The Internet architecture had sub-stantially crystallised out just before Weiser’s visionwas articulated. Perhaps as a result, the Internetwas largely built on assumptions of relatively sta-ble, fixed but slightly unreliable connectivity, whereavailability of plentiful mains electricity was neverquestioned. Pervasive computing breaks these as-sumptions, requiring a redesign.

We focus on the more fundamental issues, suchas addressing and routing, progressing to likelychanges to traffic profiles which have implicationson control of congestion and how to assure reliabledelivery. We address security issues throughout.Before drawing the paper to a close with conclu-sions, we consider how the technical changes wehave outlined will affect the business of network-ing and vice versa. But before we start on any ofthe above issues we give a reasoned argument forwhy the prevalent mode of communications for per-vasive computing will be publish-subscribe ratherthan primarily request-reply.

1The IPv6 address space accommodates 3×1038 differentIPv6 addresses. But depending on allocation efficiency [2],this would lead to anything from 1.5 × 103 to 4 × 1018 ad-dresses per square metre of the earth’s surface.

1

mailto:[email protected]

Pervasive Computing & Network Design

2 Architecture

2.1 Conceptual model

No prediction of the impact of pervasive computingon network design can be undertaken without somecharacterisation of likely applications. Other arti-cles survey expected applications [3] including casestudies of its use for care in the community [4],in the home [5] and in the automotive sector [6].The MIT Internet Zero project [7, 8] has builtlights in flexible office spaces containing Internet-connected switches through which they are con-nected to mains power, while touch sensors thatlook like light switches can be programmed to in-struct the actual switches over the Internet in orderto alter their state. Probably the application closestto widespread deployment is the use of identity tagsin the supply chain to replace bar codes, while sen-sors on work tools and materials offer the promiseof automating the recording of daily activity forworkers, particularly in the service industries.

We believe we can abstract all these pervasive com-puting applications into a single conceptual model,which we will use throughout the rest of this pa-per. Pervasive computing devices allow the cre-ation and use of models in information space thatrepresent various aspects of our changing physicalspace. We can create information models that trackchanges in the physical world and conversely ar-range to change the physical world when we modifyour virtual models of it.

As a concrete example, the switch within an Inter-net Zero light socket contains a simple (two state)information model of the light, and touch sensorshold the addresses of the lights they control withintheir connectivity model. When a touch sensor ispressed, it uses its connectivity model to determinewhich light it requests to change its state. In re-ality, the entire world’s Internet Zero lights andtouch sensors are physically connected to the In-ternet. But each connectivity model is a logicalmask programmed into each touch sensor that lim-its its logical connectivity to only a few lights. Theconnectivity model in any touch sensor can itselfbe reprogrammed to allow it to control differentlights (or an Internet hi-fi, for that matter). Forinstance, when a ‘screwdriver’ (in reality an autho-rised ID tag and reader in a screwdriver-like casing)is touched against a light then a touch sensor, itmight reprogramme the touch sensor’s connectivitymodel so that in future it switches that particularlight.

Thus, pervasive computing devices, in their roleas the interface between physical and informationworlds, have two complementary roles:

• to translate the state of the physical world intoinformation (via sensors) and vice versa (actu-ators), collectively termed digital transducers,

• in concert with many other transducers, toshare (i.e. communicate) information aboutthe physical world with other computers in or-der to collectively build more comprehensivemodels of the real world to be used for variouspurposes.

In this paper we focus nearly exclusively on commu-nications driven by sensing the world. A full treat-ment of our subject would include actuators, butwe choose a scope that brought out at least most ofthe major issues, as sensors tend to be more diffuseand the load from them far greater. Wide area tightfeedback loops between the physical and informa-tion worlds would have been even more challengingbut will have to be set aside for future work.

Every sensor creates an information model of thepart of the physical phenomenon it covers, but usu-ally such localised models serve little useful pur-pose alone. Many of these localised models need tobe composed into a more comprehensive model, re-quiring communication from the sensors, then pro-cessing to correlate the parts into a greater whole.This process is illustrated on the left of Fig 1, wherethe visual model is created from multiple photo-graphic scenes.

Also, multiple information models of different as-pects of the same physical thing may be required.For example, referring again to the left of Fig 1,its visual appearance, its thermal properties, itsextent in 3-D space (an edge or vector model),etc. The creation of certain information modelsmight be within the capabilities of the computingpower of the network of sensors themselves. Theway the visual model’s creation is depicted in Fig1 works this way, composing a wide, high resolu-tion 3-D visual scene across a ‘sensor network’ ofsimple devices, each connected to a simple camera.Other models might require more computing powerthan is available within the sensor network. In thiscase sensors (or networks of sensors) would have toreport their findings to ‘co-sensors’ (or co-sensor-networks), which are computational processes run-ning on more powerful computers (or across manycomputers). The figure shows the co-sensor casefor thermal and edge models of the same originalphysical phenomenon.

Parts of each newly created model, may in them-selves recursively form part of a more comprehen-sive information model of reality. The figure showsthe visual model and the edge models being com-bined into a model of the 3-D extent and appear-ance of the original phenomenon. Further, these

2 of 22 c© British Telecommunications plc, 2003-4


phenomenon

assetregister

thermalimaging

edge detection

colourphotography

��

property ofLegoland

��

� � �

visualmodel

edgemodel

thermalmodel

3D assetmodel

Figure 1: Information models of the environment

models may be combined with non-physical infor-mation, such as ownership, value etc, extractedfrom on-line databases, as shown on the right ofthe figure.

Note that there is no implication of some grandplan leading to the ultimate model of everything.Each of the millions of mini-models will be requiredin their own right and each by some different inter-ested party, who may or may not be willing to passon their model to help build other models. Butwe can expect some owners of these models to ex-ploit them both for their own purposes and to sellto others for theirs — retailing and wholesaling re-spectively.

Continuing the example of the Internet Zero lightswitches as an illustration, behind each touch sen-sor might be multiple connectivity models; a de-fault and one for each person who had ever chosento reprogramme the lighting system for their officespace (assuming the touch sensor was arranged toalso detect the identity behind each touch). A fur-ther model correlating all these separate models to-gether could be built, also encompassing a model ofthe presence of individuals built from other sensorinputs. So the office lighting could adapt, trying tosatisfy every occupant, given potentially conflict-ing requirements where some people turned lightson that others turned off.

2.2 Layered connectivity

In the above scenarios, connectivity is implicit.Physical and logical connectivity has been delib-erately arranged so that each stage in the systemcan connect to and be understood by the next stagein the model. It is true that humans will often de-ploy sensor networks for specific purposes and en-sure that their wireless transmissions can all reacheach other, that they are all transmitting on thesame frequencies, with the same codings and withthe same application level languages and formats.However, many applications will include the cre-ation of connectivity as part of the application.And it will be desirable to be able to use exist-ing devices and models to create new applications.So we have to allow devices to find each other andform into networks in the first place.

A classic, well-worn scenario is where an individ-ual walks up to a shop window with her personaldigital assistant (PDA) which connects to a moni-tor in the window to give the individual access tomore screen space. Behind this simple idea lies ahost of problems. There are dozens of radio linkstandards in fashion at any one time (Bluetooth,the WiFi family, etc), using different frequencies ineach region. And hundreds of legacy standards stillin use across thousands of different devices. To findeach other by radio contact, the PDA would have

c© British Telecommunications plc, 2003-4 3 of 22


to scan many frequency ranges and try all com-mon coding, link and message formats (e.g. Jini,SLP, Twine, JESA, etc). The chances of such anapproach leading to reliable seamless connectivity,any time, anywhere, are slim unless only one or twolink standards predominate for all time.

An alternative approach would be to arrange atleast the first stages of connectivity over a networkcommon to any randomly chosen pair of devices,which was the purpose of introducing the Internetprotocol — an intermediary between different linktechnologies (‘IP over everything’). So both thePDA and the monitor use their own link technolo-gies to connect to their respective points of presenceon the Internet. The monitor advertises its locationon a geographical extension of the Web (e.g. geo-graphic mark-up language or SensorML), and thePDA, knowing its own location and coverage, usesa geographical search engine to find suitable moni-tors within range.

Clearly, the indirect approach to connectivity mayalso fail to connect our two devices due to lack ofmutually understood standards at the applicationlevel (e.g. the XML format of the appropriate ge-ographical search responses). However, the directlink approach has the same chances of mismatch atthe application layer on top of the chances of mis-match at the physical, link and transport layers.

A logical model of the physical world has been cre-ated here in order to bootstrap creation of connec-tivity back in the physical world. Once the twodevices have found each other in the informationworld, they can look up whether they have com-patible interfaces in order to initiate a direct link.Failing that, they may have a good enough pathto drive the graphics display through their Internetconnection. Indeed, the monitor in our scenariomay not have had any wireless connectivity at all,only having a fixed link to the Internet. Anotheradvantage of the indirect connectivity approach isthat devices can find each other in logical spaceeven if the radio range of either of them is insuffi-cient or not in line of sight.

A more far-reaching advantage is that logical ob-jects can be placed in a model of the physical worldeven if they aren’t located there in the real world.That is, a form of augmented reality, but within amodel of reality, rather than the real thing (e.g. totest contingencies). If changes to the model werealso able to drive events in the real world, it wouldbe possible to test the response of the real world tosimulated events.

On top of Internet connectivity, a further pre-requisite for bootstrapping physical and logicalconnectivity in pervasive computing applicationslike that above will be comprehensive information

call-backone shot

request-reply

publish-subscribe

clientserver

listenerssource channel

request

reply

subscribe

publishnotify

newsubscribe

time

updates

updates

Figure 2: Communication modes

models of the location of things in the physicalworld [9, 10]. Again, we see the pattern wherewe start with potential connectivity to everything,then logically reduce connectivity to that possiblewithin a confined geographical scope, then furtherreduce connectivity to that required for an applica-tion. Effectively we are creating overlay networksover overlay networks.

2.3 Modes of communications

Asynchronous communications Impressivework has been done compressing common commu-nications protocols into tiny devices. For instanceShrikumar has implemented a Web server and allthe protocols beneath it using 256B of code [11].However, this example highlights a need to care-fully consider what mode of communication is ap-propriate when interfacing with the physical envi-ronment. The Web works in request-reply mode. Aclient asks and the server responds. But this isn’thow we sense the physical world. We don’t askthe grass what colour it is. Photons arrive fromthe grass unsolicited. If we want to know whetherit is dark yet, we don’t keep asking a light sensorwhether it’s dark yet. It is far more efficient toconfigure the sensor to tell us when it’s dark and,importantly, we will find out as soon as it gets dark,rather than the first time we happen to ask after ithas got dark — timely notification of events. Thus,request-reply is appropriate for actuators, but lessso for sensors.2

Thus a more appropriate mode of communicationfor sensors will be based on asynchronous events,a point made by Shrikumar himself about the ap-plicability of his miniature Web server with respectto his earlier work on event notification embeddedin devices [12]. An event should trigger in a sen-sor as its environment3 changes, the magnitude of

2Request-reply has its place when a model is rarely usedand can be stale between times.

3Time being part of a sensor’s environment, which may be



the necessary change determining the sensing gran-ularity. An event notifies a change in the state ofan object, allowing other copies or models of thatobject to update themselves, which in turn mayrequire them to generate further events. Event no-tification requires the publish-subscribe (pub-sub)mode of communications [13] (figure 2), where anobject publishes its potential to generate events toa logical channel, then listeners may subscribe tobe notified when they occur.

In terms of the conceptual model built in the previ-ous section, some information models will need tobe physical-event-driven and continuous, requiringpub-sub feeds into them, while others will be cre-ated to fulfil one specific request, requiring request-reply. So each arrow representing communicationsbetween adjacent models in Fig 1 might involve ei-ther push or pull. However, an event-driven modelcan only receive genuinely timely events if all themodels it depends on are also event-driven4, rightback to the physical phenomenon itself. Whereasa request-reply model will still be valid if it makesa request into a real-time model lower down thechain. Thus, all pervasive computing systemsshould support pub-sub.

A common composition of both request-reply andpub-sub modes is where a pub-sub session is dy-namically created (and eventually torn down) onrequest, with regular responses fed back to the re-questor. This is an example of the call-back modeof communications (figure 2). Later we will dis-cuss an approach called directed diffusion [14] thatworks this way, with a request diffusing througha sensor network to the most appropriate sensorsand regular responses following the same path inreverse to the requestor. We implemented anotheruseful composition termed lookup-and-watch us-ing our generic announcement protocol (GAP [15]),where the initial request gives an immediate reply,but also sets up a call-back session to notify futurechanges, the address of which is also published soothers can join.

Having introduced the main modes of communica-tion relevant to pervasive computing, we single outpub-sub for special attention below, examining twofurther features beyond timely notification that areparticularly relevant to pervasive computing: groupcommunications and no listening at the source.

Before moving on, we should clarify that we donot envisage the pub-sub mode being prevalent formachine-to-human communications, as few peoplewant or need continual interruption (evident fromthe lack of take-up of Web push in the mid-1990s).

used to trigger scheduled reports on the rest of the sensor’senvironment.

4At the same or at a finer granularity.

Humans prefer the hybrid messaging mode wherecommunications are queued until the recipient’s at-tention is ready to turn to them. We only ex-pect pub-sub mode to predominate for machine-to-machine communications.

Group communications Whereas request-replyis inherently point to point, pub-sub’s inherentpoint to multi-point nature allows multiple partiesto maintain the models they need. The underlyingfeeds from the real world may then contribute to aplethora of different views of the world.

But it would be unscalable to expect a sensor toremember a list of everyone interested in its output,because it would have no control over how muchinterest there might be. Also, every device listeningfor sensor events would have to remember to tellthe sensor of any changes to its notification addresswhile it was waiting.

Two approaches solve this problem. One providesa bare logical communication channel where thoseinterested join the channel (e.g. IP multicast [16]).The other simply moves the problem to a proxyservice for the sensor (e.g. the distributed eventmediator service in the Cambridge Event Architec-ture [17]). In either approach, a sensor only hasto remember one channel address and send justone message to it for each event, rather than over-loading already challenged sensors with multiple re-quests.

Under the covers, both approaches are essentiallysimilar. They are both generally implemented asnumerous software objects, which are addressedcollectively as a logical channel. Listeners declaretheir interest to their neighbouring instance of thechannel, which remembers their interest and in turnsubscribes onwards to other instances. When anevent occurs, the source sends it to its neighbour-ing instance of the channel, which distributes it on-wards towards wherever interest has been declared(figure 3).

However, the fundamental difference is that the me-diator provides a bundle of event-related serviceswhile the bare communications channel deliberatelyonly provides dumb forwarding. So a bare channelcould as easily be implemented either as a radiochannel, or as a collection of software subscriptionlists as described above. The bare channel approachis deliberately designed [18] to be complementedby other services such as event archiving and re-covery, but only if required. If recall of previousevents were required, perhaps to help late joinersor those temporarily disconnected, the event medi-ator would provide this service itself, whereas with-out knowing why, the bare channel would simply



forward the information to an archiving node be-cause it had joined the channel in order to providethis service. Other approaches sit at intermediatepoints on this spectrum. For instance, Microsoft’sSCRIBE [19] is a bare channel service, but also of-fers reliable delivery (discussed in §3.5).

Of course, we cannot expect everyone to share theirdata freely. Confidentiality may be required to pro-tect trade, individual privacy [20], or other differ-ences of interest. Again the above two approachesdiffer in how they offer confidentiality. An eventmediator service includes an access control func-tion that acts fully on behalf of the sensor. Thisrequires each listener to give appropriate creden-tials before being allowed to join, while the dumbchannel again leaves confidentiality to another ser-vice. The sensed data would have to be encryptedbefore sending to the channel, while another ser-vice would control access to the decryption key. Soanyone could join the channel, but they would notunderstand it without the key. The merits of eachapproach are discussed in the sections on functionplacement (§2.4) and on security (§3.6).

Announce or listen A further advantage of thepub-sub mode is that the sensor has no need tolisten for requests in ‘server mode’5. Wireless sen-sors would very quickly run down their batteries ifthey had to leave their radio receiver running tolisten for arbitrary incoming requests. It is far lesspower-consuming to leave only the sensing mecha-nism running, ‘listening’ for changes to the physicalenvironment, which can then trigger power up ofthe radio circuitry only to send notification of theevent.

But, when discussing our conceptual model earlier,we emphasised that pervasive computing systemsneed to be able to respond to arbitrary requests aswell as asynchronous notification of events. Doesthis not mean that their radio receivers will haveto remain powered up anyway? The answer lies inseparating event memory from event communica-tion. In order to answer requests for the currenttemperature, or the current state of a touch sen-sor, the sensor itself doesn’t need to remember itsown state. As long as something else (connectedto mains power) receives events from the sensor,it can respond to requests for the sensor’s currentstate between times.

Proving many of the points so far, Shrikumar’s tinyWeb server was soon taken off the Internet, as itsserial link was continually overloaded with requests

5The term server relates to any process able to respond toarbitrary incoming requests, irrespective of whether it runson a large machine often called a ‘server’ or on a tiny sensor.

from curious browsers. Its content is now servedfrom a larger mirror server.

2.4 Function placement

Evolvability A system’s evolvability is highlysensitive to the placement of communications func-tions, which is the chief concern of the Internet’send-to-end design principle [18]. The need forevolvability of today’s communications infrastruc-ture is obvious, given large investment costs requirefuture-proofing. But one may wonder why evolv-ability of pervasive computing devices is a concern,given the growth of pervasive computing is basedon projections of plummeting device costs [1]. Canwe not assume each device is disposable, only everbeing used for the purpose for which it was firstdeployed? The issue here is that the equipment isonly a part of the cost of a new application. Deploy-ment is a major cost consideration, so it is highlydesirable to put devices deployed for one purposeto use for others. For instance, to add a one pennywireless sensor beneath the drum of your washingmachine costs a lot more than remotely reusing theone that is already there.

Open by design, closed by choice In §2.2on layered connectivity we recursively created con-fined connectivity within wider potential connectiv-ity. We argue that the value of global connectivitygreatly outweighs the cost. Metcalfe showed thatthe value of the connectivity of each device riseswith the number of other devices it could poten-tially connect to, making global connectivity highlyvaluable. Whereas the cost of fully standards com-pliant Internet connectivity is about a mere 200Bof code [11]6 plus the running cost of the processingand bandwidth required for the extra header layer(compressible to a byte or so). Devices might notcarry an Internet stack, but instead connect to ahub that does. However, the added complexity ofarranging and managing a hub hardly seems worth-while given the low cost of direct Internet connec-tivity. Therefore economies of volume manufactureare likely to lead to every device design includingan Internet stack, whether or not it is needed forevery application.

Global connectivity is also highly desirable forevolvability, otherwise new uses will be constrainedby locality. For example, initially it may not seemnecessary to give light switches global connectivity,but one day you might appreciate the facility toturn your lights off from your mobile phone while

62.5% of the memory of a Berkeley mote, which is likelyto grow in capacity and shrink in size in line with Moore’sLaw



on holiday. However, more controversially, othersmay be able to remotely control or monitor yourlights. One approach to this privacy problem isto place inherent accessibility limits in the design(e.g. to design a car door lock so it can only beopened within a limited range). But this only lim-its the first hop, which cannot be prevented fromnetworking onward globally. A safer approach is toassume global accessibility might exist, and to closeoff undesirable uses logically rather than physically.To fully stress network design, we take the ‘assumeopen then close’ approach. However, we accept thatdesigners of car security systems and the like willcare more about present security than future evolv-ability. This dilemma is further explored in anotherarticle specifically on privacy [20].

Dumb relays Whether or not the devices them-selves should be evolvable, it is certain that the restof the systems they work with should be. All toooften, principles of evolvable system design are tooreadily set aside in pervasive computing demonstra-tors. Rather than designing for messages from sen-sors to be transmitted to and from any other com-puter in the world, functions are often embedded inthe base-stations that interface between the sensorand the rest of the world, perhaps doing some ad-dress or protocol conversion (e.g. from sensor-localto global). We discuss some cases below where in-telligent base-stations can be justified on principle.But if intelligent relays are necessary to a design,the end-to-end design principle teaches us that it isworth taking a long hard look at alternative designsthat confine intermediate relays to dumb forward-ing.

Ideally, the sensors themselves should be first classInternet citizens. But failing that, the remote end-points they communicate with should supplementtheir limited capabilities, not neighbouring relays(so the fate of a communication depends only onstate and trust shared between the end-points ofthe communication). Tying higher layer functionsto specific instances of equipment operated by spe-cific parties will limit flexibility, especially for newbusiness models.

Power conservation can be a valid reason to relaxthe end-to-end principle, with base-stations takingon additional functions by virtue of their role as thefirst mains-powered node in the path. But this neednot be an excuse to open the flood-gates to morefunctions than necessary. For instance, strong en-cryption is possible on challenged devices (see §3.6),so sensors should encrypt their data for confiden-tiality and the base-station should merely relay theencrypted data to another destination. Functionssuch as re-transmission can be achieved without ac-cess to encryption keys, the goal being to limit ac-

cess to as few parties as possible. For instance itwould be inadvisable to embed an event mediatorservice in the base-station, which decrypted eventsand controlled further access to them itself. Thiswould limit future uses of the system to ones wherethe base-station operator was trusted by everyonewho might want these future uses.

However, it may be more efficient for the sensorsthemselves to behave as intelligent infrastructure(relays) for the nodes around them — multi-hopsensor networks. Taking the sensor network as awhole, it has been proven that combining data ag-gregation with the relay function within each sensorsaves considerable battery power for typical diffusesensing applications [21]. When battery power isparamount relative to evolvability, it seems we haveto compromise and make infrastructure more ap-plication specific — counter to end-to-end designprinciples. We return to this subject in §3.3 onrouting.

3 Component services

So, faced with all the choices above and more tocome below, which course should a wireless sensormanufacturer or network equipment vendor take?Is there a generic design for communications withminiature devices? Which communications ser-vices should service providers be considering? Ofcourse, the detailed answer might depend on thespecifics of the application or the devices requiredfor it. But, the following sections discuss progresstowards defining generic component services so thatas many specific requirements as possible can besatisfied by building applications over these com-ponents.

To kick off the discussion we propose a straw mandesign for the communications systems of a minia-ture device. We believe that a large range of appli-cations could be satisfied by this apparently strangeproposal. We briefly outline the reasoning behindthe proposal, but we do not intend to imply thatany other approach must be inferior in all circum-stances. The architectural discussion above wasnecessarily conducted at a fairly abstract level. Weput up a straw man at this point to deliberatelyforce a change of pace in the paper. As we proceedthrough the following sections, the choices widenfurther for each aspect: routing, addressing, reli-able delivery, congestion control, traffic profiles, se-curity and other ancillary communications services.We hope the straw man will provoke thought whilereading those subsequent sections, and remind thereader that the economies of scale necessary for thepervasive computing vision require device manufac-



turers to commit to a design that will survive alarge production run.

3.1 A straw man proposal

We would recommend a configuration-free devicethat powered up its radio transmitter wheneverit sensed a threshold change to its environment.It could then send a ‘fire-and-forget’ datagram toa hard-coded multicast address7 and immediatelypower down its transmitter. It would also sendheartbeat messages, confirming the previously sentevent at regular intervals8. The device would haveto be one hop from its base-station. It should berelatively tamper-resistant, at least outputting awarning if tampered with, so that it could hold aninternally stored key, which it would use to seed aregularly changing pseudo-random sequence of keysused to encrypt its messages.

Our reasoning for choosing this design is that, al-though a sensor may only be able to perform onesimple function, to bring down its cost of produc-tion, it should be manufactured in volume. So itssingle function will need to be applied in many dif-ferent ways. So the device must be secure to somedegree even though it may not always need to be.And we have deliberately chosen to allow it to bere-purposed pre- and post-deployment but withoutre-configuration, so that the device need have noserver listening for configuration changes, savingbattery power and improving inherent security. Forinstance, proofing it against the sleep deprivationtorture attack [22], which leaves any node that re-sponds to arbitrary requests vulnerable to rapid ex-haustion of its battery.

We have recommended multicast addressing, asotherwise a device hard-coded to send to a uni-cast address is permanently tied to a specific corre-sponding node. Multicast addresses have no topo-logical significance, so the receiver of each messagecan be changed without involving the sender, in-stead only requiring potential receiver(s) to be con-figured to listen. Multicast addresses need only beloosely unique, as a multicast transmission can belocally scoped, to prevent clashes with transmis-sions to the same address. Any receiver could re-multicast with a wider scope if necessary.

The device’s multicast event notifications could belimited to just one receiver, by not revealing theseed key more widely. Or the seed key could bepublished if there were no need for confidentiality.

7Preferably IP multicast, but otherwise a multicastmedium access control (MAC) address, with a different onein each device.

8Slow changes to the interval could be arranged withrepeated advance warnings.

Between these two extremes, time-bounded parts ofthe pseudo-random sequence could be revealed toselected groups [23] by a separate key managementserver.

At least one receiver (perhaps the only authorisedreceiver), could maintain the sensor’s state, actingas its proxy for arbitrary incoming requests, andarchiving events for late joiners. The sensor wouldnot be able to receive acknowledgements for any-thing it sent, so, if a receiver missed a heart-beat,it would need to rely on other receivers for a re-transmission [24] or, if there were no other success-ful deliveries, wait until the next heartbeat.

This straw man proposal is intended to cover a wideset of circumstances, but only where each sensoralone has sufficient radio range to reach a mains-powered communications device. Multi-hop net-works of sensors would not be possible with send-only sensors. Multi-hop sensor networks come uprepeatedly in the rest of this paper, being a ma-jor focus of the research agenda. But that doesn’tmake this straw man proposal irrelevant, given sin-gle hop wireless sensors may turn out to be moreprevalent in practice.

3.2 Unusual link technologies

Given power constraints, communications links topervasive computing leaf nodes often use highlyconstraining technology. Connectivity may be theexception rather than the rule [25, 26], due to line-of-sight issues as much as power conservation. Linkavailability may have to be pre-scheduled or oppor-tunistic. Error rates may be high even when con-nected.

Further, the range of one end-point may be muchgreater than that of the other (typically where oneend is connected to mains power), implying thatoften connectivity will be unidirectional. Nonethe-less, novel technologies have been built to scavengeenergy from communications in one direction, mod-ulating it in order to respond in the other. Radiofrequency identity tags work this way, capturingthe excitation energy in the reader’s radio trans-mission until sufficient energy has been built up torespond by modulating the incoming signal. Mi-croelectromechanical (MEM) fabrication has beenused at UC Berkeley to build corner cube reflec-tors on ‘smart dust’ devices. It is projected thatsmart dust will be small enough to float in air orwater. The reflectors work on the same principleas roadway cat’s eyes, but the angle of one facecan be varied slightly to modulate the reflection ofan incoming optical beam back to its source [27].The team have manufactured a sub-millimetre cube



and achieved 400b/s over 180m with good signal-to-noise ratio [28], while their analysis claims manykb/s are possible over hundreds of metres in brightsunlight.

Such power scavenging technologies seem moresuited to request-reply mode, where a reader base-station requests a reading and the sensor responds.However, smart dust is equipped with hybrid com-munications technology, so that it can hail the base-station with a short burst of radio broadcast. Thebase-station then shines its optical beam in orderto pick up the message the sensor has for it [27],giving the sensor on-demand access to the link forminimal energy cost.

Even with more conventional wireless link tech-nologies, there is considerable scope for improvingpower efficiency by designing medium access [29,30] and transport protocols [31] to minimise energyuse, with only minor compromises in traditionalperformance metrics necessary.

All this novel link technology helps, but doesn’tremove the problem of poor connectivity, whichchanges the rules for designing all the layers builtover it, right up to the application. In our ownindex-based event-messaging system [32], eventualmessage delivery over disconnections is providedby the managed messaging layer on announcersand listeners. Messages are clustered into groupsbased on interest and indexes of the current versionof messages in each cluster are beaconed at regu-lar intervals. As nodes regain connectivity, theirmanaged messaging layer transparently finds whichmessages they have missed and accesses them froman event archive.

3.3 Routing

The task of routing messages through an ad hocnetwork of mobile battery-powered nodes is hardenough when the nodes are allowed large, re-chargeable batteries. A 2003 review of practicalprogress revealed most research was still strongerin theory than practice. Just one implementation(as opposed to simulation) of a routing protocol(AODV [33]) was able to reliably route packets overmore than one hop [34]. These were results from theInternet Engineering Task Force’s (IETF’s) MobileAd Hoc Networks (MANET) working group, whichhas been chartered since 1995/6 to focus on stan-dardising protocols that are near to market.

To realise the vision of pervasive computing, farmore challenging scenarios are envisaged. Routingprotocols have been implemented for large num-bers of tiny, dust-sized devices with very shortrange, where each second of battery use is one sec-ond closer to death. In such scenarios, few nodes

are within range of a gateway giving access towider networks, but collectively a network of sen-sors should be able to relay most nodes’ messagesto a gateway.

Routing hierarchy Routing research for sensornetworks has rightly separated routing within thesensor network from the routing beyond it. Al-though there may be a choice of routes out of thesensor network, it is rarely necessary to consideroptimising routes across both networks at once, asthe sensor network leg is far more resource-critical.However, ensuring that messages destined for thesensor network enter it from the most efficient gate-way requires a model of the sensor network to beheld by routers outside the domain. If routingnodes are relatively powerful (e.g. MANETs beingconsidered by the IETF), it has been argued thatpopular link state routing protocols can be suffi-cient. They can be tuned to allow the combinationof fixed and mobile nodes to work together effec-tively, without too much power and memory con-sumption within the MANET [35].

System-wide energy conservation Routingprotocols are generally designed to be agnosticabout which route cost-metrics to use. So it is rel-atively straightforward to replace traditional hopmetrics with power-aware metrics. Singh et al [36]showed mean time to battery exhaustion for awhole mobile ad hoc network could be considerablyimproved by using such metrics.

Chang et al [37] proved analytically that batterylives across a whole network of fixed but wirelessdevices could be maximised with no need for globalco-ordination, only requiring an algorithm local toeach node that ensured local energy consumptionwas proportional to local energy reserves. However,often the lifetimes of critically placed nodes becomethe determining factor for the lifetime of the wholenetwork (e.g. those close to a base-station).

Application-specific concast In §2.3 we ex-plained the need for pub-sub mode of communi-cations and introduced the requirement for routingevents to multiple parties. However, sensor net-work routing has avoided multicasting, as it is morepower efficient to relay events across sensor nodesto a single gateway rather than duplicating the mes-sage and the power required to transmit it. Fromthere, the multicast model can be offered, with mul-tiple parties subscribing to a logical event channel.

In 2001, researchers at the Internet Sciences In-stitute (ISI) showed that when on-net capacity



host 1

host 2 host 3

source

listeners

duplicate

duplicate

host 4

host 1

host 2 host 3

source

members

relay 1

relay 2

host 4

joinrouting group

multicastforwarding

host 1

host 2 host 3

listener

sources

aggregate

aggregate

host 4

concastforwarding

host 1

host 2 host 3

initiator

potentialsources

install

install

host 4

deployaggregationbehaviour

Figure 3: Multicast and concast group formationand forwarding

(within the sensor network) is critical, it is more ef-ficient to aggregate data from sensors while routingit, rather than sending each reading separately toan off-net reader to be aggregated there [21]. Thisproved the correctness of their seminal earlier workcalled directed diffusion [14].

Directed diffusion was a radical departure. Tra-ditionally routing is based on node addresses, en-suring everywhere in the network maintains routesto any other address so that applications can sendmessages to other nodes by their addresses. In-stead, directed diffusion addressed messages bythe content of the question that required an-swering. And nodes advertised the answers theycould give by the content of the questions theycould answer. Thus, for a sensor reading such as“temperature = 17” the relevant content name is“temperature”. This was the first instance of whatcame to be termed content-addressable networks(CANs).9 However unlike subsequent CANs, di-rected diffusion worked without the benefit of anyunderlying routing. Sensors capable of answering“temperature” questions would advertise this factto their neighbours, who would flood this fact out-wards. Queries about “temperature” could thenbe routed to the correct sensors, leaving behinda trail of ‘bread-crumbs’ so return messages couldbe reverse routed to the original place the queryhad entered the network. While return messageswere relayed across the sensor network, the tem-perature values could be aggregated. For instance,the weighted mean might be calculated before for-warding on the result.

The aggregation functions to use and the routinglogic of each directed diffusion session were highly

9CANs became prevalent the next year for routing inpeer-to-peer overlay networks for file-sharing and related ap-plications.

application specific. As explained earlier, evolv-ability has to be compromised if other factors (e.g.power conservation) are paramount. But then, in2002, researchers from the database community atUC Berkeley generalised the ideas in directed diffu-sion, using common aggregation primitives foundin commercial databases (COUNT, MIN, MAX,SUM, and AVERAGE) [38]. Thus, a more genericrouting capability has been implemented in theTinyOS operating system built for the Berkeleymotes10. It is called TinyDB, given it involves therather unexpected inclusion of database aggrega-tion primitives within a routing protocol.

In fact, generic aggregation functions at mergepoints in a network were recognised as importantoutside the sensor networking field in the late 1990s,appearing in Cisco’s generic router assist (GRA)technology [39] — a generalisation of all concastmodes of communications. In concast, multiplemessages converge, with some combination functionat each merge point (figure 3). In the mid-1990s,concast was recognised as a valid communicationsmode, used primarily when data traversed a mul-ticast tree in reverse, for functions like aggregatingmulticast feedback or merging bandwidth reserva-tions.

We should add that both directed diffusion andTinyDB allow for a time series of responses to aninitial query. In this respect, they use the call-backmode of communications introduced in §2.3, cre-ating a logical pub-sub channel (e.g. on the “tem-perature” topic) in response to a session initiationrequest.

Unusual routing for unusual links Beyonddesigning for challenging power requirements, rout-ing protocols are also having to be re-designed tocope with inconsistent link availability (see §3.2 ear-lier). If sensor nodes are acting as relays in multi-hop networks, but they can only power up inter-mittently, they all have to synchronise to get anyrelaying done.

Also, routing is notoriously difficult with unidirec-tional links (as routing inherently concerns passingadvertisements of downstream connectivity to up-stream nodes). Routing over unidirectional linkshas been solved for the classic example of satel-lite down-links, by creating a tunnelled virtual linkalong a back-channel, through which routing mes-sages can be passed [40]. However, routing overlinks that become unidirectional unpredictably isstill a research issue.

10Generic sensor nodes manufactured by Crossbow.



Routing security If all the above research is-sues were not enough, routing in ad hoc networkspresents numerous further unsolved security chal-lenges. Already authentication of route advertise-ments is a difficult area if there is a high churn ofnetwork operators. It is unrealistic to expect tril-lions of devices to appear in the next decades unlessbillions of networks also appear to connect themtogether, implying extremely rapid appearance ofnew network operators (unless all networking isout-sourced to the few existing operators, whichseems hopelessly optimistic).

In order to validate routing message authentica-tion, any one network must know whom it wouldexpect to receive adverts from. So authenticationof routes through newly appearing networks willrequire trusted third parties to introduce the newplayers. Also, just because a route advertisement isauthenticated, doesn’t mean it is honest [41]. Com-mercial networks have an incentive to understatethe cost metrics of their routes to attract extra cus-tom. So unless the cost of an advertised route canbe objectively tested [42], authentication means lit-tle.

Although problems of authentication are hard, therange of possible attacks on the availability of adhoc networks are even harder to solve. We have al-ready mentioned sleep deprivation torture attackson power constrained nodes. Law et al list arange of further attacks in their excellent introduc-tion to this area [43]: black-holing, flooding, de-tours, loops, worm-holes, hijacking and blackmail-ing. Each node’s finite battery power makes it vul-nerable to any attack that requires it to use its en-ergy before it can determine whether it is beingattacked.

Clearly, if any section of society takes a dislike tocertain wireless devices in their environment, theywill only need to identify one of these vulnerabil-ities to attack them. The send-only sensor in thestraw man proposal above, is a pragmatic way toavoid many of the vulnerabilities, although it is stillsusceptible to physical layer attacks such as channeljamming and the like.

3.4 Naming and addressing

To a casual observer, the size of the required ad-dress space for a computing network should relateto the number of hardware devices in the world.However, if pub-sub communications become pre-dominant, the size of the problem will be deter-mined by the number of software objects that havean audience of other software objects watching forupdates to their state — potentially far more nu-

merous than the trillions of devices on which theysit.

Encapsulation Hierarchy has invariably beenused to ensure addressing schemes can scale. Forinstance, variable names used within a programmeresolve to memory addresses, but the same variablename or memory address used in two programmes(or even two instances of the same programme) aredistinguished by the identity of the process in whichthey run (strictly the identity of the interface to theprocess). Continuing up the hierarchy, processesare identified relative to the interfaces of the ma-chines on which they run. Machines are identifiedrelative to their subnetwork and so on.

Address aggregation However, large distributedprocesses like environment monitoring sit acrossmachines rather than within one machine, invert-ing the ‘normal’ hierarchy11. Sharing the variablesof the process across machines causes the scalingproblem introduced above. Imagine a large set ofsensors also acting as relays for each other. Imag-ine that a subset comprises temperature sensors,which, along with those interested in their read-ings, all hold a common interest in the group-name“temperature”. We explained earlier (§2.3) whythe only practical approach here is for each sensorto send to a logical channel — pub-sub mode —rather than each hold a list of interested listeners.The logical channel is created by the interest ofthe listeners and the combined routing of all therelays. So every relay has to remember the list ofthose logical neighbours to which to forward mes-sages concerning the temperature question. Thislist consumes a small amount of memory on eachrelay.

Another subset of the same sensors may be gath-ering road traffic statistics. So each relay alsohas to set aside memory to route messages for the“road-traffic” group. If there are a large numberof network-wide processes being supported acrossthe sensor network, there could be a routing groupfor each variable in each process — potentially onerouting group for each software object on the net-work. Alternatively, many groups can be combinedinto one, so that some end-points have to filter outmessages they aren’t interested in (a problem famil-iar to people who use e-mail lists). However manygroups there are, each relay will have to store adifferent neighbour list for each group.

Unfortunately, there is no generic way for each relayto aggregate the per-group neighbour lists it holds,so the memory required on each relay grows lin-early with the number of routing groups. Each pair

11Distributed processes will be the norm in the future.



(group-name, neighbour-list) bears little relation toany other pair. Even if numbers are uniquely as-signed to each group, in a numeric order that helpsone node to group its neighbour-lists efficiently, thisorder is unlikely to help any others. In 2001, thisproblem was articulated formally as the ‘channeli-sation problem’ [44], also applying to radio channelallocation. Given we believe pub-sub will be thepredominant mode of communications in pervasivecomputing, the channelisation problem puts inher-ent limits on the economic viability of pervasivecomputing. The designers of directed diffusion andTinyDB have not had to worry about this problem,because current sensor networks are application-specific, requiring only a few routing groups. How-ever, if our conceptual model of pervasive com-puting (§2.1) becomes prevalent on a global scale,the channelisation problem will arise in the (mains-powered) networks connecting together the physi-cal and information worlds. We predict that eventsfrom the physical world will spread out across a webof listeners around the globe, with little correlationby location.

Until recently, only limited group aggregation po-tential was considered feasible on relays [45]. Anaıve solution is to use one coarser logical channelto replace many more granular ones and just expectreceivers to filter out what doesn’t concern them.Some of the filtering burden can be carried by thenetwork, even using commercially available Inter-net routing products. Hop-by-hop filtering can beadded to these products [46] using their support forgeneric concast functions [39] (see §3.3).

Our own solution to this problem takes an end-to-end12 rather than hop-by-hop approach. Our aimwas to solve the address scalability problem, butwithout revealing any more than necessary to in-termediate parties, given messages will often con-tain commercial or private information. There werealso delivery reliability reasons for choosing this ap-proach (see §3.5).

We create routing state for very granular routinggroups on relays but only for the brief time it isneeded to pass a message [32], which at first sightseems to prevent anything being sent. But eachgroup is classified into indexes, clustered togetherwith other groups having similar interest. Changesto indexes are notified to end-points interested inthem using event messaging recursively, and in-dexes may themselves be further indexed. Groupmembers listen to an index or indexes of their choicein order to hear when a message arises for theirgroup. Persistent routing groups only need to beheld open on relays for those index groups with an

12Throughout the paper, the term end-to-end is used inits technical sense to mean “involving only the end-points toprovide the function in question”.

audience. When an event source has a message tosend, it first updates the indexes. Those listeningthen send join requests to their closest relays, creat-ing the group’s routing structure only for the brieftime required. The solution makes memory usagescalable as more groups are required, but has tobe traded off against a need for more messages toco-ordinate the indexes.

Topographical addressing We have alreadybriefly discussed requirements for mapping betweenphysical space and the logical addresses of processeson computing devices (§2.2). In order for two soft-ware objects to establish whether they are close ina modelled co-ordinate space, the most efficient ap-proach is to create further objects to represent eachvolume of space. The model of each space holds theidentifiers of objects placed within it and announceswhenever an object enters or leaves it. Then, anyobject has to monitor the object representing thespace it occupies in order to find other nearby ob-jects, rather than having to continually interrogatethe position of all objects in the world in case anyone of them passes close by.13

Thus we can immediately see a scenario where everyspace (of varying volume) in the physical world isrepresented by an object in the information world,which many other objects that have placed them-selves in that space are continuously monitoring.Just this single proximity application would be suf-ficient to cause the group address aggregation scal-ing problems we have outlined — when trillions ofobjects are watching for changes in trillions of otherobjects. Further, many service providers will main-tain space models requiring co-ordination betweenmultiple models of the same space.

Internetworking beyond the Internet Asnetworks of computing devices are formed, theymay all inherit their networking characteristicsfrom the evolving Internet architecture. However,new independent forms of network may developwithout any overarching architecture common toall the networks. Overlays that work across multi-ple network architectures are perfectly feasible, theInternet itself being the classic example. But feder-ations of different network architectures are fraughtwith problems.

The Plutarch proposal [47] considers what is neces-sary to federate multiple addressing architectures,also making some inroads into wider federation is-sues. But address resolution differences can be con-fined to end-points and clearly identifiable gatewaysbetween architectures (cf. IPv4 to IPv6 gateways).

13Recall that any object might jump to anywhere in cy-berspace.



The hard problems start when federating data han-dling along the whole network path: detecting rout-ing loops or congestion, or controlling priority, ca-pacity reservation or routing. The gain from notusing an Internet-wide architecture would have tooverride the pain suffered dealing with such a widerange of issues.

3.5 Data transport issues

Traffic profiles If computing does become per-vasive one might assume that a majority of trafficflows would consist of just a few packets, with singledatagram flows being common. But we cannot pre-dict whether these bursts would constitute a largeproportion of total traffic volume. In the last half ofthe 1990s, due to the rise in popularity of the Web,flows of a few packets (< 20) constituted the largemajority of the flows (95%) and a sizeable propor-tion of the volume of traffic on the Internet (see,for example, Brownlee & Ma [48]). The rise in thepopularity of peer-to-peer file sharing between 2000and 2004 has seen longer lasting flows take over inprominence. Thus, not only would it be foolish totry to predict the future traffic mix, it would bereckless to design networks and protocols withoutcontingency for a range of scenarios.

Even our intuition about the traffic implicationsof current uses of the Internet can be misguided.Most people imagine multicast is used to streamlong-running sessions. Although this use does in-deed constitute a large volume of multicast traf-fic, a study of nearly four million native multicastflows14 [49] found over 75% consisted of just onepacket. Closer investigation found a large propor-tion of these consisted of co-ordination messages toannounce the existence of other sessions throughvarious multicast indexing tools. The same bi-modal distribution caused by the division in humanbehaviour between managing and doing (whetherwork, social interactions or whatever) is seen in uni-cast traffic [50]. But, past behaviour (mostly fromhuman-attended sessions) is not a reliable guide tothe future traffic mix if unattended sessions cometo predominate.

For instance, we might see huge avalanches of mes-sages firing across the Internet following majorchanges in the real world (road-traffic accidents,battles, security advisories, etc). Network manage-ment event avalanches already create problems thatare hard to quantify until they happen. Once theinformation world is much more tightly coupled tothe real world, the complex chains of dependencybetween messages (that may also get lost during

14Monitored throughout July 2001 on MCI/WorldCom’sbackbone

such events) may become near impossible to designfor.

Congestion control If the large majority of In-ternet traffic volume does turn out to consist oflittle bursts of packets between uncorrelated end-points, current congestion control techniques willbe largely useless. In order to pace its rate, asender should mimic the behaviour of the transmis-sion control protocol (TCP-friendly), which relieson congestion feedback from routers on the path.When a sender starts a new flow, it carefully intro-duces packets to the network, sending two for everyone that gets acknowledged by the receiver, until itsenses congestion. However, brief flows finish longbefore they discover the rate they could have used,because they have to proceed so cautiously.

If the traffic mix is mainly short flows, there may beinsufficient long-running flows to use up the remain-ing network capacity. So there will come a timewhen further increases in network capacity will notbring any benefit. TCP-friendly slow-start algo-rithms will become the limiting factor for networkcapacity. Of course, the contrary approach wouldnot work either; where everyone agrees that TCPshould be allowed to ramp up more aggressively.We could then return to the episodes of persistentcongestion collapse that led to the introduction ofTCP in the 1980s.

Further, in the pervasive computing vision, dis-tributed computations will always be fightingagainst unavoidable propagation delays due to thespeed of light. Already many GRID applicationsuse parallelism extremely judiciously, because themessaging delays between computers are so greatrelative to local delays. TCP’s ‘slow-start’ puts aninherent limit of O(log(n)) on the latency of a shortburst of n packets. Whereas often a whole burstcould have been served in one round trip, but thatcan only be discovered in retrospect.15

The data rate of reality As we have men-tioned, sensor networks can tend to generate eventavalanches. The Anderson project at ColumbiaUni has proposed a novel congestion control mech-anisms, tailored to the particular problems of sen-sor networks [51]. The problem is that traditionalcongestion control only exerts back pressure on thesender’s transmission rate. Herein lie two problems:

• the ultimate sender is the real world — it isobviously not possible to slow the data rate ofreality,

15Our current research solves these ‘slow-start’ problemsby reversing the incentive structures of the Internet’s con-gestion control mechanisms. A publication is in preparation.



• often, there is no backlog of messages at thesender which may have only contributed onemessage — congestion only arises at certainunfortunate relays in the sensor network.

By definition, congestion implies a high probabilityof not being able to service a request due to highutilisation of resources. So, again by definition, if arelay is congested, it will have no spare buffer spaceup its sleeve. So, once a relay is congested, it hasvery little room for manoeuvre, given all the datahas probably already left the sources that causedthe congestion. All that can be done is to askupstream relays to hold back data, and sources tobuffer any new data arriving ‘from reality’. Clearlythough, as events continue to unfold in the realworld, if congestion persists there will come a pointwhere data has to be dropped.

We should emphasise that some messages, no mat-ter how tiny, might carry very important informa-tion. But the importance will rarely be understoodby the sensor or relay — often it will only be pos-sible to establish how important a message is onceits meaning has been extracted by the receiver.16

As with the quality of service question in publicnetworks, the dilemma lies between adding capac-ity (which will rarely be sufficient in all circum-stances) and introducing complex prioritisation ormulti-path routing schemes. Both increase the sizeand cost of the devices, just to provide cover againstunlikely eventualities, which may never happen17.But catastrophes are exactly the time when reliabledata is most required.

As messages cross the Internet at large, these prob-lems can be ignored if the ‘data rate from real-ity’ is dwarfed by the data rate between entitiesin the information world. The latter is more elas-tic, so it can hold back to allow for fluctuations andavalanches of data from reality.

Delivery reliability Having introduced the pos-sibility of dropping messages (whether as a resultof congestion or wireless channel fade), this leadsus directly into a further challenge to conventionalthinking: how does a receiver know a message hasbeen lost when it wasn’t expecting it anyway?

Usually a receiver can detect a missing messagewhen a sequence of packets stops arriving, or thenext in the sequence arrives revealing a gap. Asyn-chronous events are not expected by definition. So

16In the physical world, this problem is solved by trans-mitting information in analogue form. For instance, an arbi-trarily large volume of information can pass through the lensof the eye and the retina, in order to be prioritised duringprocessing by the brain.

17Aggregation of data within a sensor network (§3.3)might alleviate most potential congestion problems.

the receiver can only detect a loss when the nextevent arrives, which may be anything from mi-croseconds to years later. If using positive acknowl-edgement (ack) this is not a problem, because thesender can detect a lack of ack, and re-send. But ifa large number of listeners want to be informed ofeach event, the source can be overwhelmed by whatis termed an ‘ack implosion’. Therefore, for scala-bility, the pub-sub model is deliberately arrangedto hide the comings and goings of listeners from thesource. So how can the source know how many lis-teners are interested, and therefore how many acksit should have received?

Negative acknowledgement (nack), where receiversonly complain if they miss a message, is preferredin multicast streaming scenarios. So nacks can beaggregated on their way to the source if more thanone receiver misses a message [52] (see also §3.3).This still leaves the above problems where no-onecan nack a missed message that they weren’t ex-pecting.

Our own index-based event messaging system (in-troduced in §§3.2 & §3.4 in the context of inter-mittent links and address aggregation) was also de-signed to solve this problem. Because its indexesbeacon regularly, it is clear when one is missed.And the indexes list the version number of the lat-est message on each message channel. So receiverscan nack a missed message, even being able to catchup if they have been disconnected for some time.

Hop-by-hop ack or nack handling can be used forreliable delivery. Cisco’s pragmatic general multi-cast aggregates nacks [46], while SCRIBE [19] usesthe acks of a long-running TCP session betweeneach intermediate system. However, an early in-sight during the design of the Internet was that hop-by-hop acknowledgement didn’t remove the needfor end-to-end acknowledgement (e.g. during re-routing or router failures) [18]. The situation is nodifferent for asynchronous events. We have to checkdelivery end-to-end, so hop by hop is redundant,hence justifying our choice of beaconing indexes.

The above concerns reliable multicast deliveryacross global networks, originating from a sensorjust one hop from mains power as in our straw manproposal (§3.1). When messages arise in a multi -hop sensor network, we have already (§3.3) rec-ommended avoiding duplication of power consump-tion, aggregating with concast, rather than dupli-cating with multicast until a node with mains poweris reached. How reliability mechanisms should mostefficiently span the two parts of the message trans-port in these cases is a matter for further research.



3.6 Security

All distributed applications require some degree oftrust between the devices comprising the system.Elsewhere, Seleznyov et al discuss an approach toallow pervasive devices to determine whether theyhold sufficient trust in their correspondents for therisk associated with the action in hand [53]. Suchsystems require rudimentary primitives for securecommunications.

Pervasive placement of computers in the environ-ment breaks many traditional communications se-curity assumptions. Most importantly, storage ofkeys on a device assumes the device is physically se-cured against those who don’t know the key, whichis not the case for many sensor networking applica-tions spread liberally throughout the environment.

Verifiable location However, many other ap-plications of pervasive computing involve deviceswithin business or residential premises. Recent re-search at UC Berkeley has introduced a techniqueto establish whether a device is located where itclaims to be [54], although a trusted node closeto the device is a prerequisite. Previous tech-niques without that assumption were far more com-plex [55]. If it can be established that a device iswithin, rather than outside, a physically securedbuilding, immediately more trust can be placed inmessages from that device. Also, it may be possibleto authenticate that a device is what it says it is,because it is located where it is meant to be.

Tamper-resistance and challenged hardwareIf security-sensitive devices must be subject togeneral access, it may be sufficient to use mildlytamper-resistant casings (as in our straw man pro-posal in §3.1), as long as the limitations are un-derstood [56]. The sheer numbers of devices canbe used to offer sufficient protection by designingthe whole system to be resistant to compromise ofa minority of devices. SPINS [57] is an exampleof this approach, which has been implemented onBerkeley motes. It consists of two message securityprimitives: SNEP for confidentiality and µTESLAfor message authenticity and integrity. Both aredesigned to provide strong protection despite ex-tremely limited hardware, ruling out asymmetriccryptography. µTESLA18 derives the asymmetryneeded for authentication from the one-way pas-sage of time, rather than modular arithmetic. InSPINS, these primitives are built up into a secure

18µTESLA is based on TESLA, our own joint work withColumbia Uni, UC Berkeley and IBM for lightweight, per-packet authentication of broadcast multimedia streams. Itis currently in the process of standardisation through theIETF [58].

sensor network system bootstrapped from an asso-ciation with a base-station.

Key management Public key (asymmetric)cryptography requires considerable computing re-sources, so it is considered infeasible on miniaturedevices for the foreseeable future. Even on high-speed computers, asymmetric keys tend to only beused to bootstrap lighter weight symmetric cryp-tography by exchange of a symmetric key. Withoutthe ability to use public keys, it is hard to boot-strap a secure system of miniature devices by au-thenticating that the source of the initial keys istrusted. This is why SPINS (above) cannot boot-strap its authentication with any trusted identity,being limited to having to trust the base-stationowner, which it authenticates by locality.

Stajano and Anderson [22] propose that a usefulkey establishment primitive for miniature deviceswould be physical touch. That is, a master key canbe established in a device when it is placed in con-tact with a mother device. This key cannot thenbe overridden by the touch of another device. Onlythe original mother can release the device from itsmother’s binding, after which it can be bound tothe first new mother that touches it. The relianceon touch can be relaxed to include proximity [59].Chan et al [60] establishes keys by giving each of aset of sensors a different subset of a large set of ran-dom keys prior to deployment. It uses the increasedprobability of any two nodes sharing common keysto bootstrap key establishment.

Once initial keys are established, key managementprocedures must be used to refresh the keys actu-ally employed for message cryptography [61], re-ducing the time attackers have to guess the keys inuse by brute-force methods (as in our straw manproposal in §3.1). However, when broadcasting se-crets to a constrained group, traditional key man-agement techniques developed for one-to-one com-munications cannot be used, because the authorisedmembership of the group may change over time.

One approach is to assume the presence of a sta-ble set of trusted event mediator nodes (see §2.3).Then messages are sent to these mediators andgroup members form a one-to-one security asso-ciation with any one of these mediators. How-ever, trust in stable intermediaries is neither genericnor necessary in pervasive computing scenarios (oracross the Internet at large). A preferred approachis for the message to be encrypted with a groupkey (using that classic oxymoron, the secret sharedover a large group) at source, and remain encryptedthroughout its end-to-end journey, at least avoid-ing sharing the key unnecessarily with intermediatenodes. As end-points join and leave the group, the



group key is changed. Moyer et al provides a use-ful overview of the issues in group key managementand a survey of solutions at the time [62].

3.7 Ancillary communications ser-vices

Throughout the paper so far, we have kept ourfocus on the rudimentary functions necessary forcommunications to realise a pervasive computingvision. Beyond these, a richer set of ancillary com-munications services may be necessary for eachspecific application: search and discovery, groupforming, session co-ordination, certification, trans-actional messaging, causal message ordering, andso on.

There are two schools of thought on how to achieveall but the most rudimentary function of forwardingand routing:

bundled — functions embedded within routersand relays throughout the messaging network(e.g. the event mediation service19),

unbundled — communications services sepa-rately provided by third parties (e.g. eventarchives) or by the joint efforts of peer end-points (e.g. authentication and confidential-ity).

Both approaches are distributed, they merely differin whether the act of relaying is unavoidably bun-dled with other functions or not. In the unbundledapproach, relays act as common carriers, irrespec-tive of the messages being passed.

Our instincts are to always try to design unbundledfunctions (which can then optionally be collocatedwith the relaying function). But each case mustbe taken on its merits, and reasoned justificationsgiven, rather than following the end-to-end designprinciple as a religion. We have given these rea-soned arguments throughout.

But once we move from rudimentary to higher levelfunctions as listed above, there is no question thatthey are best designed so that they can be separatedfrom the basic networking service. In this respect,they have less impact on network design, justifyingruling their detailed discussion out of this paper’sscope.

19Which may itself be an overlay network built on morerudimentary primitives, but it consists of message relaysitself.

4 Business implications

Trends Over the last couple of decades asyn-chronous programming has become prevalent, atleast for non-networked code local to the machine’sown bus (e.g. an event listener is set for a mouseclick event and, when it triggers, the code checkswhere the mouse pointer is and calls the relevantfunction). This trend will extend to distributedprogramming, though initially through the use ofintermediary message servers rather than directpeer-to-peer remote procedure calls. As comput-ing becomes more interfaced to the wider physi-cal world, we can expect distributed asynchronousprogramming to become commonplace. Crowcroftenvisages 1010 event messages per second world-wide [46]. We have already explained that, if weexpect trillions of devices, there will be orders ofmagnitude more event sources and listeners (§3.4).

This warns us that the potential growth of perva-sive computing will be dependent on the successfuldeployment of the pub-sub mode of group commu-nications, whether directly in the network infras-tructure (e.g. as IP multicast [16]) or using over-lays [19, 63].

The value of group forming Metcalfe’s Lawpredicts that the value of a network is O(n2), be-cause each of n users has the potential to commu-nicate with n− 1 other users. Reed’s Law goes be-yond this, pointing out that n users20 have the po-tential to create 2n different groups between them-selves [64], making the value of a network that sup-ports formation of groups rise exponentially O(2n).Although neither law is intended to be a guide toprediction of actual market size, they give a feel forwhat shape the market growth curve should takein each case. They certainly show that a businessthat allows unfettered creation of groups (‘YahooGroups for machines’) will tend to be popular. Ifgrowth in computing device numbers remains ex-ponential (the predicted doubling time is about 0.6years), then growth in group numbers will be dou-bly exponential, that is O(22t

). Or put anotherway, if we are to create thousands of trillions ofgroups by 2020, world-wide group creation facilitieswill have to have been capable of creating millionsof groups every second.

Whose business? Which customer? If de-vices are spread throughout the fabric of our lives,in shared office blocks, in industrial units, in publicplaces and in private dwellings, up to a point, net-works of devices will be able to act as their own in-

20Or processes?



frastructure. But part of the capacity of global net-working infrastructure and all the capacity of ancil-lary services dedicated to asynchronous messagingwill also be required. Why would anyone invest inthis infrastructure? For the public good? For pri-vate gain? What socio-economic mechanisms willcause these prerequisites of the pervasive comput-ing vision to happen?21

Because the impact of each device is so small, thequestion of who is responsible for its share of in-frastructure becomes blurred. Many assume thatinfrastructure operators will cover their costs bycross-subsidising infrastructure from higher levelservices. But it is unrealistic to expect any com-pany to be successful enough at these very differentbusinesses for one to sustain the other, given com-petition from specialists in services for pervasivecomputing. So, if a washing machine detects newfabrics in its wash-load and looks up their washinginstructions over the Internet, who should arrangefor the required infrastructure and its maintenance?The manufacturer? the retailer? the householder?Who should pay for the service engineer to comeout to a faulty washing machine only to discoverthe fault is due to the householder not paying theirInternet bill? If sensor A is measuring light levelsfor one application, but also relaying for sensor B,they may both need global connectivity, but shouldrelay A charge sensor B for its services?

Clearly, there will be many informal acts of giveand take over what will often be trivial issues. Butmany tiny acts of take without any give mountup. Solutions to these free-rider problems must befound if the vision of pervasive computing is to berealised.22

Pricing Assuming someone (probably not theend-user) will take responsibility for paying the billsfor the communications infrastructure necessary tosupport pervasive computing, how will it be priced?The casual observer would expect event messagingservices to be flat charged (irrespective of usage).Usage charging23 would incentivise responsible useof resources, but we have seen that miniature de-vices already have good reason to be parsimonious,particularly to conserve battery power.

Our intuition is that flat charging will prevail wher-ever pervasive computing is ‘scavenging’ resourcesprovided for other purposes (e.g. the wider Inter-net). But where messaging services are provided

21The wider question of who will have the incentive toinvest in deployment of the devices themselves is just asvalid, but outside the scope of this paper.

22See http://www.mmapps.org/ for our collaborative re-search on motivations in peer-to-peer communities.

23In bulk — it goes without saying that itemisation is outof the question.

specifically, the potential sheer volume of messagingwill tend to force the introduction of usage charg-ing.

We have also explained that many applications willbe part of vital business processes, their communi-cations requiring priority over more optional mes-sages during surges in demand. Clearly, priorityservice will attract premium charging. Given pri-ority will rarely have to be exercised, premiums areunlikely to be levied only when priority is needed(usage). Rather they will be paid regularly in ad-vance for the right to priority as a contingency(flat).

Pub-sub business model Traditionally, multi-cast has been associated with efficient distributionof streamed media, but it is also suitable for thetimely delivery of asynchronous events. The ses-sions are just considerably shorter. One of thereasons pub-sub has not been widely deployed formedia distribution is the desire to re-create con-tent distribution business models over it that mimicthose used today, by both the content and the net-work industry. Specifically, they expect the dis-tribution network to charge the sender proportion-ately to the number of receivers.

Therefore, the full potential of pervasive computingwill not be realised unless we can establish a viableseparation between the business models for mediadistribution and for event notification. It is clearlynot feasible to charge for event notification mes-saging per session (i.e. per event), but, if pub-subwere charged flat rate, it would be hard to preventthe same mechanisms being used to bypass mediadistribution pricing.

To bundle or to unbundle? When we dis-cussed function placement (§2.4), we recommendedthat functions should not be assigned to specificequipment. Rather, we advised that the systemshould be designed open. Then, it is still perfectlypossible to bundle functions together into a pieceof equipment (e.g. if a vendor believes the businessmodel is advantageous). But bundling is chosen,not inherent to the technical design.

Throughout, we have shown that there are rarelytechnical reasons to lock in even rudimentary com-munications services with the business of operatinga dumb pub-sub network.24 But, despite having noinherent lock-in, we can predict that messaging ser-vices will make good business for network operatorsin the next few years. However, as the pervasivecomputing scenario develops, we predict that all, or

24Message aggregation and duplication — concast andmulticast — being exceptions.


http://www.mmapps.org/


at least most of these services will be self-providedmore competitively by distributed software acrossthe pervasive computing base. Therefore the tech-nology should be designed for this transition fromclosed to open from the outset [65], justifying ourintuition of an open design closed by policy choice.

5 Conclusions

We have given controversial but reasoned explana-tions for why most pervasive computing will largelybe connected globally and for why it will rely heav-ily on models of the physical world within the in-formation world. It is infeasible to imagine thatany arbitrary pair of computing devices will be ableto talk directly to each other, just because theyare in physical proximity. Instead physical deviceswill be bound to information models of themselves,which will meet in cyberspace, communications be-tween devices taking place across cyberspace, as of-ten as by direct wireless connectivity. Continuousco-ordination between the physical and informationworlds will lead to a web of tens of billions of mes-sages per second across the world’s networks.

We have explained why we predict that asyn-chronous event messaging using publish-subscribewill be the predominant mode of communicationsfor pervasive computing. Pub-sub will mostly bebased on the multicast mode (whether native oroverlay), once messages from the physical worldhave hit the first gateway to the rest of the Inter-net (the first connection to mains power). But, ifthere is a multi-hop wireless network between thephysical world and that first gateway, in order toconserve power, concast will be the most likely com-munications mode up to that gateway.

We have questioned the assumption that tiny cheapcomputing devices will be considered disposableand application-specific. Economies of scale in vol-ume device manufacturing will always favour reuseof the investment in generic device designs, whethereach unit is disposable or not. Also, the invest-ment in deploying devices will be higher than theircost, tending to encourage new ways to combinedeployed devices to novel ends. Therefore workingout the most generic communications facilities forminiature devices is a central part of the researchagenda.

Having set out the grand challenge, we have sur-veyed its implications on each rudimentary elementof communications: routing, addressing, congestioncontrol, reliable delivery, security, etc. We have de-scribed the problems precisely and the various mainapproaches being adopted by the research commu-nity to solve them, giving rationale. We have ex-ploded some myths particularly explaining why it

is often more effective and less complex to createan x-like system from un-x-like parts (e.g. a reli-able system from unreliable parts, or a secure sys-tem from insecure parts). We have also correctedsome misunderstandings that the research commu-nity seems to have carried over from their previousresearch areas. For instance, it is fruitless to try tocontrol congestion by varying the data rate of re-ality and it is fruitless to expect receivers to knowwhen they have missed an asynchronous message,which by definition they weren’t expecting anyway.

Finally, we have introduced the implications ofpervasive computing on the business of commu-nications, explaining the trouble the commercialcommunity has with the pub-sub model and em-phasising the importance of group creation ser-vices. Many open questions remain, particularlyconcerning how to promote investment in pervasivecomputing infrastructure, given the benefits are sothinly spread, making collection of return on in-vestment costly, even with flat pricing models. Wehave explained why ‘open by design but closed bypolicy choice’ will still be the appropriate commer-cial approach, given communications designs willstill need to be generic, even though the devices onwhich they are implemented will be disposable.

Acknowledgements

Jon Crowcroft (Cambridge Uni), Jane Tateson,Trevor Burbridge, Andrea Soppera, Alan Steven-ton (BT Research) and the anonymous reviewers.



References

[1] Weiser M: ‘The computer for the 21st Century’, Scientific American, 265, No 3, pp 94–104 (September 1991)

[2] Durand A, Huitema C: ‘The host-density ratio for address assignment efficiency: An update on the H ratio’,Request for comments 3194, Internet Engineering Task Force, URL: rfc3194.txt (November 2001)

[3] Bulman J, Crabtree B, Gower A, Oldroyd A, Lawson M, Stutton J: ‘Mixed reality applications in urbanenvironments’, BT Technology Journal, 22, No 3 (July 2004)

[4] Brown S, Garner P, Sixsmith A, Hine N: ‘Care in the community’, BT Technology Journal, 22, No 3 (July2004)

[5] Bull P, Payne R: ‘Pervasive home environments’, BT Technology Journal, 22, No 3 (July 2004)

[6] Bilchev G: ‘Traffimatics — A pervasive view of co-operative vehicle highway systems’, BT TechnologyJournal, 22, No 3 (July 2004)

[7] Gershenfeld N, Krikorian R: ‘Building intelligence’. Web page URL: http://www.media.mit.edu/physics/projects/IP/bldg/bi/ (June 2002) Briefing note.

[8] Krikorian R: ‘Internet 0; Bringing IP to the leaf node’. URL: http://www.bitwaste.com/wasted-bits/blog/conferences/et2003/I0-oreilly.pdf (April 2003) (Presentation).

[9] Yokoji S, Takahashi K, Miura N: ‘Kokono search: A location based search engine’,In: Proc. Tenth International World Wide Web Conference (WWW10), (May 2001) URL:http://www10.org/cdrom/posters/contents.html#a5 (Poster).

[10] Buyukkokten O, Cho J, Garcia-Molina H, Gravano L, Shivakumar N: ‘Exploiting geographical locationinformation of web pages’, In: (Informal) Proc. Workshop on Web Databases (WebDB’99), ACM (June1999) URL: http://citeseer.ist.psu.edu/buyukkokten99exploiting.html

[11] Shrikumar H: ‘IPic - A match head sized Web-server’. Web page URL: http://www-ccs.cs.umass.edu/shri/iPic.html (October 2002)

[12] Shrikumar H: ‘Connecting absolutely everything’, White Paper WP010308, Ipsil, URL: http://www.ipsil.com/resources/whitepapers/connecting.pdf (2001)

[13] Oki B, Pfluegl M, Siegel A, Skeen D: ‘The Information Bus; an architecture for extensible distributedsystems’, In: Proc. 14th ACM Symposium on Operating Systems Principles, (1993) URL: http://www.cs.utah.edu/~retrac/cs7460/infobus.pdf

[14] Intanagonwiwat C, Govindan R, Estrin D: ‘Directed diffusion: A scalable and ro-bust communication paradigm for sensor networks’, In: Proc. ACM International Con-ference on Mobile Computing and Networks (MobiCOM’00), ACM (August 2000) URL:http://www.isi.edu/scadds/projects/diffusion.html#publications

[15] Soppera A, Burbridge T, Briscoe B, Rizzo M: ‘GAP: The generic announcement protocol for event mes-saging’, In: Proc. London Communication Symposium (LCS’03), UCL (September 2003) URL: http:

//www.ee.ucl.ac.uk/lcs/papers2003/103.pdf

[16] Deering S E: ‘Multicast routing in internetworks and extended LANs’, In: Proc. ACM SIGCOMM’88.(August 1988)

[17] Bacon J, Moody K, Bates J, Hayton R, Ma C, McNeil A, Seidel O, Spiteri M: ‘Genericsupport for distributed applications’, IEEE Computer, pp 68–76 (March 2000) URL:http://www.cl.cam.ac.uk/Research/SRG/opera/publications/pre-2002.html#2000

[18] Saltzer J H, Reed D P, Clark D D: ‘End-to-end arguments in system design’, ACM Transactions on ComputerSystems, 2, No 4, pp 277–288 (November 1984) URL: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf An earlier version appeared in the Second International Conference on DistributedComputing Systems (April, 1981) pages 509–512.

[19] Rowstron A, Kermarrec A M, Castro M, Druschel P: ‘SCRIBE: The design of a large-scale event notificationinfrastructure’, In Crowcroft J, Hofmann M, eds.: Proc. 3rd International COST264 Workshop on NetworkedGroup Communication (NGC’01). Volume 2233 of LNCS., Springer LNCS pp 30–43 (November 2001) URL:http://link.springer.de/link/service/series/0558/bibs/2233/22330030.htm

[20] Soppera A, Burbridge T: ‘Maintaining privacy in pervasive computing’, BT Technology Journal, 22, No 3(July 2004)

[21] Heidemann J, Silva F, Intanagonwiwat C, Govindan R, Estrin D, Ganesan D: ‘Building efficient wirelesssensor networks with low-level naming’, In: Proc. Symposium on Operating Systems Principles, ACM pp146–159 (October 2001) URL: http://www.isi.edu/~johnh/PAPERS/Heidemann01c.html

[22] Stajano F, Anderson R: ‘The resurrecting duckling: Security issues for ad-hoc wireless networks’, InChristianson B, Crispo B, Roe M, eds.: LNCS 1796, Proc. 7th International Workshop on Security Protocols,Springer Verlag pp 172–194 (April 1999) URL: http://citeseer.ist.psu.edu/227971.html


http://www.ietf.org/rfc/rfc3194.txt

http://www.media.mit.edu/physics/projects/IP/bldg/bi/

http://www.media.mit.edu/physics/projects/IP/bldg/bi/

http://www.bitwaste.com/wasted-bits/blog/conferences/et2003/I0-oreilly.pdf

http://www.bitwaste.com/wasted-bits/blog/conferences/et2003/I0-oreilly.pdf

http://www10.org/cdrom/posters/contents.html#a5

http://citeseer.ist.psu.edu/buyukkokten99exploiting.html

http://www-ccs.cs.umass.edu/shri/iPic.html

http://www-ccs.cs.umass.edu/shri/iPic.html

http://www.ipsil.com/resources/whitepapers/connecting.pdf

http://www.ipsil.com/resources/whitepapers/connecting.pdf

http://www.cs.utah.edu/~retrac/cs7460/infobus.pdf

http://www.cs.utah.edu/~retrac/cs7460/infobus.pdf

http://www.isi.edu/scadds/projects/diffusion.html#publications

http://www.ee.ucl.ac.uk/lcs/papers2003/103.pdf

http://www.ee.ucl.ac.uk/lcs/papers2003/103.pdf

http://www.cl.cam.ac.uk/Research/SRG/opera/publications/pre-2002.html#2000

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

http://link.springer.de/link/service/series/0558/bibs/2233/22330030.htm

http://www.isi.edu/~johnh/PAPERS/Heidemann01c.html

http://citeseer.ist.psu.edu/227971.html


[23] Briscoe B: ‘MARKS: Zero side effect multicast key management using arbitrarily revealed key sequences’, In:LNCS 1736, Proc. 1st International COST264 Workshop on Networked Group Communication (NGC’99),Springer (November 1999) URL: http://www.btexact.com/publications/papers?doc=70250

[24] Floyd S, Jacobson V, Liu C G, McCanne S, Zhang L: ‘A reliable multicast framework for light-weight sessionsand application level framing’, Proc. ACM SIGCOMM’95, Computer Communication Review, 25, No 4, pp342–356 (October 1995) URL: http://www.acm.org/sigcomm/ccr/archive/1995/conf/floyd.html

[25] Fall K: ‘Delay tolerant networking research group’, Working group charter, Internet Research Task Force,URL: http://www.dtnrg.org/ (2002) (Continuously updated).

[26] Fall K: ‘A delay-tolerant network architecture for challenged internets’, Proc. ACM SIGCOMM’03, Com-puter Communication Review, 33, No 4, pp 27–34 (October 2003) URL: http://portal.acm.org/citation.cfm?id=863960&dl=ACM&coll=portal

[27] Kahn J M, Katz R H, Pister K S: ‘Emerging challenges: Mobile networking for ‘smart dust”, Journal ofCommunications and Networks, 2, No 3, pp 188–196 (September 2000) URL: http://citeseer.ist.psu.edu/kahn00emerging.html

[28] Zhou L, Kahn J M, Pister K S: ‘Corner-cube retroreflectors based on structure-assisted assembly for free-space optical communication’, IEEE Journal of Microelectromechanical Systems, 12, No 3, pp 233–242 (June2003) URL: http://www-ee.stanford.edu/~jmk/pubs/ccr.jmems.pdf

[29] Chlamtac I, Petrioli C, Redi J: ‘Energy conservation in access protocols for mobile computing and commu-nication’, Microprocessors and Microsystems Journal, 1, pp 20–32 (March 1998)

[30] Chockalingam A, Zorzi M: ‘Energy efficiency of media access protocols for mobile data networks’, IEEETransactions on Communications, 46, No 11, pp 1418–1421 (November 1998) URL: http://citeseer.nj.nec.com/259740.html

[31] Kravets R, Krishnan P: ‘Application-driven power management for mobile communication’, Wireless Net-works, 6, pp 263–277 (2000) URL: http://citeseer.nj.nec.com/kravets98applicationdriven.html

[32] Soppera A, Burbridge T, Nekovee M: ‘Index-based event messaging’, In: Proc. International Workshopon Large-Scale Group Communication, (October 2003) URL: http://srds2003.cnuce.cnr.it/papers/

soppera.pdf

[33] Perkins C, Belding-Royer E, Das S: ‘Ad hoc on-demand distance vector (AODV) routing’, Request forcomments 3561, Internet Engineering Task Force, URL: http://www.tcs.hut.fi/~anttit/manet/aodv/

(July 2003) (Experimental).

[34] Tschudin C, Lundgren H, Nordstrom E: ‘Embedding MANETs in the real world’, In: Proc. Conferenceon Personal Wireless Communications (TWC’03), IFIP (September 2003) URL: http://www.it.uu.se/

research/group/core/publications.php?pub_id=41

[35] Baker F: ‘An outsider’s view of MANET’, Internet Draft draft-baker-manet-review-01, Internet EngineeringTask Force, URL: http://bgp.potaroo.net/ietf/old-ids/draft-baker-manet-review-01.txt (March2002) (Expired).

[36] Singh S, Woo M, Raghavendra C S: ‘Power-aware routing in mobile ad hoc networks’, Proc. ACM In-ternational Conference on Mobile Computing and Networks (MobiCOM’98), pp 181–190 (1998) URL:citeseer.nj.nec.com/singh98poweraware.html

[37] Chang J H, Tassiulas L: ‘Energy conserving routing in wireless ad-hoc networks’, In: Proc. IEEE Conferenceon Computer Communications, pp 22–31 (2000) URL: http://citeseer.nj.nec.com/chang00energy.html

[38] Madden S R, Szewczyk R, Franklin M J, Culler D: ‘Supporting aggregate queries over ad-hoc wirelesssensor networks’, In: Proc. Workshop on Mobile Computing and Systems Applications, (2002) URL: http://www.cs.berkeley.edu/~madden/madden_aggregation.pdf

[39] Cain B, Speakman T, Towsley D: ‘Generic router assist (GRA) building block; motivation and archi-tecture’, Internet draft, Internet Engineering Task Force, URL: http://bgp.potaroo.net/ietf/old-ids/draft-ietf-rmt-gra-arch-01.txt (March 2000) (Expired Sep 2000) (also invited talk at NGC’99).

[40] Duros E, Dabbous W, Izumiyama H, Fujii N, Zhang Y: ‘A link-layer tunneling mechanism for unidirectionallinks’, Request for comments 3077, Internet Engineering Task Force, URL: rfc3077.txt (March 2001)

[41] Perlman R: ‘Network layer protocols with byzantine robustness’, Technical Report 429, MIT, URL: http://www.lcs.mit.edu/publications/specpub.php?id=997 (October 1988) (Based on PhD thesis).

[42] Zhu D, Gritter M, Cheriton D R: ‘Feedback based routing’, Computer Communication Review, 33, No 1,pp 71–76 (January 2003) URL: http://portal.acm.org/citation.cfm?id=774774&dl=ACM&coll=portal

[43] Law Y, Dulman S, Etalle S, Havinga P: ‘Assessing security-critical energy-efficient sensor networks’, InGritzalis D, Vimercati S D C D, Samarati P, Katsikas S, eds.: Proc. 18th TC11 Int. Conf. On Informa-tion Security, IFIP, Kluwer pp 459–463 (May 2003) URL: http://www.ub.utwente.nl/webdocs/ctit/1/00000087.pdf


http://www.btexact.com/publications/papers?doc=70250

http://www.acm.org/sigcomm/ccr/archive/1995/conf/floyd.html

http://www.dtnrg.org/

http://portal.acm.org/citation.cfm?id=863960&dl=ACM&coll=portal


http://citeseer.ist.psu.edu/kahn00emerging.html

http://citeseer.ist.psu.edu/kahn00emerging.html

http://www-ee.stanford.edu/~jmk/pubs/ccr.jmems.pdf

http://citeseer.nj.nec.com/259740.html

http://citeseer.nj.nec.com/259740.html

http://citeseer.nj.nec.com/kravets98applicationdriven.html

http://srds2003.cnuce.cnr.it/papers/soppera.pdf

http://srds2003.cnuce.cnr.it/papers/soppera.pdf

http://www.tcs.hut.fi/~anttit/manet/aodv/

http://www.it.uu.se/research/group/core/publications.php?pub_id=41

http://www.it.uu.se/research/group/core/publications.php?pub_id=41

http://bgp.potaroo.net/ietf/old-ids/draft-baker-manet-review-01.txt

citeseer.nj.nec.com/singh98poweraware.html

http://citeseer.nj.nec.com/chang00energy.html

http://www.cs.berkeley.edu/~madden/madden_aggregation.pdf

http://www.cs.berkeley.edu/~madden/madden_aggregation.pdf

http://bgp.potaroo.net/ietf/old-ids/draft-ietf-rmt-gra-arch-01.txt

http://bgp.potaroo.net/ietf/old-ids/draft-ietf-rmt-gra-arch-01.txt

http://www.ietf.org/rfc/rfc3077.txt

http://www.lcs.mit.edu/publications/specpub.php?id=997

http://www.lcs.mit.edu/publications/specpub.php?id=997


http://www.ub.utwente.nl/webdocs/ctit/1/00000087.pdf

http://www.ub.utwente.nl/webdocs/ctit/1/00000087.pdf


[44] Adler M, Ge Z, Kurose J, Towsley D, Zabele S: ‘Channelization problem in large scale data dissemination’,In: Proc. IEEE International Conference on Network Protocols (ICNP’01), (2001) URL: http://www.cs.umass.edu/~micah/pubs/channelization.ps

[45] Thaler D, Handley M: ‘On the aggregatability of multicast forwarding state’, In: Proc. IEEE Conferenceon Computer Communications (Infocom 2000), (March 2000) URL: http://www.ieee-infocom.org/2000/papers/632.ps

[46] Crowcroft J, Bacon J, Pietzuch P, Coulouris G, Naguib H: ‘Channel islands in a reflective ocean: Largescale event distribution in heterogeneous networks’, IEEE Communications Magazine, 40, No 9, pp 112–115(September 2002) URL: http://www.cl.cam.ac.uk/Research/SRG/opera/publications/2002-pubs.html

[47] Crowcroft J, Hand S, Mortier R, Roscoe T, Warfield A: ‘Plutarch: An argument for network pluralism’, In:SIGCOMM FDNA’03, ACM (2003) URL: http://www.cl.cam.ac.uk/~jac22/out/plutarch.pdf

[48] Brownlee N, Ma A: ‘NeTraMet flow lifetimes and implications for routing context’. Web page URL:http://www.caida.org/analysis/workload/netramet/lifetimes/ (June 2002) (Data in and out of UCSan Diego Supercomputer Center collected Jun 2000).

[49] Beverly R, claffy k: ‘Wide-area IP multicast traffic characterization’, IEEE Network, (January/February2003) URL: http://www.caida.org/outreach/papers/2003/mcastworkchar/

[50] Crovella M, Bestavros A: ‘Self-similarity in World Wide Web traffic: Evidence and possible causes’,IEEE/ACM Transactions on Networking, 5, No 6, pp 835–846 (1997) URL: http://citeseer.ist.psu.edu/22080.html

[51] Wan C Y, Eisenman S B, Campbell A T: ‘CODA: Congestion detection and avoidance in sensor networks’,In: Proc. First International Conference on Embedded Networked Sensor Systems, ACM pp 266–279 (2003)URL: http://comet.ctr.columbia.edu/armstrong/

[52] Speakman T, et al.: ‘PGM reliable transport protocol specification’, Internet draft, Internet EngineeringTask Force, URL: draft-speakman-pgm-spec-05.txt (November 2000) (Work in progress) (expires 24 May2001).

[53] Seleznyov A, Ahmed M O, Hailes S: ‘Cooperation in the digital age: Engendering trust in electronicenvironments’, BT Technology Journal, 22, No 3 (July 2004)

[54] Sastry N, Shankar U, Wagner D: ‘Secure verification of location claims’, In: Proc. Workshop on WirelessSecurity (WiSe 2003), ACM (September 2003) URL: http://www.cs.berkeley.edu/~nks/locprove/

[55] Gabber E, Wool A: ‘On location-restricted services’, IEEE Network, 13, No 6, pp 44–52 (1999)

[56] Anderson R, Kuhn M G: ‘Tamper resistance — A cautionary note’, In: Proc. Second USENIX ElectronicCommerce Workshop, pp 1–21 (November 1996) URL: http://www.cl.cam.ac.uk/users/rja14/#Reliability

[57] Perrig A, Szewczyk R, Wen V, Culler D E, Tygar J D: ‘SPINS: Security protocols for sensor networks’, In:Proc. ACM International Conference on Mobile Computing and Networks (Mobicom’01), pp 189–199 (July2001) URL: http://citeseer.ist.psu.edu/568886.html

[58] Perrig A, Canetti R, Song D, Tygar D, Briscoe B: ‘TESLA: Multicast source authentication transform intro-duction’, Internet draft, Internet Engineering Task Force, URL: draft-ietf-msec-tesla-intro-01.txt (February2002) (Work in progress).

[59] Juels A: “‘Yoking-proofs” for RFID tags’, In Sandhu R, Thomas R, eds.: Proc. First International Workshopon Pervasive Computing and Communication Security, IEEE Press (2004) URL: http://www.rsasecurity.com/rsalabs/staff/bios/ajuels/publications/rfidyoke/

[60] Chan H, Perrig A, Song D: ‘Random key predistribution schemes for sensor networks’, In: Proc. Symposiumon Security and Privacy 2003, IEEE (2003) URL: http://www.ece.cmu.edu/~adrian/publications.html

[61] Basagni S, Herrin K, Bruschi D, Rosti E: ‘Secure pebblenet’, In: Proc. International Symposium onMobile Ad Hoc Networking & Computing (MobiHoc’01), ACM pp 156–163 (October 2001) URL: http://www.ece.neu.edu/faculty/basagni/publications.html

[62] Moyer M J, Rao J R, Rohatgi P: ‘A survey of multicast security issues in multicast communications’, IEEENetwork, 13, No 6, pp 12–23 (1999) http://www.comsoc.org/

[63] Ratnasamy S, Handley M, Karp R, Shenker S: ‘Application-level multicast using content-addressable net-works’, In: Proc. 3rd International COST264 Workshop on Networked Group Communication (NGC’01).Volume 2233., Springer LNCS pp 14– (November 2001) URL: http://link.springer.de/link/service/series/0558/bibs/2233/22330014.htm

[64] Reed D P: ‘That sneaky exponential — Beyond Metcalfe’s Law to the power of community building’.Web Page URL: http://www.reed.com/Papers/GFN/reedslaw.html (1999) Online Supplement to Articlein Context magazine.

[65] Clark D, Sollins K, Wroclawski J, Braden R: ‘Tussle in cyberspace: Defining tomorrow’s Internet’, Proc.ACM SIGCOMM’02, Computer Communication Review, 32, No 4 (August 2002) URL: http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.pdf


http://www.cs.umass.edu/~micah/pubs/channelization.ps

http://www.cs.umass.edu/~micah/pubs/channelization.ps

http://www.ieee-infocom.org/2000/papers/632.ps

http://www.ieee-infocom.org/2000/papers/632.ps

http://www.cl.cam.ac.uk/Research/SRG/opera/publications/2002-pubs.html

http://www.cl.cam.ac.uk/~jac22/out/plutarch.pdf

http://www.caida.org/analysis/workload/netramet/lifetimes/

http://www.caida.org/outreach/papers/2003/mcastworkchar/



http://comet.ctr.columbia.edu/armstrong/

http://www.ietf.org/internet-drafts/draft-speakman-pgm-spec-05.txt

http://www.cs.berkeley.edu/~nks/locprove/

http://www.cl.cam.ac.uk/users/rja14/#Reliability


http://bgp.potaroo.net/ietf/old-ids/draft-ietf-msec-tesla-intro-01.txt

http://www.rsasecurity.com/rsalabs/staff/bios/ajuels/publications/rfidyoke/

http://www.rsasecurity.com/rsalabs/staff/bios/ajuels/publications/rfidyoke/

http://www.ece.cmu.edu/~adrian/publications.html

http://www.ece.neu.edu/faculty/basagni/publications.html

http://www.ece.neu.edu/faculty/basagni/publications.html



http://www.reed.com/Papers/GFN/reedslaw.html

http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.pdf

http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.pdf


Document history

Version Date Author Details of changeA 04 Dec 2003 Bob Briscoe Outline DraftB 12 Dec 2003 Bob Briscoe Updated outline draft based on reviewers commentsC 03 May 2004 Bob Briscoe Completed ready for review.1 06 Jun 2004 Bob Briscoe Modified following reviewer comments.2 18 Jun 2004 Bob Briscoe First issue sent to publisher.3 18 Jul 2004 Bob Briscoe Minor corrections.


Documents

The Implications of Pervasive Computing on Network Designbobbriscoe.net/projects/2020comms/pervimp/pervimp_bttj04.pdf · The Implications of Pervasive Computing on Network Design