The Implications of Pervasive Computing on Network Design

BT Technology Journal • Vol 22 No 3 • July 2004170

The implications of pervasive computing on network design

R Briscoe

This paper concerns the impact that computing devices will have on how we design networking. We identify the pressurepoints where pervasive computing will push current approaches to their limits, covering both technical and businessimplications. We use a broad definition of communications technology, to include not only infrastructure equipment andservices, but also communications facilities within computing devices themselves.

We outline progress in redesigning the Internet for pervasive computing. We cover components of communications such astransport, routing and security. But we also consider how the industry will be arranged, explaining why new modes ofcommunications (e.g. publish-subscribe) will become prevalent, where functions will be placed and how their deploymentwill happen. We give the rationale behind the most respected approaches being adopted. We give reasoned, if sometimescontroversial, views of what should happen, built on our own research. We dispel some myths and outline the researchagenda that still stands between us and realisation of the vision of pervasive computing.

1. IntroductionMark Weiser’s late 1980s vision of an age of calmtechnology with pervasive computing disappearing intothe fabric of the world [1] has been tempered by anindustry-driven vision with more of a feel of conspicuousconsumption. In the modified version, everyone carriesaround consumer electronics to provide natural,seamless interactions both with other people and withthe information world, particularly for eCommerce, butstill through a pervasive computing fabric.

Based on cost trends, trillions of devices globallyhave been predicted. Using a high-level economicargument we predict that most will be globallyconnected, at least at a rudimentary level. To a casualoutsider, a global network of either form of pervasivecomputing would seem to require a major re-design ofthe world’s communications systems. However, to areasonable extent, assumptions made during thedevelopment of the Internet’s architecture took intoaccount the more obvious issues that pervasivecomputing would raise. For instance the packetabstraction allows for brief one-way datagrams whichare ideally suited for reporting changes in the physicalenvironment, and IPv6 has sufficient address space forperhaps 1018 addresses per square metre of the earth’ssurface1. Also, the Internet protocol is deliberatelydesigned to abstract away from the creation of new linklayer technologies (IP over everything), such as those

appropriate for wireless links to battery-poweredsensors or devices in hostile environments.

However, when one delves a little deeper, problemssurface. The Internet architecture had substantiallycrystallised out just before Weiser’s vision wasarticulated. Perhaps as a result, the Internet was largelybuilt on assumptions of relatively stable, fixed butslightly unreliable connectivity, where availability ofplentiful mains electricity was never questioned.Pervasive computing breaks these assumptions,requiring a redesign.

We focus on the more fundamental issues, such asaddressing and routing, progressing to likely changes totraffic profiles which have implications on control ofcongestion and how to assure reliable delivery. Weaddress security issues throughout. Before drawing thepaper to a close with conclusions, we consider how thetechnical changes we have outlined will affect thebusiness of networking and vice versa. But before westart on any of the above issues we give a reasonedargument for why the prevalent mode ofcommunications for pervasive computing will bepublish-subscribe rather than primarily request-reply.

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


BT Technology Journal • Vol 22 No 3 • July 2004 171

2. Architecture

2.1 Conceptual modelNo prediction of the impact of pervasive computing onnetwork design can be undertaken without somecharacterisation of likely applications. Other papers inthis special edition survey expected applications [3]including case studies of its use for care in thecommunity [4], in the home [5] and in the automotivesector [6]. The MIT Internet Zero project [7, 8] has builtlights in flexible office spaces containing Internet-connected switches through which they are connectedto mains power, while touch sensors that look like lightswitches can be programmed to instruct the actualswitches over the Internet in order to alter their state.Probably the application closest to widespreaddeployment is the use of identity tags in the supplychain to replace bar codes, while sensors on work toolsand materials offer the promise of automating therecording of daily activity for workers, particularly in theservice industries.

We believe we can abstract all these pervasivecomputing applications into a single conceptual model,which we will use throughout the rest of this paper.

Pervasive computing devices allow the creation anduse of models in information space that representvarious aspects of our changing physical space. We cancreate information models that track changes in thephysical world and conversely arrange to change thephysical world when we modify our virtual models of it.

As a concrete example, the switch within an InternetZero light socket contains a simple (two state)information model of the light, and touch sensors holdthe addresses of the lights they control within theirconnectivity model. When a touch sensor is pressed, ituses its connectivity model to determine which light itrequests to change its state. In reality, the entire world’sInternet Zero lights and touch sensors are physicallyconnected to the Internet. But each connectivity modelis a logical mask programmed into each touch sensorthat limits its logical connectivity to only a few lights.The connectivity model in any touch sensor can itself bere-programmed to allow it to control different lights (oran Internet hi-fi, for that matter). For instance, when a‘screwdriver’ (in reality an authorised ID tag and readerin a screwdriver-like casing) is touched against a lightand then a touch sensor, it might reprogram the touchsensor’s connectivity model so that in future it switchesthat particular light.

Thus, pervasive computing devices, in their role asthe interface between physical and information worlds,have two complementary roles:

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

• in concert with many other transducers, to share(i.e. communicate) information about the physicalworld with other computers in order to collectivelybuild more comprehensive models of the real worldto be used for various purposes.

In this paper we focus nearly exclusively oncommunications driven by sensing the world. A fulltreatment of our subject would include actuators, butwe choose a scope that brought out at least most of themajor issues, as sensors tend to be more diffuse and theload from them far greater. Wide area tight feedbackloops between the physical and information worldswould have been even more challenging but will have tobe set aside for future work.

Every sensor creates an information model of thepart of the physical phenomenon it covers, but usuallysuch localised models serve little useful purpose alone.Many of these localised models need to be composedinto a more comprehensive model, requiring communi-cation from the sensors, then processing to correlatethe parts into a greater whole. This process is illustratedon the left of Fig 1, where the visual model is createdfrom multiple photographic scenes.

Also, multiple information models of differentaspects of the same physical thing may be required. Forexample, referring again to the left of Fig 1, its visualappearance, its thermal properties, its extent in 3-Dspace (an edge or vector model), etc. The creation ofcertain information models might be within thecapabilities of the computing power of the network ofsensors themselves. The way the visual model’s creationis depicted in Fig 1 works this way, composing a wide,high resolution 3-D visual scene across a ‘sensornetwork’ of simple devices, each connected to a simplecamera. Other models might require more computingpower than 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 runningon more powerful computers (or across manycomputers). The illustration in Fig 1 shows the co-sensorcase for thermal and edge models of the same originalphysical phenomenon.

Parts of each newly created model, may inthemselves recursively form part of a morecomprehensive information model of reality. The figureshows the visual model and the edge models beingcombined into a model of the 3-D extent andappearance of the original phenomenon. Further, these



models may be combined with non-physicalinformation, such as ownership, value etc, extractedfrom on-line databases, as shown on the right of thefigure.

Note that there is no implication of some grand planleading to the ultimate model of everything. Each of themillions of mini-models will be required in their ownright and each by some different interested party, whomay or may not be willing to pass on their model to helpbuild other models. But we can expect some owners ofthese models to exploit them both for their ownpurposes and to sell to others for theirs — retailing andwholesaling respectively.

Continuing the example of the Internet Zero lightswitches as an illustration, behind each touch sensormight be multiple connectivity models — a default andone for each person who had ever chosen to reprogramthe lighting system for their office space (assuming thetouch sensor was arranged to also detect the identitybehind each touch). A further model correlating allthese separate models together could be built, alsoencompassing a model of the presence of individualsbuilt from other sensor inputs. So the office lightingcould adapt, trying to satisfy every occupant, given

potentially conflicting requirements where some peopleturned lights on that others turned off.

2.2 Layered connectivityIn the above scenarios, connectivity is implicit. Physicaland logical connectivity has been deliberately arrangedso that each stage in the system can connect to and beunderstood by the next stage in the model. It is truethat humans will often deploy sensor networks forspecific purposes and ensure that their wirelesstransmissions can all reach each other, that they are alltransmitting on the same frequencies, with the samecodings and with the same application level languagesand formats. However, many applications will includethe creation of connectivity as part of the application.And it will be desirable to be able to use existing devicesand models to create new applications. So we have toallow devices to find each other and form into networksin the first place.

A classic, well-worn scenario is where an individualwalks up to a shop window with their personal digitalassistant (PDA) which connects to a monitor in thewindow to give the individual access to more screenspace. Behind this simple idea lies a host of problems.There are dozens of radio link standards in fashion at

Fig 1 Information models of the environment.

assetregister

phenomenon

visualmodel

edgemodel

property ofLegoland

3-D assetmodel

thermalmodel

edgedetection

colourphotography

co-s

enso

rsthermalimaging

7 Euro



any one time (Bluetooth, the WiFi family, etc), usingdifferent frequencies in each region — and hundreds oflegacy standards still in use across thousands ofdifferent devices. To find each other by radio contact,the PDA would have to scan many frequency ranges andtry all common coding, link and message formats (e.g.Jini, SLP, Twine, JESA, etc). The chances of such anapproach leading to reliable seamless connectivity, anytime, anywhere, are slim unless only one or two linkstandards predominate for all time.

An alternative approach would be to arrange at leastthe first stages of connectivity over a network commonto any randomly chosen pair of devices, which was thepurpose of introducing the Internet protocol — anintermediary between different link technologies (‘IPover everything’). So both the PDA and the monitor usetheir own link technologies to connect to theirrespective points of presence on the Internet. Themonitor advertises its location on a geographicalextension of the Web (e.g. geographic mark-uplanguage or SensorML), and the PDA, knowing its ownlocation and coverage, uses a geographical searchengine to find suitable monitors within range.

Clearly, the indirect approach to connectivity mayalso fail to connect our two devices due to lack ofmutually understood standards at the application level(e.g. the XML format of the appropriate geographicalsearch responses). However, the direct link approachhas the same chances of mismatch at the applicationlayer on top of the chances of mismatch at the physical,link and transport layers.

A logical model of the physical world has beencreated here in order to bootstrap creation ofconnectivity back in the physical world. Once the twodevices have found each other in the information world,they can look up whether they have compatibleinterfaces in order to initiate a direct link. Failing that,they may have a good enough path to drive the graphicsdisplay through their Internet connection. Indeed, themonitor in our scenario may not have had any wirelessconnectivity at all, only having a fixed link to theInternet. Another advantage of the indirect connectivityapproach is that devices can find each other in logicalspace even if the radio range of either of them isinsufficient or not in line of sight.

A more far-reaching advantage is that logical objectscan be placed in a model of the physical world even ifthey are not located there in the real world, i.e. a formof augmented reality, but within a model of reality,rather than the real thing (e.g. to test contingencies). Ifchanges to the model were also able to drive events inthe real world, it would be possible to test the responseof the real world to simulated events.

On top of Internet connectivity, a further pre-requisite for bootstrapping physical and logicalconnectivity in pervasive computing applications likethat above will be comprehensive information models ofthe location of things in the physical world [9, 10].Again, we see the pattern where we start with potentialconnectivity to everything, then logically reduceconnectivity to that possible within a confinedgeographical scope, then further reduce connectivity tothat required for an application. Effectively we arecreating overlay networks over overlay networks.

2.3 Modes of communications

2.3.1 Asynchronous communications Impressive work has been done compressing commoncommunications protocols into tiny devices. For instanceShrikumar has implemented a Web server and all theprotocols beneath it using 256 B of code [11]6. However,this example highlights a need to carefully considerwhat mode of communication is appropriate when inter-facing with the physical environment. The Web works inrequest-reply mode. A client asks and the server responds.But this is not how we sense the physical world. We donot ask the grass what colour it is. Photons arrive fromthe grass unsolicited. If we want to know whether it isdark yet, we do not keep asking a light sensor whether itis dark yet. It is far more efficient to configure the sensorto tell us when it is dark and, importantly, we will findout as soon as it gets dark, rather than the first time wehappen to ask after it has got dark — timely notificationof events. Thus, request-reply is appropriate foractuators, but less so for sensors2.

Thus a more appropriate mode of communicationfor sensors will be based on asynchronous events, apoint made by Shrikumar himself about the applicabilityof his miniature Web server with respect to his earlierwork on event notification embedded in devices [12]. Anevent should trigger in a sensor as its environment3

changes, the magnitude of the necessary changedetermining the sensing granularity. An event notifies achange in the state of an object, allowing other copiesor models of that object to update themselves, which inturn may require them to generate further events. Eventnotification requires the publish-subscribe (pub-sub)mode of communications [13] (Fig 2), where an objectpublishes its potential to generate events to a logicalchannel, then listeners may subscribe to be notifiedwhen they occur.

In terms of the conceptual model built in theprevious section, some information models will need to

2 Request-reply has its place when a model is rarely used and can be stalebetween times.3 Time being part of a sensor’s environment, which may be used to triggerscheduled reports on the rest of the sensor’s environment.



be physical-event-driven and continuous, requiring pub-sub feeds into them, while others will be created to fulfilone specific request, requiring request-reply. So eacharrow representing communications between adjacentmodels in Fig 1 might involve either push or pull.However, an event-driven model can only receivegenuinely timely events if all the models it depends onare also event-driven4, right back to the physicalphenomenon itself. Whereas a request-reply model willstill be valid if it makes a request into a real-time modellower down the chain. Thus, all pervasive computingsystems should support pub-sub.

A common composition of both request-reply andpub-sub modes is where a pub-sub session isdynamically created (and eventually torn down) onrequest, with regular responses fed back to therequestor. This is an example of the call-back mode ofcommunications (Fig 2). Later we will discuss anapproach called directed diffusion [14] that works thisway, with a request diffusing through a sensor networkto the most appropriate sensors and regular responsesfollowing the same path in reverse to the requestor. Weimplemented another useful composition termed look-up-and-watch using our generic announcementprotocol (GAP [15]), where the initial request gives animmediate reply, but also sets up a call-back session tonotify future changes, the address of which is alsopublished so others can join.

Having introduced the main modes ofcommunication relevant to pervasive computing, wesingle out pub-sub for special attention below,examining two further features beyond timelynotification that are particularly relevant to pervasivecomputing — group communications and no listeningat the source.

Before moving on, we should clarify that we do notenvisage the pub-sub mode being prevalent formachine-to-human communications, as few peoplewant or need continual interruption (evident from thelack of take-up of Web push in the mid-1990s). Humansprefer the hybrid messaging mode where communi-cations are queued until the recipient’s attention isready to turn to them. We only expect pub-sub mode topredominate for machine-to-machine communications.

2.3.2 Group communications Whereas request-reply is inherently point to point, pub-sub’s inherent point to multi-point nature allowsmultiple parties to maintain the models they need. Theunderlying feeds from the real world may thencontribute to a plethora 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 listening forsensor events would have to remember to tell the sensor4 At the same or at a finer granularity.

Fig 2 Communication modes.

request

reply

server client

time

updates

subscribe

call-back

source listeners

publish

updates

one shot

channel

newsubscribe

requ

est-

rep

lyp

ubl

ish-

subs

crib

e

notify



of any changes to its notification address while it waswaiting.

Two approaches solve this problem. One provides abare logical communications channel where thoseinterested join the channel (e.g. IP multicast [16]). Theother simply moves the problem to a proxy service forthe sensor (e.g. the distributed event mediator servicein the Cambridge Event Architecture [17]). In eitherapproach, a sensor only has to remember one channeladdress and send just one message to it for each event,rather than overloading already challenged sensors withmultiple requests.

Under the covers, both approaches are essentiallysimilar. They are both generally implemented asnumerous software objects, which are addressedcollectively as a logical channel. Listeners declare theirinterest to their neighbouring instance of the channel,which remembers their interest and in turn subscribesonwards to other instances. When an event occurs, thesource sends it to its neighbouring instance of thechannel, which distributes it onwards towards whereverinterest has been declared (Fig 3).

However, the fundamental difference is that themediator provides a bundle of event-related serviceswhile the bare communications channel deliberatelyonly provides dumb forwarding. So a bare channel couldas easily be implemented either as a radio channel, or asa collection of software subscription lists as describedabove. The bare channel approach is deliberatelydesigned [18] to be complemented by other servicessuch as event archiving and recovery, but only ifrequired. If recall of previous events were required,perhaps to help late joiners or those temporarilydisconnected, the event mediator would provide thisservice itself, whereas without knowing why, the barechannel would simply forward the information to anarchiving node because it had joined the channel inorder to provide this service. Other approaches sit atintermediate points on this spectrum. For instance,Microsoft’s SCRIBE [19] is a bare channel service, butalso offers reliable delivery (discussed in section 3.5).

Of course, we cannot expect everyone to share theirdata freely. Confidentiality may be required to protecttrade, individual privacy [20], or other differences ofinterest. Again the above two approaches differ in howthey offer confidentiality. An event mediator service

Fig 3 Multicast and concast group formation and forwarding.

host 1

relay 1

relay 2

host 2

host 4 host 3

duplicate

duplicate

install

install

aggregate

aggregate

source source

join inrouting group

members listeners

multicastforwarding

initiator listener

deploy aggregationbehaviour

concastforwarding

potentialsources

sources



includes an access control function that acts fully onbehalf of the sensor. This requires each listener to giveappropriate credentials before being allowed to join,while the dumb channel again leaves confidentiality toanother service. The sensed data would have to beencrypted before sending to the channel, while anotherservice 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 (section 2.4) and on security (section 3.6).

2.3.3 Announce or listen A further advantage of the pub-sub mode is that thesensor has no need to listen for requests in ‘servermode’6. Wireless sensors would very quickly run downtheir batteries if they had to leave their radio receiverrunning to listen for arbitrary incoming requests. It is farless power-consuming to leave only the sensingmechanism running, ‘listening’ for changes to thephysical environment, which can then trigger power-upof the radio circuitry only to send notification of theevent.

But, when discussing our conceptual model earlier,we emphasised that pervasive computing systems needto be able to respond to arbitrary requests as well asasynchronous notification of events. Does this not meanthat their radio receivers will have to remain powered upanyway? The answer lies in separating event memoryfrom event communication. In order to answer requestsfor the current temperature, or the current state of atouch sensor, the sensor itself does not need toremember its own state. As long as something else(connected to mains power) receives events from thesensor, it can respond to requests for the sensor’scurrent state between times.

Proving many of the points so far, Shrikumar’s tinyWeb server was soon taken off the Internet, as its seriallink was continually overloaded with requests fromcurious browsers. Its content is now served from a largermirror server.

2.4 Function placement

2.4.1 Evolvability A system’s evolvability is highly sensitive to theplacement of communications functions, which is thechief concern of the Internet’s end-to-end designprinciple [18]. The need for evolvability of today’scommunications infrastructure is obvious, given largeinvestment costs require future-proofing. But one may

wonder why evolvability of pervasive computing devicesis a concern, given the growth of pervasive computing isbased on projections of plummeting device costs [1].Can we not assume each device is disposable, only everbeing used for the purpose for which it was firstdeployed? The issue here is that the equipment is only apart of the cost of a new application. As deployment is amajor cost consideration, it is highly desirable to putdevices deployed for one purpose to use for others. Forinstance, to add a one penny wireless sensor beneaththe drum of your washing machine costs a lot more thanremotely reusing the one that is already there.

2.4.2 Open by design, closed by choice In section 2.2 on layered connectivity, we recursivelycreated confined connectivity within wider potentialconnectivity. We argue that the value of globalconnectivity greatly outweighs the cost. Metcalfeshowed that the value of the connectivity of each devicerises with the number of other devices to which it couldpotentially connect, making global connectivity highlyvaluable; whereas the cost of fully standards compliantInternet connectivity is a mere 200 B of code [11]6, plusthe running cost of the processing and bandwidthrequired for the extra header layer (compressible to abyte or so). Devices might not carry an Internet stack,but instead connect to a hub that does. However, theadded complexity of arranging and managing a hubhardly seems worthwhile given the low cost of directInternet connectivity. Therefore economies of volumemanufacture are likely to lead to every device designincluding an Internet stack, whether or not it is neededfor every application.

Global connectivity is also highly desirable forevolvability, otherwise new uses will be constrained bylocality. For example, initially it may not seem necessaryto give light switches global connectivity, but one dayyou might appreciate the facility to turn your lights offfrom your mobile phone while on holiday. However,more controversially, others may be able to remotelycontrol or monitor your lights. One approach to thisprivacy problem is to place inherent accessibility limitsin the design (e.g. to design a car door lock so it canonly be opened within a limited range). But this onlylimits the first hop, which cannot be prevented fromnetworking onward globally. A safer approach is toassume global accessibility might exist, and to close offundesirable uses logically rather than physically. To fullystress network design, we take the ‘assume open thenclose’ approach. However, we accept that designers ofcar security systems and the like will care more aboutpresent security than future evolvability. This dilemmais further explored in another paper [20].

5 The term server relates to any process able to respond to arbitraryincoming requests, irrespective of whether it runs on a large machine oftencalled a ‘server’ or on a tiny sensor.

6 2.5% of the memory of a Berkeley mote, which is likely to grow incapacity and shrink in size in line with Moore’s Law.



2.4.3 Dumb relaysWhether or not the devices themselves should beevolvable, it is certain that the rest of the systems theywork with should be. All too often, principles ofevolvable system design are too readily set aside inpervasive computing demonstrators. Rather thandesigning for messages from sensors to be transmittedto and from any other computer in the world, functionsare often embedded in the base-stations that interfacebetween the sensor and the rest of the world, perhapsdoing some address or protocol conversion (e.g. fromsensor-local to global). We discuss some cases belowwhere intelligent base-stations can be justified onprinciple. But if intelligent relays are necessary to adesign, the end-to-end design principle teaches us thatit is worth taking a long hard look at alternative designsthat confine intermediate relays to dumb forwarding.

Ideally, the sensors themselves should be first classInternet citizens. But failing that, the remote end-pointsthey communicate with should supplement their limitedcapabilities, not neighbouring relays (so the fate of acommunication depends only on the state and trustshared between the end-points of the communication).Tying higher layer functions to specific instances ofequipment operated by specific parties will limitflexibility, especially for new business models.

Power conservation can be a valid reason to relax theend-to-end principle, with base-stations taking onadditional functions by virtue of their role as the firstmains-powered node in the path. But this need not bean excuse to open the flood-gates to more functionsthan necessary. For instance, strong encryption ispossible on challenged devices (see section 3.6), sosensors should encrypt their data for confidentiality andthe base-station should merely relay the encrypted datato another destination. Functions such as re-transmission can be achieved without access toencryption keys, the goal being to limit access to as fewparties as possible. For instance it would be inadvisableto embed an event mediator service in the base-station,which decrypted events and controlled further access tothem itself. This would limit future uses of the system toones where the base-station operator was trusted byeveryone who 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-hop sensornetworks. Taking the sensor network as a whole, it hasbeen proved that combining data aggregation with therelay function within each sensor saves considerablebattery power for typical diffuse sensing applications[21]. When battery power is paramount relative toevolvability, it seems we have to compromise and makeinfrastructure more application specific — counter to

end-to-end design principles. We return to this subjectin section 3.3 on routing.

3. Component servicesSo, faced with all the choices above and more to comebelow, which course should a wireless sensormanufacturer or network equipment vendor take? Isthere a generic design for communications withminiature devices? Which communications servicesshould service providers be considering? Of course, thedetailed answer might depend on the specifics of theapplication or the devices required for it. But, thefollowing sections discuss progress towards defininggeneric component services so that as many specificrequirements as possible can be satisfied by buildingapplications over these components.

To kick off the discussion we propose a straw mandesign for the communications systems of a miniaturedevice. We believe that a large range of applicationscould be satisfied by this apparently strange proposal.We briefly outline the reasoning behind the proposal,but we do not intend to imply that any other approachmust be inferior in all circumstances. The architecturaldiscussion above was necessarily conducted at a fairlyabstract level. We put up a straw man at this point todeliberately force a change of pace in the paper. As weproceed through the following sections, the choiceswiden further for each aspect: routing, addressing,reliable delivery, congestion control, traffic profiles,security 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 devicemanufacturers to commit to a design that will survive alarge production run.

3.1 A straw man proposalWe would recommend a configuration-free device thatpowered up its radio transmitter whenever it sensed athreshold change to its environment. It could then senda ‘fire-and-forget’ datagram to a hard-coded multicastaddress7 and immediately power down its transmitter. Itwould also send heartbeat messages, confirming thepreviously sent event at regular intervals8. The devicewould have to be one hop from its base-station. Itshould be relatively tamper-resistant, at leastoutputting a warning if tampered with, so that it couldhold an internally stored key, which it would use to seeda regularly changing pseudo-random sequence of keysused to encrypt its messages.

7 Preferably IP multicast, but otherwise a multicast medium access control(MAC) address, with a different one in each device.8 Slow changes to the interval could be arranged with repeated advancewarnings.



Our reasoning for choosing this design is that,although a sensor may only be able to perform onesimple function, to bring down its cost of production, itshould be manufactured in volume. So its singlefunction will need to be applied in many different ways.The device must therefore be secure to some degreeeven though it may not always need to be. And we havedeliberately chosen to allow it to be re-purposed pre-and post-deployment but without re-configuration, sothat the device need have no server listening forconfiguration changes, saving battery power andimproving inherent security, e.g. proofing it against thesleep deprivation torture attack [22], which leaves anynode that responds to arbitrary requests vulnerable torapid exhaustion of its battery.

We have recommended multicast addressing, asotherwise a device hard-coded to send to a unicastaddress is permanently tied to a specific correspondingnode. Multicast addresses have no topologicalsignificance, and so the receiver of each message can bechanged without involving the sender, instead onlyrequiring potential receiver(s) to be configured to listen.Multicast addresses need only be loosely unique, as amulticast transmission can be locally scoped, to preventclashes with transmissions to the same address. Anyreceiver could re-multicast with a wider scope ifnecessary.

The device’s multicast event notifications could belimited to just one receiver, by not revealing the seedkey more widely; or the seed key could be published ifthere were no need for confidentiality. Between thesetwo extremes, time-bounded parts of the pseudo-random sequence could be revealed to selected groups[23] by a separate key management server.

At least one receiver (perhaps the only authorisedreceiver) could maintain the sensor’s state, acting as itsproxy for arbitrary incoming requests, and archivingevents for late joiners. As the sensor would not be ableto receive acknowledgements for anything it sent, if areceiver missed a heart-beat, it would need to rely onother receivers for a re-transmission [24] or, if therewere no other successful deliveries, wait until the nextheartbeat.

This straw man proposal is intended to cover a wideset of circumstances, but only where each sensor alonehas sufficient radio range to reach a mains-poweredcommunications device. Multi-hop networks of sensorswould not be possible with send-only sensors. Multi-hopsensor networks come up repeatedly in the rest of thispaper, being a major focus of the research agenda. Butthat does not make this straw man proposal irrelevant,given single hop wireless sensors may turn out to bemore prevalent in practice.

3.2 Unusual link technologiesGiven 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 oropportunistic. Error rates may be high even whenconnected.

Further, the range of one end-point may be muchgreater than that of the other (typically where one end isconnected to mains power), implying that oftenconnectivity will be unidirectional. Nonetheless, noveltechnologies have been built to scavenge energy fromcommunications in one direction, modulating it in orderto respond in the other. Radio frequency identity tagswork this way, capturing the excitation energy in thereader’s radio transmission until sufficient energy hasbeen built up to respond by modulating the incomingsignal. Micro-electro-mechanical (MEM) fabrication hasbeen used at UC Berkeley to build corner cube reflectorson ‘smart dust’ devices. It is projected that smart dustwill be small enough to float in air or water. Thereflectors work on the same principle as roadway cat’seyes, but the angle of one face can be varied slightly tomodulate the reflection of an incoming optical beamback to its source [27]. The team have manufactured asub-millimetre cube and achieved 400 bit/s over 180 mwith good signal-to-noise ratio [28], while their analysisclaims many kbit/s are possible over hundreds of metresin bright sunlight.

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 hybridcommunications technology, so that it can hail thebase-station with a short burst of radio broadcast. Thebase-station then shines its optical beam in order topick up the message the sensor has for it [27], giving thesensor on-demand access to the link for minimal energycost.

Even with more conventional wireless linktechnologies, there is considerable scope for improvingpower efficiency by designing medium access [29, 30]and transport protocols [31] to minimise energy use,with only minor compromises in traditional performancemetrics necessary.

All this novel link technology helps, but does notremove the problem of poor connectivity, whichchanges the rules for designing all the layers built overit, right up to the application. In our own index-basedevent-messaging system [32], eventual messagedelivery over disconnections is provided by the



managed messaging layer on announcers and listeners.Messages are clustered into groups based on interestand indexes of the current version of messages in eachcluster are beaconed at regular intervals. As nodesregain connectivity, their managed messaging layertransparently finds which messages they have missedand accesses them from an event archive.

3.3 RoutingThe 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 stronger intheory than practice. Just one implementation (asopposed to simulation) of a routing protocol (AODV[33]) was able to reliably route packets over more thanone hop [34]. These were results from the InternetEngineering Task Force’s (IETF’s) Mobile Ad HocNetworks (MANETs) working group, which has beenchartered since 1995/6 to focus on standardisingprotocols that are near to market.

To realise the vision of pervasive computing, farmore challenging scenarios are envisaged. Routingprotocols have been implemented for large numbers oftiny, dust-sized devices with very short range, whereeach second of battery use is one second closer todeath. In such scenarios, few nodes are within range of agateway giving access to wider networks, butcollectively a network of sensors should be able to relaymost nodes’ messages to a gateway.

3.3.1 Routing hierarchyRouting research for sensor networks has rightlyseparated routing within the sensor network from therouting beyond it. Although there may be a choice ofroutes out of the sensor network, it is rarely necessary toconsider optimising routes across both networks atonce, as the sensor network leg is far more resource-critical. However, ensuring that messages destined forthe sensor network enter it from the most efficientgateway requires a model of the sensor network to beheld by routers outside the domain. If routing nodes arerelatively powerful (e.g. MANETs being considered bythe IETF), it has been argued that popular link staterouting protocols can be sufficient. They can be tunedto allow the combination of fixed and mobile nodes towork together effectively, without too much power andmemory consumption within the MANET [35].

3.3.2 System-wide energy conservation Routing protocols are generally designed to be agnosticabout which route cost-metrics to use. So it is relativelystraightforward to replace traditional hop metrics withpower-aware metrics. Singh et al [36] showed mean

time to battery exhaustion for a whole mobile ad hocnetwork could be considerably improved by using suchmetrics.

Chang et al [37] proved analytically that battery livesacross a whole network of fixed but wireless devicescould be maximised with no need for global co-ordination, only requiring an algorithm local to eachnode that ensured local energy consumption wasproportional to local energy reserves. However, oftenthe lifetimes of critically placed nodes become thedetermining factor for the lifetime of the whole network(e.g. those close to a base-station).

3.3.3 Application-specific concast In section 2.3 we explained the need for pub-sub modeof communications and introduced the requirement forrouting events to multiple parties. However, sensornetwork routing has avoided multicasting, as it is morepower efficient to relay events across sensor nodes to asingle gateway rather than duplicating the message andthe power required to transmit it. From there, themulticast model can be offered, with multiple partiessubscribing to a logical event channel.

In 2001, researchers at the Internet SciencesInstitute (ISI) showed that when on-net capacity (withinthe sensor network) is critical, it is more efficient toaggregate data from sensors while routing it, ratherthan sending each reading separately to an off-netreader to be aggregated there [21]. This proved thecorrectness of their seminal earlier work called directeddiffusion [17].

Directed diffusion was a radical departure.Traditionally routing is based on node addresses,ensuring everywhere in the network maintains routes toany other address so that applications can sendmessages to other nodes by their addresses. Instead,directed diffusion addressed messages by the content ofthe question that required answering; and nodesadvertised the answers they could give by the content ofthe questions they could answer. Thus, for a sensorreading such as ‘temperature = 17’ the relevant contentname is ‘temperature’. This was the first instance ofwhat came to be termed content-addressable networks(CANs)9. However, unlike subsequent CANs, directeddiffusion worked without the benefit of any underlyingrouting. Sensors capable of answering ‘temperature’questions would advertise this fact to their neighbours,who would flood this fact outwards. Queries about‘temperature’ could then be routed to the correctsensors, leaving behind a trail of ‘bread-crumbs’ soreturn messages could be reverse routed to the original

9 CANs became prevalent the next year for routing in peer-to-peer overlaynetworks for file-sharing and related applications.



place the query had entered the network. While returnmessages were relayed across the sensor network, thetemperature values could be aggregated. For instance,the weighted mean might be calculated beforeforwarding on the result.

The aggregation functions to use and the routinglogic of each directed diffusion session were highlyapplication specific. As explained earlier, evolvabilityhas to be compromised if other factors (e.g. powerconservation) are paramount. But then, in 2002,researchers from the database community at UCBerkeley generalised the ideas in directed diffusion,using common aggregation primitives found incommercial databases (COUNT, MIN, MAX, SUM, andAVERAGE) [38]. Thus, a more generic routing capabilityhas been implemented in the TinyOS operating systembuilt for the Berkeley motes10. It is called TinyDB, givenit involves the rather unexpected inclusion of databaseaggregation 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 concast modesof communications. In concast, multiple messagesconverge, with some combination function at eachmerge point (Fig 3). In the mid-1990s, concast wasrecognised as a valid communications mode, usedprimarily when data traversed a multicast tree inreverse, for functions like aggregating multicastfeedback or merging bandwidth reservations.

We should add that both directed diffusion andTinyDB allow for a time series of responses to an initialquery. In this respect, they use the call-back mode ofcommunications introduced in section 2.3, creating alogical pub-sub channel (e.g. on the ‘temperature’topic) in response to a session initiation request.

3.3.4 Unusual routing for unusual links Beyond designing for challenging power requirements,routing protocols are also having to be re-designed tocope with inconsistent link availability (see section 3.2earlier). If sensor nodes are acting as relays in multi-hopnetworks, but they can only power up intermittently,they all have to synchronise to get any relaying done.

Also, routing is notoriously difficult withunidirectional links (as routing inherently concernspassing advertisements of downstream connectivity toupstream nodes). Routing over unidirectional links hasbeen solved for the classic example of satellite down-links, by creating a tunnelled virtual link along a back-

channel, through which routing messages can bepassed [40]. However, routing over links that unpre-dictably become unidirectional is still a research issue.

3.3.5 Routing securityIf all the above research issues were not enough, routingin ad hoc networks presents numerous further unsolvedsecurity challenges. Already authentication of routeadvertisements is a difficult area if there is a high churnof network operators. It is unrealistic to expect trillionsof devices to appear in the next decades unless billionsof networks also appear in order to connect themtogether, implying extremely rapid appearance of newnetwork operators (unless all networking is out-sourcedto the few existing operators, which seems hopelesslyoptimistic).

In order to validate routing message authentication,any one network must know from whom it would expectto receive adverts. So authentication of routes throughnewly appearing networks will require trusted thirdparties to introduce the new players. Also, just becausea route advertisement is authenticated, does not meanit is honest [41]. Commercial networks have anincentive to understate the cost metrics of their routesto attract extra custom. So unless the cost of anadvertised route can be objectively tested [42],authentication means little.

Although problems of authentication are hard, therange of possible attacks on the availability of ad hocnetworks are even harder to solve. We have alreadymentioned sleep deprivation torture attacks on powerconstrained nodes. Law et al list a range of furtherattacks in their excellent introduction to this area [43]— black-holing, flooding, detours, loops, worm-holes,hijacking and blackmailing. Each node’s finite batterypower makes it vulnerable to any attack that requires itto use its energy before it can determine whether it isbeing attacked.

Clearly, if any section of society takes a dislike tocertain wireless devices in their environment, they willonly need to identify one of these vulnerabilities toattack them. The send-only sensor in the straw manproposal above, is a pragmatic way to avoid many of thevulnerabilities, although it is still susceptible to physicallayer attacks such as channel jamming and the like.

3.4 Naming and addressingTo a casual observer, the size of the required addressspace for a computing network should relate to thenumber of hardware devices in the world. However, ifpub-sub communications become predominant, thesize of the problem will be determined by the number ofsoftware objects that have an audience of other10 Generic sensor nodes manufactured by Crossbow.



software objects watching for updates to their state —potentially far more numerous than the trillions ofdevices on which they sit.

3.4.1 EncapsulationHierarchy has invariably been used to ensure addressingschemes can scale. For instance, variable names usedwithin a programme resolve to memory addresses, butthe same variable name or memory address used in twoprogrammes (or even two instances of the sameprogramme) are distinguished by the identity of theprocess in which they run (strictly the identity of theinterface to the process). Continuing up the hierarchy,processes are identified relative to the interfaces of themachines on which they run. Machines are identifiedrelative to their subnetwork and so on.

3.4.2 Address aggregationHowever, large distributed processes like environmentmonitoring sit across machines rather than within onemachine, inverting the ‘normal’ hierarchy11. Sharingthe variables of the process across machines causes thescaling problem introduced above. Imagine a large setof sensors also acting as relays for each other. Imaginethat a subset comprises temperature sensors, which,along with those interested in their readings, all hold acommon interest in the group-name ‘temperature’. Weexplained earlier (section 2.3) why the only practicalapproach here is for each sensor to send to a logicalchannel — pub-sub mode — rather than each hold a listof interested listeners. The logical channel is created bythe interest of the listeners and the combined routing ofall the relays. So every relay has to remember the list ofthose logical neighbours to which to forward messagesconcerning the temperature question. This listconsumes a small amount of memory on each relay.

Another subset of the same sensors may begathering road traffic statistics. So each relay also hasto set aside memory to route messages for the ‘road-traffic’ group. If there are a large number of network-wide processes being supported across the sensornetwork, there could be a routing group for eachvariable in each process — potentially one routinggroup for each software object on the network.Alternatively, many groups can be combined into one,so that some end-points have to filter out messagesthey are not interested in (a problem familiar to peoplewho use e-mail lists). However many groups there are,each relay will have to store a different neighbour list foreach group.

Unfortunately, as there is no generic way for eachrelay to aggregate the per-group neighbour lists itholds, the memory required on each relay grows linearly

with the number of routing groups. Each pair (group-name, neighbour-list) bears little relation to any otherpair. Even if numbers are uniquely assigned to eachgroup, in a numeric order that helps one node to groupits neighbour-lists efficiently, this order is unlikely tohelp any others. In 2001, this problem was articulatedformally as the ‘channelisation problem’ [44], alsoapplying to radio channel allocation. Given we believepub-sub will be the predominant mode ofcommunications in pervasive computing, thechannelisation problem puts inherent limits on theeconomic viability of pervasive computing. Thedesigners of directed diffusion and TinyDB have not hadto worry about this problem, because current sensornetworks are application-specific, requiring only a fewrouting groups. However, if our conceptual model ofpervasive computing (section 2.1) becomes prevalenton a global scale, the channelisation problem will arisein the (mains-powered) networks connecting togetherthe physical and information worlds. We predict thatevents from the physical world will spread out across aweb of listeners around the globe, with little correlationby location.

Until recently, only limited group aggregationpotential was considered feasible on relays [45]. A naïvesolution is to use one coarser logical channel to replacemany more granular ones and just expect receivers tofilter out what does not concern them. Some of thefiltering burden can be carried by the network, evenusing commercially available Internet routing products.Hop-by-hop filtering can be added to these products[46] using their support for generic concast functions[39] (see section 3.3).

Our own solution to this problem takes an end-to-end12 rather than hop-by-hop approach. Our aim was tosolve the address scalability problem, but withoutrevealing any more than necessary to intermediateparties, given messages will often contain commercialor private information. There were also deliveryreliability reasons for choosing this approach (seesection 3.5).

We create routing state for very granular routinggroups on relays but only for the brief time it is neededto pass a message [56], which at first sight seems toprevent anything being sent. But each group is classi-fied into indexes, clustered together with other groupshaving similar interest. Changes to indexes are notifiedto end-points interested in them using event messagingrecursively, and indexes may themselves be furtherindexed. Group members listen to an index or indexes oftheir choice in order to hear when a message arises for

11 Distributed processess will be the norm in the future.

12 Throughout the paper, the term end-to-end is used in its technical senseto mean ‘involving only the ends to provide the function in question’.



their group. Persistent routing groups only need to beheld open on relays for those index groups with anaudience. When an event source has a message to send,it first updates the indexes. Those listening then sendjoin requests to their closest relays, creating the group’srouting structure only for the brief time required. Thesolution makes memory usage scalable as more groupsare required, but has to be traded off against a need formore messages to co-ordinate the indexes.

3.4.3 Topographical addressingWe have already briefly discussed requirements formapping between physical space and the logicaladdresses of processes on computing devices (section2.2). In order for two software objects to establishwhether they are close in a modelled co-ordinate space,the most efficient approach is to create further objectsto represent each volume of space. The model of eachspace holds the identifiers of objects placed within itand announces whenever an object enters or leaves it.Then, any object has to monitor the object representingthe space it occupies in order to find other nearbyobjects, rather than having to continually interrogatethe position of all objects in the world in case any one ofthem passes close by13.

Thus we can immediately see a scenario where everyspace (of varying volume) in the physical world is repre-sented by an object in the information world, whichmany other objects that have placed themselves in thatspace are continuously monitoring. Just this singleproximity application would be sufficient to cause thegroup address aggregation scaling problems we haveoutlined — when trillions of objects are watching forchanges in trillions of other objects. Further, many ser-vice providers will maintain space models requiring co-ordination between multiple models of the same space.

3.4.4 Internetworking beyond the InternetAs networks of computing devices are formed, they mayall inherit their networking characteristics from theevolving Internet architecture. However, newindependent forms of network may develop without anyoverarching architecture common to all the networks.Overlays that work across multiple networkarchitectures are perfectly feasible, the Internet itselfbeing the classic example. But federations of differentnetwork architectures are fraught with problems.

The Plutarch proposal [47] considers what isnecessary to federate multiple addressing architectures,also making some inroads into wider federation issues.But address resolution differences can be confined toend-points and clearly identifiable gateways betweenarchitectures (cf IPv4 to IPv6 gateways). The hard

problems start when federating data handling along thewhole network path — detecting routing loops orcongestion, or controlling priority, capacity reservationor routing. The gain from not using an Internet-widearchitecture would have to override the pain suffereddealing with such a wide range of issues.

3.5 Data transport issues

3.5.1 Traffic profilesIf computing does become pervasive one might assumethat a majority of traffic flows would consist of just a fewpackets, with single datagram flows being common. Butwe cannot predict whether these bursts wouldconstitute a large proportion of total traffic volume. Inthe last half of the 1990s, due to the rise in popularity ofthe Web, flows of a few packets (< 20) constituted thelarge majority of the flows (95%) and a sizeableproportion of the volume of traffic on the Internet (see,for example, Brownlee and 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 to try topredict the future traffic mix, it would be reckless todesign networks and protocols without contingency fora range of scenarios.

Even our intuition about the traffic implications ofcurrent uses of the Internet can be misguided. Mostpeople imagine multicast is used to stream long-running sessions. Although this use does indeedconstitute a large volume of multicast traffic, a study ofnearly four million native multicast flows14 [49] foundover 75% consisted of just one packet. Closerinvestigation found a large proportion of theseconsisted of co-ordination messages to announce theexistence of other sessions through various multicastindexing tools. The same bimodal distribution causedby the division in human behaviour between managingand doing (whether work, social interactions orwhatever) is seen in unicast traffic [50]. But, pastbehaviour (mostly from human-attended sessions) is nota reliable guide to the future traffic mix, if unattendedsessions come to predominate.

For instance, we might see huge avalanches ofmessages firing across the Internet following majorchanges in the real world (road-traffic accidents, battles,security advisories, etc). Network management eventavalanches already create problems that are hard toquantify until they happen. Once the information worldis much more tightly coupled to the real world, thecomplex chains of dependency between messages (thatmay also get lost during such events) may become nearimpossible to design for.

13 Recall that any object might jump to anywhere in cyberspace. 14 Monitored throughout July 2001 on MCI/WorldCom’s backbone



3.5.2 Congestion controlIf the large majority of Internet traffic volume does turnout to consist of little bursts of packets betweenuncorrelated end-points, current congestion controltechniques will be largely useless. In order to pace itsrate, a sender should mimic the behaviour of thetransmission control protocol (TCP-friendly), whichrelies on congestion feedback from routers on the path.When a sender starts a new flow, it carefully introducespackets to the network, sending two for every one thatgets acknowledged by the receiver, until it sensescongestion. However, brief flows finish long before theydiscover the rate they could have used, because theyhave to proceed so cautiously.

If the traffic mix is mainly short flows, there may beinsufficient long-running flows to use up the remainingnetwork capacity. So there will come a time whenfurther increases in network capacity will not bring anybenefit. TCP-friendly slow-start algorithms will becomethe limiting factor for network capacity. Of course, thecontrary approach would not work either; whereeveryone agrees that TCP should be allowed to ramp upmore aggressively. We could then return to the episodesof persistent congestion collapse that led to theintroduction of TCP in the 1980s.

Further, in the pervasive computing vision,distributed computations will always be fighting againstunavoidable propagation delays due to the speed oflight. Already many GRID applications use parallelismextremely judiciously, because the messaging delaysbetween computers are so great relative to local delays.TCP’s ‘slow-start’ puts an inherent limit of O(log(n)) onthe latency of a short burst of n packets. Whereas oftena whole burst could have been served in one round trip,but that can only be discovered in retrospect15.

3.5.3 The data rate of realityAs we have mentioned, sensor networks can tend togenerate event avalanches. The Anderson project atColumbia University has proposed a novel congestioncontrol mechanism, tailored to the particular problemsof sensor 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,

• 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. Therefore, again by definition, ifa relay is congested, it will have no spare buffer spaceup its sleeve. Therefore, once a relay is congested, it hasvery little room for manoeuvre, given all the data hasprobably already left the sources that caused thecongestion. All that can be done is to ask upstreamrelays to hold back data, and sources to buffer any newdata arriving ‘from reality’. Clearly though, as eventscontinue to unfold in the real world, if congestionpersists there will come a point where data has to bedropped.

We should emphasise that some messages, nomatter how tiny, might carry very importantinformation. But the importance will rarely beunderstood by the sensor or relay — often it will only bepossible to establish how important a message is onceits meaning has been extracted by the receiver16. Aswith the quality of service question in public networks,the dilemma lies between adding capacity (which willrarely be sufficient in all circumstances) and introducingcomplex prioritisation or multi-path routing schemes.Both increase the size and cost of the devices, just toprovide cover against unlikely eventualities, which maynever happen17. But catastrophes are exactly the timewhen reliable data is most required.

As messages cross the Internet at large, theseproblems can be ignored if the ‘data rate from reality’ isdwarfed by the data rate between entities in theinformation world. The latter is more elastic, so it canhold back to allow for fluctuations and avalanches ofdata from reality.

3.5.4 Delivery reliabilityHaving introduced the possibility of dropping messages(whether as a result of congestion or wireless channelfade), this leads us directly into a further challenge toconventional thinking — how does a receiver know amessage has been lost when it was not expecting itanyway?

Usually a receiver can detect a missing messagewhen a sequence of packets stops arriving, or the nextin the sequence arrives revealing a gap. Asynchronousevents are not expected by definition. The receiver cantherefore only detect a loss when the next event arrives,

15 Our current research solves these ‘slow-start’ problems by reversing theincentive structures of the Internet’s congestion control mechanisms. Apublication is in preparation.16 In the physical world, this problem is solved by transmitting informationin analogue form. For instance, an arbitrarily large volume of informationcan pass through the lens of the eye and the retina, in order to be prioritisedduring processing by the brain.17 Aggregation of data within a sensor network (see section 3.3) mightalleviate most potential congestion problems.



which may be anything from microseconds to yearslater. If using positive acknowledgement (ack) this is nota problem, because the sender can detect a lack of ack,and re-send. But if a large number of listeners want tobe informed of each event, the source can beoverwhelmed by what is termed an ‘ack implosion’.Therefore, for scalability, the pub-sub model isdeliberately arranged to hide the comings and goings oflisteners from the source. So how can the source knowhow many listeners are interested, and therefore howmany acks it should have received?

Negative acknowledgement (nack), where receiversonly complain if they miss a message, is preferred inmulticast streaming scenarios. So nacks can beaggregated on their way to the source if more than onereceiver misses a message [52] (see also section 3.3).This still leaves the above problems where no-one cannack a missed message that they were not expecting.

Our own index-based event messaging system(introduced in sections 3.2 and 3.4 in the context ofintermittent links and address aggregation) was alsodesigned to solve this problem. Because its indexesbeacon regularly, it is clear when one is missed; and theindexes list the version number of the latest message oneach message channel. Receivers can therefore nack amissed message, even being able to catch up if theyhave been disconnected for some time.

Hop-by-hop ack or nack handling can be used forreliable delivery. Cisco’s pragmatic general multicastaggregates nacks [46], while SCRIBE [19] uses the acksof a long-running TCP session between eachintermediate system. However, an early insight duringthe design of the Internet was that hop-by-hopacknowledgement did not remove the need for end toend acknowledgement (e.g. during re-routing or routerfailures) [18]. The situation is no different forasynchronous events. As we have to check delivery endto end, hop by hop is redundant — hence justifying ourchoice of beaconing indexes.

The above concerns reliable multicast deliveryacross global networks, originating from a sensor justone hop from mains power as in our straw man proposal(section 3.1). When messages arise in a multi-hopsensor network, we have already (section 3.3)recommended avoiding duplication of powerconsumption, aggregating with concast, rather thanduplicating with multicast until a node with mainspower is reached. How reliability mechanisms shouldmost efficiently span the two parts of the messagetransport in these cases is a matter for further research.

3.6 SecurityAll distributed applications require some degree of trustbetween the devices comprising the system. ElsewhereSeleznyov et al discuss an approach to allow pervasivedevices to determine whether they hold sufficient trustin their correspondents for the risk associated with theaction in hand [53]. Such systems require rudimentaryprimitives for secure communications.

Pervasive placement of computers in theenvironment breaks many traditional communicationssecurity assumptions. Most importantly, storage of keyson a device assumes the device is physically securedagainst those who do not know the key, which is not thecase for many sensor networking applications spreadliberally throughout the environment.

3.6.1 Verifiable locationHowever, many other applications of pervasivecomputing involve devices within business or residentialpremises. Recent research at UC Berkeley hasintroduced a technique to establish whether a device islocated where it claims to be [54], although a trustednode close to the device is a prerequisite. Previoustechniques without that assumption were far morecomplex [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 possible toauthenticate that a device is what it says it is, because itis located where it is meant to be.

3.6.2 Tamper-resistance and challenged hardwareIf security-sensitive devices must be subject to generalaccess, it may be sufficient to use mildly tamper-resistant casings (as in our straw man proposal insection 3.1), as long as the limitations are understood[56]. The sheer numbers of devices can be used to offersufficient protection by designing the whole system tobe resistant to compromise of a minority of devices.SPINS [57] is an example of this approach, which hasbeen implemented on Berkeley motes. It consists of twomessage security primitives — SNEP for confidentialityand µTESLA for message authenticity and integrity.Both are designed to provide strong protection despiteextremely limited hardware, ruling out asymmetriccryptography. µTESLA18 derives the asymmetry neededfor authentication from the one-way passage of time,rather than modular arithmetic. In SPINS, theseprimitives are built up into a secure sensor networksystem bootstrapped from an association with a base-station.

18 µTESLA is based on TESLA, our own joint work with Columbia University,UC Berkeley and IBM for lightweight, per-packet authentication ofbroadcast multimedia streams. It is currently in the process ofstandardisation through the IETF [58].



3.6.3 Key managementPublic key (asymmetric) cryptography requiresconsiderable computing resources, so it is consideredunfeasible on miniature devices for the foreseeablefuture. Even on high-speed computers, asymmetric keystend to only be used to bootstrap lighter weightsymmetric cryptography by exchange of a symmetrickey. Without the ability to use public keys, it is hard tobootstrap a secure system of miniature devices byauthenticating that the source of the initial keys istrusted. This is why SPINS (above) cannot bootstrap itsauthentication with any trusted identity, being limitedto having to trust the base-station owner, which itauthenticates by locality.

Stajano and Anderson [22] propose that a useful keyestablishment primitive for miniature devices would bephysical touch. That is, a master key can be establishedin a device when it is placed in contact with a motherdevice. This key cannot then be overridden by the touchof another device. Only the original mother can releasethe device from its mother’s binding, after which it canbe bound to the first new mother that touches it. Thereliance on 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 randomkeys prior to deployment. It uses the increasedprobability of any two nodes sharing common keys tobootstrap key establishment.

Once initial keys are established, key managementprocedures must be used to refresh the keys actuallyemployed for message cryptography [61], reducing thetime attackers have to guess the keys in use by brute-force methods (as in our straw man proposal insection 3.1). However, when broadcasting secrets to aconstrained group, traditional key managementtechniques developed for one-to-one communicationscannot be used, because the authorised membership ofthe group may change over time.

One approach is to assume the presence of a stableset of trusted event mediator nodes (see section 2.3).Then messages are sent to these mediators and groupmembers form a one-to-one security association withany one of these mediators. However, trust in stableintermediaries is neither generic nor necessary inpervasive computing scenarios (or across the Internet atlarge). A preferred approach is for the message to beencrypted with a group key (using that classicoxymoron, the secret shared over a large group) atsource, and remain encrypted throughout its end-to-end journey, at least avoiding sharing the keyunnecessarily with intermediate nodes. As end-pointsjoin and leave the group, the group key is changed.Moyer et al provides a useful overview of the issues in

group key management and a survey of solutions at thetime [62].

3.7 Ancillary communications servicesThroughout the paper so far, we have kept our focus onthe rudimentary functions necessary for communi-cations to realise a pervasive computing vision. Beyondthese, a richer set of ancillary communications servicesmay be necessary for each specific application — searchand discovery, group forming, session co-ordination,certification, transactional messaging, causal messageordering, and so on.

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

• bundled — functions embedded within routers andrelays throughout the messaging network (e.g. theevent mediation service19),

• unbundled — communications services separatelyprovided by third parties (e.g. event archives) or bythe joint efforts of peer end-points (e.g.authentication and confidentiality).

Both approaches are distributed, they merely differin whether the act of relaying is unavoidably bundledwith other functions or not. In the unbundled approach,relays act as common carriers, irrespective of themessages being passed.

Our instincts are to always try to design unbundledfunctions (which can then optionally be collocated withthe relaying function). But each case must be taken onits merits, and reasoned justifications given, rather thanfollowing the end-to-end design principle as a religion.We have given these reasoned arguments throughout.

But once we move from rudimentary to higher levelfunctions as listed above, there is no question that theyare best designed so that they can be separated fromthe basic networking service. In this respect, they haveless impact on network design, justifying ruling theirdetailed discussion out of this paper’s scope.

4. Business implications

4.1 Trends Over the last couple of decades asynchronousprogramming has become prevalent, at least for non-networked code local to the machine’s own bus (e.g. anevent listener is set for a mouse click event and, when ittriggers, the code checks where the mouse pointer isand calls the relevant function). This trend will extend to

19 Which may itself be an overlay network built on more rudimentaryprimitives, but it consists of message relays itself.



distributed programming, though initially through theuse of intermediary message servers rather than directpeer-to-peer remote procedure calls. As computingbecomes more interfaced to the wider physical world,we can expect distributed asynchronous programmingto become commonplace. Crowcroft envisages 1010

event messages per second world-wide [46]. We havealready explained that, if we expect trillions of devices,there will be orders of magnitude more event sourcesand listeners (section 3.4).

This warns us that the potential growth of pervasivecomputing will be dependent on the successfuldeployment of the pub-sub mode of groupcommunications, whether directly in the networkinfrastructure (e.g. as IP multicast [16]) or usingoverlays [19, 63].

4.2 The value of group forming Metcalfe’s Law predicts that the value of a network isO(n2), because each of n users has the potential tocommunicate with n −1 other users. Reed’s Law goesbeyond this, pointing out that n users20 have thepotential to create 2n different groups betweenthemselves [64], making the value of a network thatsupports 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 take in eachcase. They certainly show that a business that allowsunfettered creation of groups (‘Yahoo Groups formachines’) will tend to be popular. If growth incomputing device numbers remains exponential (thepredicted doubling time is about 0.6 years), thengrowth in group numbers will be doubly exponential,that is:

.

Or put another way, if we are to create thousands oftrillions of groups by 2020, world-wide group creationfacilities will have to have been capable of creatingmillions of groups every second.

4.3 Whose business? Which customer?If devices 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, networksof devices will be able to act as their own infrastructure.But part of the capacity of global networkinginfrastructure and all the capacity of ancillary servicesdedicated to asynchronous messaging will also berequired. Why would anyone invest in thisinfrastructure? For the public good? For private gain?What socio-economic mechanisms will cause these

prerequisites of the pervasive computing vision tohappen21?

Because the impact of each device is so small, thequestion of who is responsible for its share ofinfrastructure becomes blurred. Many assume thatinfrastructure operators will cover their costs by cross-subsidising infrastructure from higher level services. Butit is unrealistic to expect any company to be successfulenough at these very different businesses for one tosustain the other, given competition from specialists inservices for pervasive computing. So, if a washingmachine detects new fabrics in its wash-load and looksup their washing instructions over the Internet, whoshould arrange for the required infrastructure and itsmaintenance? The manufacturer? The retailer? Thehouseholder? Who should pay for the service engineerto come out to a faulty washing machine only todiscover the fault is due to the householder not payingtheir Internet bill? If sensor A is measuring light levels forone application, but also relaying for sensor B, they mayboth need global connectivity, but should relay A chargesensor B for its services?

Clearly, there will be many informal acts of give andtake over what will often be trivial issues. But many tinyacts of take without any give mount up. Solutions tothese free-rider problems must be found if the vision ofpervasive computing is to be realised22.

4.4 Pricing Assuming someone (probably not the end-user) will takeresponsibility for paying the bills for thecommunications infrastructure necessary to supportpervasive computing, how will it be priced? The casualobserver would expect event messaging services to beflat charged (irrespective of usage). Usage charging23

would incentivise responsible use of resources, but wehave seen that miniature devices already have goodreason to be parsimonious, particularly to conservebattery power.

Our intuition is that flat charging will prevailwherever pervasive computing is ‘scavenging’ resourcesprovided for other purposes (e.g. the wider Internet).But where messaging services are provided specifically,the potential sheer volume of messaging will tend toforce the introduction of usage charging.

We have also explained that many applications willbe part of vital business processes, their communi-

20 Or processes?

O 22t

21 The wider question of who will have the incentive to invest indeployment of the devices themselves is just as valid, but outside thescope of this paper.22 See ‘http://www.mmapps.org/’ for our collaborative research onmotivations in peer-to-peer communities.23 In bulk — it goes without saying that itemisation is out of the question.



cations requiring priority over more optional messagesduring surges in demand. Clearly, priority service willattract premium charging. Given priority will rarely haveto be exercised, premiums are unlikely to be levied onlywhen priority is needed (usage). Rather they will be paidregularly in advance for the right to priority as acontingency (flat).

4.5 Pub-sub business modelTraditionally, multicast has been associated withefficient distribution of streamed media, but it is alsosuitable for the timely delivery of asynchronous events.The sessions are just considerably shorter. One of thereasons pub-sub has not been widely deployed formedia distribution is the desire to re-create contentdistribution business models over it that mimic thoseused today, by both the content and the networkindustry. Specifically, they expect the distributionnetwork to charge the sender proportionately to thenumber 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 clearly notfeasible to charge for event notification messaging persession (i.e. per event), but, if pub-sub were charged flatrate, it would be hard to prevent the same mechanismsbeing used to bypass media distribution pricing.

4.6 To bundle or to unbundle?When we discussed function placement (section 2.4),we recommended that functions should not be assignedto specific equipment. Rather, we advised that thesystem should be designed open. Then, it is stillperfectly possible to bundle functions together into apiece of equipment (e.g. if a vendor believes thebusiness model is advantageous). But bundling ischosen, not inherent to the technical design.

Throughout, we have shown that there are rarelytechnical reasons to lock in even rudimentarycommunications services with the business of operatinga dumb pub-sub network24. But, despite having noinherent lock-in, we can predict that messaging serviceswill make good business for network operators in thenext few years. However, as the pervasive computingscenario develops, we predict that all, or at least most ofthese services will be self-provided more competitivelyby distributed software across the pervasive computingbase. Therefore the technology should be designed forthis transition from closed to open from the outset [65],justifying our intuition of an open design closed bypolicy choice.

5. ConclusionsWe have given controversial but reasoned explanationsfor why most pervasive computing will largely beconnected globally and for why it will rely heavily onmodels of the physical world within the informationworld. It is unfeasible to imagine that any arbitrary pairof computing devices will be able to talk directly to eachother, just because they are in physical proximity.Instead physical devices will be bound to informationmodels of themselves, which will meet in cyberspace,communications between devices taking place acrosscyberspace, as often as by direct wireless connectivity.Continuous co-ordination between the physical andinformation worlds will lead to a web of tens of billionsof messages per second across the world’s networks.

We have explained why we predict thatasynchronous event messaging using publish-subscribewill be the predominant mode of communications forpervasive computing. Pub-sub will mostly be based onthe multicast mode (whether native or overlay) oncemessages from the physical world have hit the firstgateway to the rest of the Internet (the first connectionto mains power). But, if there is a multi-hop wirelessnetwork between the physical world and that firstgateway, in order to conserve power, concast will be themost likely communications mode up to that gateway.

We have questioned the assumption that tiny cheapcomputing devices will be considered disposable andapplication-specific. Economies of scale in volumedevice manufacturing will always favour reuse of theinvestment in generic device designs, whether each unitis disposable or not. Also, the investment in deployingdevices will be higher than their cost, tending toencourage new ways to combine deployed devices tonovel ends. Therefore working out the most genericcommunications facilities for miniature devices is acentral part of the research agenda.

Having set out the grand challenge, we havesurveyed its implications on each rudimentary elementof communications — routing, addressing, congestioncontrol, reliable delivery, security, etc. We havedescribed the problems precisely and the various mainapproaches being adopted by the research communityto solve them, giving rationale. We have exploded somemyths particularly explaining why it is often moreeffective and less complex to create an x-like systemfrom un-x-like parts (e.g. a reliable system fromunreliable parts, or a secure system from insecureparts). We have also corrected some misunderstandingsthat the research community seems to have carried overfrom their previous research areas. For instance, it isfruitless to try to control congestion by varying the datarate of reality and it is fruitless to expect receivers toknow when they have missed an asynchronous

24 Message aggregation and duplication — concast and multicast — beingexceptions.



message, which by definition they were not expectinganyway.

Finally, we have introduced the implications ofpervasive computing on the business of communi-cations, explaining the trouble the commercialcommunity has with the pub-sub model andemphasising the importance of group creation services.Many open questions remain, particularly concerninghow to promote investment in pervasive computinginfrastructure, given the benefits are so thinly spread,making collection of return on investment costly, evenwith flat pricing models. We have explained why ‘openby design but closed by policy choice’ will still be theappropriate commercial approach, given communi-cations designs will still need to be generic, even thoughthe devices on which they are implemented will bedisposable.

AcknowledgementsJon Crowcroft (Cambridge University), Jane Tateson,Trevor Burbridge, Andrea Soppera, Alan Steventon (BTResearch) and the anonymous reviewers.

References1 Weiser M: ‘The computer for the 21st Century’, Scientific

American, 256, No 3, pp 94—104 (September 1991).

2 Durand A and Huitema C: ‘The host-density ratio for addressassignment efficiency: An update on the H ratio’, RFC 3194,Internet Engineering Task Force (November 2001).

3 Bulman J, Crabtree B, Gower A, Oldroyd A, Lawson M and SuttonJ: ‘Mixed reality applications in urban environments’, BT Technol J,22, No 3, pp 84—94 (July 2004).

4 Brown S, Garner P, Sixsmith A and Hine N: ‘Care in thecommunity’, BT Technol J, 22, No 3, pp 56—64 (July 2004).

5 Bull P and Payne R: ‘Pervasive home environments’, BT Technol J,22, No 3, pp 65—72 (July 2004).

6 Bilchev G et al: ‘Traffimatics — intelligent co-operative vehiclehighway systems’, BT Technol J, 22, No 3, pp 73—83 (July 2004).

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

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

9 Yokoji S, Takahashi K and Miura N: ‘Kokono search: A locationbased search engine’, in Proc Tenth International World Wide WebConference (WWW10) (May 2001) — http://www10.org/cdrom/posters/contents.html#a5

10 Buyukkokten O, Cho J, Garcia-Molina H, Gravano L andShivakumar N: ‘Exploiting geographical location information ofWeb pages’, in (Informal) Proc Workshop on Web Databases(WebDB’99), ACM (June 1999) — http://citeseer.ist.psu.edu/buyukkokten99exploiting.html

11 Shrikumar H: ‘IPic — a match head sized Web-server’, (October2002) — http://www-ccs.cs.umass.edu/shri/iPic.html,

12 Shrikumar H: ‘Connecting absolutely everything’, White PaperWP010308, Ipsil (2001) — http://www.ipsil.com/resources/whitepapers/connecting.pdf

13 Oki B, Pfluegl M, Siegel A and Skeen D: ‘The Information Bus: anarchitecture for extensible distributed systems’, in Proc 14th ACMSymposium on Operating Systems Principles (1993) — http://www.cs.utah.edu/~retrac/cs7460/infobus.pdf

14 Intanagonwiwat C, Govindan R and Estrin D: ‘Directed diffusion: Ascalable and robust communication paradigm for sensornetworks’, in Proc ACM International Conference on MobileComputing and Networks (MobiCOM’00), ACM (August 2000) —http://www.isi.edu/scadds/projects/diffusion.html#publications

15 Soppera A, Burbridge T, Briscoe B and Rizzo M: ‘GAP: The genericannouncement protocol for event messaging’, in Proc LondonCommunication Symposium (LCS’03), UCL (September 2003) —http://www.ee.ucl.ac.uk/lcs/papers2003/103.pdf

16 Deering S E: ‘Multicast routing in internetworks and extendedLANs’, in Proc ACM SIGCOMM’88 (August 1988).

17 Bacon J, Moody K, Bates J, Hayton R, Ma C, McNeil A, Seidel Oand Spiteri M: ‘Generic support for distributed applications’, IEEEComputer, pp 68—76 (March 2000) — http://www.cl.cam.ac.uk/Research/SRG/opera/publications/pre-2002.html#2000

18 Saltzer J H, Reed D P and Clark D D: ‘End-to-end arguments insystem design’, ACM Transactions on Computer Systems, 2, No 4,pp 277—288 (November 1984). [An earlier version appeared inthe Second International Conference on Distributed ComputingSystems, pp 509—512 (April 1981) — http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf]

19 Rowstron A, Kermarrec A-M, Castro M and Druschel P: ‘SCRIBE:the design of a large-scale event notification infrastructure’, inCrowcroft J and Hofmann M (Eds): ‘Proc 3rd InternationalCOST264 Workshop on Networked Group Communication(NGC’01)’, Vol 2233, pp 30—43, Springer LNCS (November 2001)— http://link.springer.de/link/service/series/0558/bibs/2233/22330030. htm

20 Soppera A and Burbridge T: ‘Maintaining privacy in pervasivecomputing’, BT Technol J, 22, No 3, pp 106—118 (July 2004).

21 Heidemann J, Silva F, Intanagonwiwat C, Govindan R, Estrin D andGanesan D: ‘Building efficient wireless sensor networks with low-level naming’, in Proc Symposium on Operating SystemsPrinciples, pp 146—159, ACM (October 2001) — http://www.isi.edu/~johnh/PAPERS/Heidemann01c.html

22 Stajano F and Anderson R: ‘The resurrecting duckling: Securityissues for ad hoc wireless networks’, in Christianson B, Crispo Band Roe M (Eds): ‘Proc 7th International Workshop on SecurityProtocols’, pp 172—194, Springer Verlag LNCS 1796 (April 1999)— http://citeseer.ist.psu.edu/227971.html

23 Briscoe B: ‘MARKS: Zero side effect multicast key managementusing arbitrarily revealed key sequences’, in Proc 1st InternationalCOST264 Workshop on Networked Group Communication(NGC’99), Vol 1736, Springer LNCS (November 1999) — http://www.btexact.com/publications/papers?doc=70250

24 Floyd S, Jacobson V, Liu C G, McCanne S and Zhang L: ‘A reliablemulticast framework for lightweight sessions and application levelframing’, Proc ACM SIGCOMM’95, Computer CommunicationReview, 25, No 4, pp 342—356 (October 1995) — http://www.acm.org/sigcomm/ccr/archive/1995/conf/floyd.html



25 Fall K: ‘Delay tolerant networking research group’, Working Groupcharter, Internet Research Task Force (2002) — http://www.dtnrg.org/

26 Fall K: ‘A delay-tolerant network architecture for challengedInternets’, Proc ACM SIGCOMM’03, Computer CommunicationReview, 33, No 4, pp 27—34 (October 2003) — http://portal.acm.org/citation.cfm?id=863960&dl=ACM&coll=portal

27 Kahn J M, Katz R H and Pister K S J: ‘Emerging challenges: mobilenetworking for “smart dust” ’, Journal of Communications andNetworks, 2, No 3, pp 188—196 (September 2000) — http://citeseer.ist.psu.edu/kahn00emerging.html

28 Zhou L, Kahn J M and Pister K S J: ‘Corner-cube retroreflectorsbased on structure-assisted assembly for free-space opticalcommunication’, IEEE Journal of Microelectromechanical Systems,12, No 3, pp 233—242 (June 2003) — http://www-ee.stanford.edu/~jmk/pubs/ccr.jmems.pdf

29 Chlamtac I, Petrioli C and Redi J: ‘Energy conservation in accessprotocols for mobile computing and communication’,Microprocessors and Microsystems Journal, 1, pp 20—32 (March1998).

30 Chockalingam A and Zorzi M: ‘Energy efficiency of media accessprotocols for mobile data networks’, IEEE Transactions onCommunications, 46, No 11, pp 418—421 (November 1998) —http://citeseer.nj.nec.com/259740.html

31 Kravets R and Krishnan P: ‘Application-driven power managementfor mobile communication’, Wireless Networks, 6, pp 263—277(2000) — http://citeseer.nj.nec.com/kravets98applicationdriven.html

32 Soppera A, Burbridge T and Nekovee M: ‘Index-based eventmessaging’, in Proc International Workshop on Large-Scale GroupCommunication (October 2003) — http://srds2003.cnuce.cnr.it/papers/soppera.pdf

33 Perkins C, Belding-Royer E and Das S: ‘Ad hoc on-demanddistance vector (AODV) routing’, RFC 3561, Internet EngineeringTask Force (July 2003) — http://www.tcs.hut.fi/~anttit/manet/aodv/

34 Tschudin C, Lundgren H and Nordström E: ‘Embedding MANETsin the real world’, in Proc Conference on Personal WirelessCommunications (TWC’03), IFIP (September 2003) — 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 Engineering Task Force (March 2002)— http://bgp.potaroo.net/ietf/old-ids/draft-baker-manet-review-01.txt

36 Singh S, Woo M and Raghavendra C S: ‘Power-aware routing inmobile ad-hoc networks’, Proc. ACM International Conference onMobile Computing and Networks (MobiCOM’98), pp 181—190(1998) — citeseer.nj.nec.com/singh98poweraware.html

37 Chang J H and Tassiulas L: ‘Energy conserving routing in wirelessad-hoc networks’, in Proc IEEE Conference on ComputerCommunications, pp 22—31 (2000) — http://citeseer.nj.nec.com/chang00energy.html

38 Madden S R, Szewczyk R, Franklin M J and Culler D: ‘Supportingaggregate queries over ad-hoc wireless sensor networks’, in ProcWorkshop on Mobile Computing and Systems Applications (2002)— htttp://www.cs.berkeley.edu/~madden/madden_aggregation.pdf

39 Cain B, Speakman T and Towsley D: ‘Generic router assist (GRA)building block; motivation and architecture’, Internet draft,Internet Engineering Task Force, (March 2000) — http://bgp.potaroo.net/ietf/old-ids/draft-ietf-rmt-gra-arch-01.txt

40 Duros E, Dabbous W, Izumiyama H, Fujii N and Zhang Y: ‘A link-layer tunneling mechanism for unidirectional links’, RFC 3077,Internet Engineering Task Force (March 2001).

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

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

43 Law Y W, Dulman S, Etalle S and Havinga P H: ‘Assessing security-critical energy-efficient sensor networks’, in Gritzalis D, DeCapitani Di Vimercati S, Samarati P and Katsikas S K (Eds): ‘Proc18th TC11 Int Conf On Information Security’, pp 459—463, IFIP,Kluwer (May 2003) — http://www.ub.utwente.nl/webdocs/ctit/1/00000087.pdf

44 Adler M, Ge Z, Kurose J, Towsley D and Zabele S: ‘Channelizationproblem in large scale data dissemination’, in Proc IEEEInternational Conference on Network Protocols (ICNP’01) (2001)— http://www.cs.umass.edu/~micah/pubs/channelization.ps

45 Thaler D and Handley M: ‘On the aggregatability of multicastforwarding state’, in Proc IEEE Conference on ComputerCommunications (Infocom 2000) (March 2000) — http://www.ieee-infocom.org/2000/papers/632.ps

46 Crowcroft J, Bacon J, Pietzuch P, Coulouris G and Naguib H:‘Channel Islands in a Reflective Ocean: Large scale eventdistribution in heterogeneous networks’, IEEE CommunicationsMagazine, 40, No 9, pp 112—115 (September 2002) — http://www.cl.cam.ac.uk/Research/SRG/opera/publications/2002-pubs.html

47 Crowcroft J, Hand S, Mortier R, Roscoe T and Warfield A:‘Plutarch: An argument for network pluralism’, in SIGCOMMFDNA’03, ACM (2003) — http://www.cl.cam.ac.uk/~jac22/out/plutarch.pdf

48 Brownlee N and Ma A: ‘NeTraMet flow lifetimes and implicationsfor routing context’, Web page (Data in and out of UC San DiegoSupercomputer Center, collected June 2000) (June 2002) — http://www.caida.org/analysis/workload/netramet/lifetimes/

49 Beverly R and Claffy K: ‘Wide-area IP multicast trafficcharacterization’, IEEE Network (January/February 2003) — http://www.caida.org/outreach/papers/2003/mcastworkchar/

50 Crovella M and Bestavros A: ‘Self-similarity in World Wide Webtraffic: Evidence and possible causes’, IEEE/ACM Transactions onNetworking, 5, No 6, pp 35—846 (1997) — http://citeseer.ist.psu.edu/22080.html

51 Wan C-Y, Eisenman S B and Campbell A T: ‘CODA: congestiondetection and avoidance in sensor networks’, in Proc FirstInternational Conference on Embedded Networked SensorSystems, pp 266—279, ACM (2003) — http://comet.ctr.columbia.edu/armstrong/

52 Speakman T et al: ‘PGM reliable transport protocol specification’,RFC 3208, Internet Engineering Task Force (December 2001) —http://www.ietf.org/rfc/rfc3208.txt

53 Seleznyov A, Ahmed M O and Hailes S: ‘Co-operation in the digitalage — engendering trust in electronic environments’, BT TechnolJ, 22, No 3, pp 95—105 (July 2004).



54 Sastry N, Shankar U and Wagner D: ‘Secure verification of locationclaims’, in Proc Workshop on Wireless Security (WiSe 2003), ACM(September 2003) — http://www.cs.berkeley.edu/~nks/locprove/

55 Gabber E and Wool A: ‘On location-restricted services’, IEEENetwork, 13, No 6, pp 44—52 (1999).

56 Anderson R and Kuhn M G: ‘Tamper resistance — a cautionarynote’, in Proc Second USENIX Electronic Commerce Workshop, pp1—21 (November 1996) — http://www.cl.cam.ac.uk/users/rja14/#Reliability

57 Perrig A, Szewczyk R, Wen V, Culler D E and Tygar J D: ‘SPINS:Security protocols for sensor networks’, in Proc ACM InternationalConference on Mobile Computing and Networks (Mobicom’01), pp189—199, (July 2001) — http://citeseer.ist.psu.edu/568886.html

58 Perrig A, Canetti R, Song D, Tygar D and Briscoe B: ‘TESLA:Multicast source authentication transform introduction’, Internetdraft, Internet Engineering Task Force (Work in progress) (February2002) — http://bgp.potaroo.net/ietf/old-ids/draft-ietf-msec-tesla-intro-01.txt

59 Juels A: ‘ “Yoking-proofs” for RFID tags’, in Sandhu R and ThomasR (Eds): ‘Proc First International Workshop on PervasiveComputing and Communication Security’, IEEE Press (2004) —http://www.rsasecurity.com/rsalabs/staff/bios/ajuels/publications/rfidyoke/

60 Chan H, Perrig A and Song D: ‘Random key predistributionschemes for sensor networks’, in Proc Symposium on Security andPrivacy, IEEE (2003) — http://www.ece.cmu.edu/~adrian/publications.html

61 Basagni S, Herrin K, Bruschi D and Rosti E: ‘Secure pebblenet’, inProc ACM International Symposium on Mobile Ad Hoc Networking& Computing (MobiHoc’01), pp 156—163 (October 2001) —http://www.ece.neu.edu/faculty/basagni/publications.html

62 Moyer M J, Rao J R and Rohatgi P: ‘A survey of multicast securityissues in multicast communications’, IEEE Network, 13, No 6, pp12—23 (1999) — http://www.comsoc.org/

63 Ratnasamy S, Handley M, Karp R and Shenker S: ‘Application-levelmulticast using content-addressable networks’, in Proc 3rdInternational COST264 Workshop on Networked GroupCommunication (NGC’01), Vol 2233, pp 14, Springer LNCS(November 2001) — http://link.springer.de/link/service/series/0558/bibs/2233/22330014.htm

64 Reed D P: ‘That sneaky exponential — beyond Metcalfe’s Law tothe power of community building’, Online supplement to article inContext magazine (1999) — http://www.reed.com/Papers/GFN/reedslaw.html

65 Clark D, Sollins K, Wroclawski J and Braden R: ‘Tussle incyberspace: Defining tomorrow’s Internet’, Proc ACMSIGCOMM’02, Computer Communication Review, 32, No 4(August 2002) — http://www.acm.org/sigcomm/sigcomm2002/papers/tussle.pdf

Bob Briscoe joined BT in 1980 and nowdirects the research programme of BT'sNetworks Research Centre. In the late-1980s he managed the transition to IP ofmany of BT's R&D networks and systems.In the mid-1990s he represented BT on theHTTP working group of the IETF and in theANSA distributed systems researchconsortium, which led to the creation ofthe OMG and CORBA.

In 2000 he initiated and was technicaldirector of the Market Managed Multi-service Internet (M3I) consortium, a suc-

cessful European collaborative project investigating the feasibility anduser acceptability of controlling Internet quality on fast time-scalesthrough pricing.

His published research, standards contributions and patent filings arein the fields of loosely coupled distributed systems, scalable networkcharging and security solutions (especially multicast), managing fixedand wireless network loading using pricing and on the structure ofcommunications markets. He is also studying part-time for a PhD atUniversity College London.

The Implications of Pervasive Computing on Network Design

Documents

Transcript of The Implications of Pervasive Computing on Network Design