deapspace – transient ad hoc networking of pervasive devices

DEAPspace ± Transient ad hoc networking of pervasivedevices

Reto Hermann *, Dirk Husemann, Michael Moser, Michael Nidd,Christian Rohner, Andreas Schade

IBM Research Division, Zurich Research Laboratory, S�aumerstrasse 4, CH-8803 R�uschlikon, Switzerland

Abstract

The rapid spreading of mobile computerized devices marks the beginning of a new computing paradigm charac-

terized by ad hoc networking and spontaneous interaction, taking place transparently to the human user. The

DEAPspace project described in this paper aims at providing a framework for interconnecting pervasive devices over a

wireless medium. It supports the development of new proximity-based collective distributed applications. In this paper

we discuss the motivation of the project and describe possible new application scenarios from which requirements for

both the supporting framework and the underlying wireless medium are derived. Central research issues such as a new

push-model-based approach to fast and resource e�cient service discovery, and encoding and match-making of

compact service descriptions, are elaborated in more detail. The paper also describes some related work and concludes

with a critical review of existing wireless communication technologies, followed by a description of the current state of

our project and an outlook on future research directions. Ó 2001 Elsevier Science B.V. All rights reserved.

Keywords: Transient ad-hoc networking; Proximity based networking; Service advertising; Service discovery; Distributed service

discovery; Push model; Peer-to-peer communication; Service description; Multi-device applications; Bluetooth; IEEE 802.11; IEEE

802.15; HomeCast OpenProtocol

1. A world of connected devices

Most of the things we deal with in our day-to-day life are invisible from a computer science pointof view ± they either do not even contain a mi-croprocessor or they do not o�er an interface tothe outside world, let alone communicate withother devices. Nevertheless, we already are sur-rounded by a host of devices containing a micro-processor of some sort. Moreover, we increasinglyencounter devices that not only contain an em-

bedded controller or system but in addition pro-vide an interface for exchanging data with otherdevices. It does not take a lot of imagination tocome to the conclusion that we are on the road toa world of devices that are not only controlled by amicroprocessor but also are capable of exchanginginformation with other devices through some kindof interface:· already we carry with us GSM phones, personal

digital assistants (PDAs), digital watches, andother wearable devices;

· very few o�ce environments survive without acomputer, printer, or network;

· modern cars increasingly rely on computers notonly to control the operation of the car itself but

Computer Networks 35 (2001) 411±428

www.elsevier.com/locate/comnet

* Corresponding author. Tel.: +41-1-724-8573.

E-mail address: [email protected] (R. Hermann).

1389-1286/01/$ - see front matter Ó 2001 Elsevier Science B.V. All rights reserved.

PII: S 1 3 8 9 - 1 2 8 6 ( 0 0 ) 0 0 1 8 4 - 5

also to provide additional services such as navi-gation, communication, and entertainment;

· in our homes we use computerized devices tocontrol our home appliances, to entertain us,and to patrol our property;

· and sensors that provide data about ourselvesand our environment pop up everywhere.Concurrently to the microprocessor pervasion,

wireless radio communication technologies (suchas Bluetooth or IEEE 802.11) become availablethat are ®rst steps towards environments in whichcommunication is no longer wire-bound and eachdevice can cheaply communicate with other de-vices over some form of radio technology. Thecombination of information appliances with thesewireless networking technologies enables an entirerange of new applications and usage scenarios.

The DEAPspace project aims at providing aframework for interconnecting pervasive devicesover wireless communication technologies. Usingthis framework, devices that are in proximity toeach other can form ad hoc transient alliances tocreate new types of collective distributed applica-tions. To accomplish this goal, the followingquestions have to be answered. How can we ®ndout about the information available and the ser-vices that devices o�er? What kind of applicationsbecome possible? Can we provide a framework ofbuilding blocks for developing such applications?A particular focus of our work is on proximity-based networks and mobile nodes; in this context weneed to ®nd out about available services in a fastmanner as communication relationships are po-tentially of rather short duration.

In the following sections we present a set ofapplication scenarios that capture the scope ofDEAPspace and, based on these scenarios, de-scribe the requirements, challenges, and goals ofour research and brie¯y discuss how our workcompares with existing, related research projects.The main part of our paper describes the under-lying service model and our approach to servicedescription, followed by a presentation and dis-cussion of the DEAPspace service announcementand discovery protocol. After a discussion of theexisting wireless communication technologies andtheir suitability for transient ad hoc networking,we conclude the paper by describing the current

state of our work as well as future research di-rections.

2. Application scenarios

As a basis for discussion we present three ap-plication scenarios. The ®rst scenario illustrates amultidevice application where several devicesrender one virtual application. The second sce-nario is centered around a personal informationmanagement (PIM) application; here we useDEAPspace technology to hide data synchroni-zation. The third and last scenario illustrates acontext-aware application.

The ®rst scenario describes a multidevice appli-cation. Alice wears a digital wristwatch, carries anultra-modern PDA containing not only the usualPDA applications (such as date book, addressbook), but also an attached MP3 player with aheadset including a microphone. In her backpackshe carries her GSM phone. With current tech-nology, when a phone call comes in, her GSMphone will start ringing, and all Alice can do iseither take down her backpack, open it, look forthe phone, check the phone to see who is calling,and decide whether to take the call, or she can justignore the call and hope that whoever is callingwill leave a message on the answering serviceprovided by her network operator.

With DEAPspace technology, her GSM phonediscovers her digital wristwatch and notices that ito�ers an alarm service, a limited display service,and an input service (the wristwatch has two but-tons). Instead of ringing in the backpack, the GSMphone invokes the alarm service of the digitalwristwatch, then the display service of the watch todisplay the number of the calling party, and theinput service of the watch to wait for Alice to ac-cept the call. Alice now merely has to glance at herwatch to ®nd out who is calling and then press oneof the two buttons of the wristwatch to either ac-cept the call or ignore it. As the phone call is fromBob, her manager, she decides to accept the call.The GSM phone in the meantime has found outthat her MP3 player o�ers a voice output and in-put service; as soon as Alice has accepted thephone call through her wristwatch, the GSM

412 R. Hermann et al. / Computer Networks 35 (2001) 411±428

phone connects with the MP3 player, and Alice istalking to Bob.

The second interesting scenario describes ahidden personal information management applica-tion. PIM refers to a set of applications such ase-mail, address book, calendar, to-do or task lists,shopping lists, user preference pro®les, which aretypically jointly hosted on organizers, PDAs, lap-tops, and/or desktop computers. For the end-user,synchronization of the information across all de-vices becomes increasingly cumbersome and a taskin its own right. Wireless radio-based communi-cation technology can remedy the situation be-cause it can make the synchronization implicit,thus ``hiding'' it from the user. The followingscenario illustrates this transparency.

Bob has just left his home and is driving towork when his phone indicates with a beep thearrival of a message. His wife asks him to buysome ¯owers and bring them to dinner at hismother-in-law's place tonight. Whereas Bob mightwell forget the task after a day's worth of work, herests assured that he will be reminded because hisphone has transferred the appointment message toboth his PDA and his wrist watch. In the o�ce heswitches on his desktop computer and startsworking through a full inbox of e-mails. Suddenly,a pop-up window alerts him that there is a con-¯icting calendar entry. His secretary has scheduledthe video broadcast of the CEO's annual kicko�speech and it happens to collide with his wife'srequest to shop the ¯owers. As Bob is well versedin the ``We've had an outstanding year, but thisdoes not mean that . . .'' speeches, he decides toskip that speech and instead take care of the¯owers as promised. Later that afternoon, while heis engaged in a lively discussion in one of his col-league's o�ces, the alarm on his wrist sounds, re-minding him to leave for the ¯ower shop.

The third scenario involves those situationswhere we could pro®t from context-related infor-mation and describes a context-aware application.Already today, information kiosks supply visitorsof exhibitions, museums, entertainment parks,malls, stations, airports, etc. with location-depen-dent information. Whereas now visitors must walkup to these kiosks to collect the information onpaper, radio-based communication technology al-

lows information kiosks to propagate informationto the person's information appliance. As the ki-osk detects the information appliance within radiorange, it tries to obtain user-speci®c context in-formation (age, gender, origin, etc.) and pushes thetailored information to the appliance. The arrivalinformation in the appliance may then issue analert to the user or, alternately, the informationmay simply be cached in the appliance with someadequate time-to-live. Let us look at an airportscenario in more detail.

Alice is driving to the airport to leave for abusiness trip when her car information systemalerts her of a tra�c jam on the route to airport.Unfortunately she cannot take another route and,thus, there is nothing she can do to avoid beingheld up. Alarmingly late she ®nally arrives at theairport car park, leaves her car and rushes to theelevator. While she is traveling to the departure¯oor, the airport passenger information systemreads out the ticket details from her e-wallet.While still in the elevator, Alice's attention isdrawn to her wristwatch by its alarm indicating thearrival of a message. As she hurries towards thedeparture hall, she reads on display of her watchthat she is to proceed directly to gate A37. Si-multaneously the security guards at the entrance toterminal A are alerted to her late arrival. As shewalks up to the checkpoint, they give her expeditedtreatment. Bypassing the queue, she passes thecheckpoint and proceeds to the gate where thehostess is already waiting for her. Minutes latershe is seated in the plane, breathless and thinkingthat perhaps taking the subway would not havebeen such a bad idea after all.

3. Requirements, challenges, and goals

Using these scenarios we can extract a set offeatures that de®ne the scope of our DEAPspacework. A key feature is that applications can spanmultiple information appliances; that is, they aredistributed. Moreover, we target a wide range ofappliances: from small devices (such as a wrist-watch) to large devices (such as the elevator in theairport scenario); from devices designed to ac-complish a single function particularly well to

R. Hermann et al. / Computer Networks 35 (2001) 411±428 413

devices that combine multiple functions in one box± DEAPspace intends to be pervasive.

Another key feature illustrated in the previousexamples is hidden computing: the consumer isunaware of the applications executing. Applica-tions engage with one another triggered by certainevents such as the presence of a certain device in anenvironment. Applications may alert the user oncea result has been obtained, or cache the result forlater retrieval by the user. Related to hiddencomputing is another feature shared by our ex-ample applications, namely, spontaneous interac-tion. Interaction with a peer device is triggered bythe discovery of the device and its services. Next,appliances should be able to engage in applicationtransactions irrespective of whether they have metbefore; that is, we expect an ad hoc style of com-munication and application interaction. Tying inwith the ad hoc requirement is the desire to havetrue peer-to-peer communication without requiringa master to be present (nor should a master elec-tion process have to take place).

Then, proximity-bound computing and transientcommunication relationships are key features exem-pli®ed by our scenarios. The limited radio range ofthe wireless communication technology employedby the appliances is used to establish spatial context(i.e., proximity). As we are dealing with mobileusers and mobile devices, communication relation-ships will be of short duration determined by therange of the wireless communication technologiesand the (relative) velocities with which devicesare moving through this range. Relative mobilityof devices can make this period arbitrarily small.

Also, applications will involve various mediatypes, possibly including audio, images and evenvideo data; thus, we need to be able to deal withmultimedia data.

As the transient communication relationshipfeature is frequently overlooked when evaluatingwireless communication technology let us illustratethis point in more detail. Assuming a mobile sce-nario with relative device velocity v and a wirelessrange r, the maximum time available for the ap-plication transactions to complete called interac-tion window tW, is given as tW � 2r=v. Table 1illustrates the duration of the interaction windowsfor various mobility situations.

The execution of an application comprises anumber of activities, each adding to the total ex-ecution time tE required. These activities includediscovering a peer device or an existing network,creating or joining a network, discovering (all)peer application entities (i.e., service discovery),connection establishment (including parameternegotiation), transaction execution, and ®nallydisconnection.

Clearly, the following equation must hold:

tE < tW � 2r=v:

The primary goal of the DEAPspace researchproject is the development of suitable algorithmsand formats (where necessary) and the imple-mentation of a ready-to-use framework for build-ing applications. Research issues that we haveidenti®ed include prompt service discovery with-out a central service discovery server, compact andextensible service description, security in pervasivead hoc networks, con®guration and managementof a large number of devices, new applicationmodels such as multidevice applications, and alsowireless communication technology. To arrive atan experimental platform as soon as possible, weconcentrated in a ®rst step on service discovery,service description, and wireless communicationtechnology.

Table 1

Interaction window tW for various mobility situations

Mobility situation Wireless range

Description Velocity 10 m 20 m 30 m

Person moving slowly 1 m/s 20 s 40 s 60 s

Person moving quickly 4 m/s 5 s 10 s 15 s

Two persons crossing slowly 2 m/s 10 s 20 s 30 s

Car moving slowly 50 km/h 1.44 s 2.88 s 4.32 s

Two cars crossing slowly 100 km/h 0.72 s 1.44 s 2.16 s


4. DEAPspace service model

The DEAPspace service usage model is rolebased. An entity providing a service that can beutilized by other requesting entities acts as a pro-vider. Conversely, the entity requesting the provi-sion of a service is called a requester. To provideits service, a provider in turn can act as a requestermaking use of other services.

DEAPspace forms a distributed system; that is,requesters and providers can live on physicallyseparate hosting devices. In terms of service usage,however, the location of an entity is transparent toits partners. A service provided on the same deviceas the requester would be used as if it were a re-mote service.

Regardless of its particular role, an entity con-ceptually provides at most two interfaces, an inputand an output interface. Each of these interfacesrequires or emits data in particular formats. Anentity (e.g., a microphone) that only provides anoutput interface acts as a data source from thepoint of view of the DEAPspace system. Con-versely, a data sink is an entity that provides onlyan input interface (e.g., a speaker or a beamer). 1

An entity acting as a provider accepts data in aset of di�erent formats at the provider interface.Conversely, a requester can emit a set of di�erentdata formats through its requester interface. Aprovider satis®es a requester if the provider inter-face matches the requester interface. Two inter-faces match if their data format sets are notdisjoint; that is, there exists at least one data for-mat that can be used to connect the two interfaces.

As depicted in Fig. 1, provision of a service istriggered by sending data in a supported format ffrom the requester interface ir of a requesting entityto the provider interface ip of a satisfying provider.

Communication between a requester interfaceand a provider interface can be bi-directional. Thisis the case if the data format in use is coarsegrained and refers to a protocol such as FTP orSMTP consisting of di�erent primitives.

The roles that entities in DEAPspace can as-sume are similar to those found in other models ofdistributed systems such as RM-ODP [11], COR-BA [13] or DCOM [2]. The main di�erence is thatthe DEAPspace service usage scheme also allowsstreaming of data, and is therefore more generalthan the request-based mechanism of remote op-erations in object-oriented distributed systems.

Note that with DEAPspace the communicationmedium chosen to announce a service need notnecessarily be the same as the communicationmedium used to invoke a service; for example, adevice can choose to announce a service using aradio-based technology, while service invocationcan only occur via infrared.

5. Compact service description

Service advertising and selection depend di-rectly on the service description format. This isimportant in two aspects:1. On the service provider side, the service descrip-

tion format determines the precision for servic-es advertisements.

2. On the requester side, the service descriptionformat determines the selection capabilities forchoosing a matching service o�er.When a provider advertises its services, de-

scriptions of the services are encoded for distri-bution to potential users. A requester receives anencoded description of an available service, de-codes it, and can then decide to use the serviceo�ering based on its description.

Service descriptions have to meet di�erent, tosome extent even contradictory requirements. Onthe one hand, the requirement for precise serviceadvertising and matchmaking, for instance, advo-cates complex service description formats. On theother hand, there is a requirement for e�cientencoding and decoding of service descriptions that

1 Sources and sinks can o�er management interfaces through

which their normal operation can be controlled. These man-

agement interfaces are of course input interfaces.

Fig. 1. Communicating DEAPspace entities.


suggests using simpler data formats. The followingrequirements have been identi®ed as being im-portant to the DEAPspace platform:· Service description formats must accommodate

all information necessary to select suitable ser-vices allowing a ®ne-grained selection.

· The encoding scheme must generate small mes-sages e�ciently to preserve bandwidth.

· The coding of service descriptions must be sim-ple and e�cient to keep the size of the encodingand decoding modules (codecs) small.DEAPspace assumes a very basic model of

service usage in which services provide and/or ac-cept data for processing. Therefore parts of aDEAPspace service description represent the ser-vice input and output in terms of acceptable andproduced data formats, respectively. This generalmodel allows both stream-based and message-based service deployment.

Fig. 2 illustrates the general idea behind theDEAPspace service description format. Each ser-vice has a short identi®er (Name), a set of serviceattributes (Service-attr), an optional set ofacceptable input formats (Input-format), anoptional set of output formats (Output-for-mat), and also an optional detailed informationpart (Details).

The DEAPspace service description formatdi�erentiates between mandatory and optionalservice attributes. While the mandatory attributes(e.g., service address) ensure that all advertisedservices can be utilized, the optional part (e.g.,quality-of-service characteristics) allows serviceproperties to be further quali®ed.

As no assumptions can be made as to whichservice types will be available in a DEAPspacesystem, the DEAPspace services description for-mat can be used to describe arbitrary services.Format types are represented in a hierarchical

form in which speci®c subtypes are derived fromcommon supertypes. For e�cient encoding anddecoding, some standard format types are alreadyknown to the DEAPspace system. At any node,this type tree can be extended with application-speci®c derivatives.

5.1. Service description data structure

DEAPspace services are speci®ed as a data hi-erarchy. The root node of this hierarchy is theDSService class. As depicted in the listingbelow, instances of this class contain the name ofthe service, a ServiceAttribute object, twoFormatType objects, and an array of Name-

ValuePair objects ± the Details part ofFig. 2. 2

The ServiceAttribute object representsmandatory descriptive information about the ser-vice, such as some security-related informationusing the SecurityAttribute class, the fee(Fee) for using the service, and the service address(DSNetworkAddress). As a DEAPspace systemcan communicate using di�erent communicationprotocols, a DEAPspace address is represented by

1 DSService ::� Name

2 ServiceAttribute

3 InputFormat

4 OutputFormat

5 NameValuePair*.

6 InputFormat ::� FormatType.

7 OutputFormat ::� FormatType.

Fig. 2. DEAPspace service description format.

2 Note that the extended Backus±Naur form (EBNF) listings

of the service description format shown in this section are not

complete.


an abstract class DSNetworkAddress. From thisclass all concrete network address descriptionclasses are derived, such as IPNetworkAddressfor the IP protocol or BtNetworkAddress forBluetooth addresses.

8 ServiceAttribute ::� Security

AttributeFeeDSNetworkAddress:

The two FormatType objects in the DSSer-

vice class describe the input and the output for-mat of a DEAPspace service. The description ofservices acting as data sources in a DEAPspacesystem contains a null value for the input formattype indicating that they do not accept any inputfrom other DEAPspace services. Conversely, ser-vices that act as data sinks for the DEAPspacesystem carry a null output format type in theirservice description, indicating that the service doesnot produce any output that is useful to otherDEAPspace services.

Format types are represented in a hierarchicalmanner, ranging from abstract format types tomore speci®c ones:

9 FormatType ::� DSoidCompFormatType � :

DEAPspace provides an identi®cation schemefor format types that is based on quali®ed nodenames in a tree. Each format type is associatedwith an identi®er component that is unique rela-tive to the supertype. A particular format type isidenti®ed by concatenating all identi®ers from thetree's root along the path to the type node. Thisscheme is a generalization of the two-level-MIMEs, similar to the concept of object identi®ers(OIDs) known from ASN.1 [9].

Each format type level is associated with aDSOIDComp object that describes an entity similarto an OID component. This OID component ob-ject either represents a standard format type(standardized within the DEAPspace framework)or the name of a proprietary extension possiblyknown only to some recipients of the service de-scription object.FormatType descriptions allow the inclusion

of a list of next-level format type descriptions inaddition to the DSOIDComp object. Standardformat type classes (e.g., ImageFormat, Ap-

plicationFormat, SoundFormat) have beende®ned as re®nements of the abstract Format-Type class. Thus, speci®c format types can bespeci®ed by appropriately arranging instances ofthose standard classes; for example, we representthe MIME type application/postscript through anApplicationFormat object that contains anAppPostscriptFormat object in its list ofsubformats. Speci®c properties of the concreteformat type are described on the correspondinglevel (e.g., the postscript version and releasenumber as well as color or monochrome post-script). The advantage of this approach is that aseries of format type speci®ers can be folded intoone.

The list of NameValuePair objects in a ser-vice description represents optional informationused to di�erentiate further services. DEAPspacedoes not impose a particular structure on this kindof information ± it is merely a sequence of namevalue pairs (both as byte arrays) with an associatedtype indicator enabling type-speci®c comparisonoperations. A recipient will usually have someexpectation as to what the optional service de-scription part conveys.

5.2. Coding service descriptions

The way encoding in general works is straight-forward. The service description hierarchy is tra-versed and the information found in any of thenodes transformed into a serialized representation.Decoding is the reverse operation, in which theoriginal data hierarchy is reconstructed from theserialized form.

As the encoder can use application-speci®cformat types, the decoder may receive informationthat it is unable to process. For these cases,DEAPspace provides opaque decoding, which al-lows unknown format types to be read. While thedata cannot be used locally, it can be passed on ``asis'' to another entity that may understand it. Thedecoding procedure skips the unknown formattype, and re-synchronizes with the byte streamafterwards.

DEAPspace services can accept or emit multi-ple, in most cases similar format types. Normalencoding of those service descriptions would result


in carrying redundant information: The top-levelformat type would be the same, merely thesublevel format would di�er. To avoid thisredundancy DEAPspace encoding allows sharingof top-level format types where only the sublevelsdi�er, and accomplishes better compression thanmethods that traverse a service description asprescribed by the type hierarchy.

We have investigated ®ve of the most commonencoding methods: ASN.1 BER and DER en-coding [10], XML [19], WBXML [18], Java seri-alization, and XDR [15]. None of them showsgood results when viewed in terms of our opti-mization targets, codec size and message size.ASN.1 generates the shortest message, yet entailsthe largest codec module size. XML containsmuch overhead compared to payload data, andoptimum WBXML is di�cult to generate, re-sulting in large codecs. Using Java serializationwe arrive at small codecs but also at the largestservice description messages in our evaluation.XDR is a rather poor compromise as neither itscode size nor its message size is particularly good.As a benchmark exercise we therefore decided todevelop a DEAPspace-speci®c data-driven en-coding and decoding scheme. The main reasonfor this is that all common encoding methods donot allow sharing format type information at thehighest possible level. An encoding proceduresensitive to the structure of the data to be en-coded will therefore always produce better re-sults.

The DEAPspace encoding scheme is charac-terized by the following features:· All data types are byte-aligned; encoded data

(with the exception of booleans) will only takeup as much space as absolutely necessary.

· Service descriptions are hierarchically structureddata types that share information at the highestpossible level.

· FormatType data are encoded in a post-orderfashion: ®rst those parts that di�er, then thosethat are shared; for each level speci®c end mark-ers are used.

· The decoding algorithm skips unknown dataformat types, and resynchronizes with the nextknown upper-level format type using the endmarker corresponding to the item to be skipped.

6. DEAPspace service discovery

Two assumptions characterize the bulk of ex-isting service discovery protocols: that some stablenode exists on which a central server can be in-stalled, and that low round-trip times can usuallybe expected. Both of these assumptions are nolonger valid in our target environment, thus a newprotocol is needed.

A centralized system, such as DHCP [5] or Jini[17], provides a simple and robust mechanism forservice lookup (once the server has been located).In wired networks, it is reasonable to expect thatservices like a DHCP server are provided by thesame organization that maintains the physicalequipment; ad hoc groups cannot be expected toprovide such infrastructure. An ad hoc group maybe formed by any two (or more) devices that comeinto proximity with one another, therefore guar-anteeing at least one server in such an arbitrarygroup requires that almost all candidate devices berunning that server. In addition to the increasedoverhead resulting from this practice, such routinedeployment of servers means that groups wouldregularly be formed with more than one server as amember. In this situation, maintaining a central-ized approach would require servers to exchangestate, and to elect which server is to represent thediscovery protocol in each ad hoc group every timethe network recon®gures itself. If devices can bemembers of more than one network, the scenariobecomes increasingly complicated.

The second assumption that we must give up isthe expectation of low round-trip times. The con-sequence of this assumption has been reactiverather than pro-active systems as these conservebandwidth. However, if in a decentralized systemthe members do not pro-actively cache informa-tion about their environment, every service requestmust be transmitted to all group members.Broadcasts in wireless networks are often sched-uled to allow power-saving modules to wake up,and therefore o�er slow response time. Further-more, because reliable broadcast is di�cult, re-quests must be repeated, further increasingresponse time. In this environment, the delayproblems outweigh the advantages of reactivesystems, and a pro-active solution is preferable.


Pro-active discovery necessarily involves somespontaneous actions on the part of the devicesinvolved. Scheduling of these actions can broadlybe categorized into regular and slotted advertise-ments. Examples of systems with regular adver-tisements include Appletalk [1] and HIPERLAN[6], in which devices send periodic beacons sched-uled independently by each device. An example ofslotted advertisements is 802.11 [8] in which de-vices contend for each occurrence of a well-de®nedbeacon slot. The similarity between these catego-ries is that they both require a new member of thegroup to be present for at least as long as themaximum time between broadcasts for all othermember devices before the new device has acomplete view of the available services. This re-quirement means that if devices are to have a viewof their environment no more than 10 s out ofdate, then all devices must broadcast their serviceo�erings at least once every 10 s. When the in-formation being shared are only addresses, as with802.11, or is on a mostly static, high-bandwidthnetwork, like Appletalk, this trade-o� betweentimeliness and bandwidth is not a problem; inwireless, transient ad hoc networks, it poses aproblem. Because regular advertisements put anunbounded demand on broadcast packets, andslotted advertisements cause the expected time fordiscovery to grow linearly with the number ofdevices present, a hybrid solution is necessary.

6.1. DEAPspace algorithm

We have established that in some situationseach device should build a timely picture, or``world view,'' of the services o�ered in its area.One example of where this is helpful is a group offour devices, each o�ering some set of services.What each device would ideally do is to make areliable broadcast to the other three, constructinga current world view for each device. Aside fromthe complexity of reliable broadcast under normalconditions, this approach carries with it the riskthat an individual device might not even be certainwhich other devices are present to receive its ad-vertisement, or when that set changes.

To solve this, we propose that devices broad-cast their entire world view. If all listening devices

incorporate new elements found in each broadcastinto their own views, then occasionally missing abroadcast will not cause signi®cant problems forany particular device because the next broadcastby any device that did not miss the ®rst one willrepeat (and update) the same information. In thisway, we obtain reliability through continuedrepetition. Also, as each device revises the con-tents of the world view before repeating it, theinformation undergoes a constant slow alteration.It is the awareness of time that separates this al-gorithm from typical gossiping approaches. In-formation must not only be shared, but also betimely.

The following is a general outline of devicebehavior in a DEAPspace network. Embellishedletters are used to connect a rule to its use in thesample implementation of Fig. 3:1. Each node maintains a list of service descrip-

tions.2. Nodes participate in the advertising of services

by a broadcast mechanism.3. A service is described by a service description

that includes at least· a time-to-live,· the address of the node o�ering the service.

4. The broadcast mechanism works as follows:· Broadcasts are scheduled to occur within reg-

ularly recurring time windows, with one nodebroadcasting in each window. ( A

· The broadcasting node is determined by arandom back-o� mechanism. ( B

· Nodes that see one of their service descrip-tions about to time out increase their chanceto broad-cast by choosing a shorter randomback-o� time. ( C

· Before broadcasting its list, a node re-initializ-es the time-to-live value of its local servic-es. ( D

5. Each node processes a newly received servicelist in the following way:

· It combines the received list of (remote) ser-vices with the set of its own (local) servic-es. ( E

· It updates the time-to-live values of the re-mote services. ( F

In order to give a sample implementation, somecon®guration information must be decided. The


following values are used in Fig. 3 and in lateranalysis:· Time-to-live values are reset to a maximum val-

ue NormalExpiry.· Normal broadcast timeouts are taken from

range X.· Short broadcast timeouts, used when a device

sees one of its own services missing or aboutto expire, are taken from range X 0 strictly lessthan X. In this case, ``about to expire'' is de®nedas having a time-to-live value less than MinEx-piry.Ranges rather than constant values are used for

timeouts because the receipt of an advertisementresets the transmit timer in every device, thereforewithout a random jitter in the setting of the timerall devices would broadcast together. Aside fromcausing possible problems at the physical level, thiswould defeat the goal of the algorithm: reductionin the number of broadcasts from each individualdevice.

If this approach seems reminiscent of pro-activeroute discovery protocols for ad hoc networks,then it is because of the similar goals: route dis-covery is the special case of service discovery inwhich all services are adjacency tables. Not sur-prisingly, for reasons similar to those used as de-sign points for DEAPspace, the route discovery

protocols associated with many ad hoc networkingspeci®cations also use pro-active systems. Usingthe slotted and regular categories de®ned above,we will now compare the performance of alterna-tive solutions with that of DEAPspace for a sim-ilar payload.

6.2. Timeliness

For a fair comparison of timeliness, it isimportant to use con®gurations that cause com-parable network tra�c. Thus, timeliness compar-isons will be made under conditions where theDEAPspace algorithm sends one broadcast (typi-cally having n entries) about once for every nbroadcasts (having one entry each) of the regularalgorithm. There is some overhead associated withsending a broadcast packet, at the least a packetheader containing a broadcast address, and we canapproximate this overhead as being about thesame as that caused by the timestamp required foreach entry in DEAPspace, justifying this equiva-lence. Let us now measure network load in termsof advertisements per second, where one adver-tisement describes one device's capabilities.

As we assume that service discovery is imple-mented above an existing protocol, we expectpackets to be delivered correctly or not at all (i.e.,

Fig. 3. Sample pseudo-code implementation of the DEAPspace algorithm.


no bit-errors will occur). This, combined with theabove load assumption, means the o�ered loadwill be about the same for regular, slotted, andDEAPspace discovery [12].

The time for acquisition (discovery) of availableservices is improved with DEAPspace becausemore information is being transmitted when onedevice broadcasts its world view than when eachdevice broadcasts its own information. The addi-tional information transmitted is the feedback tothe member devices about what is known aboutthem by at least one other member of the network.

For both slotted and regular broadcast classesof advertisement schemes, a period T can easily beestablished for the expected time between adver-tisement repetitions. Suppose we want to tuneparameters to perform well with 10% (uncorre-lated) packet loss probability and groups of up tosix devices. It is now informative to consider whathappens when the sixth device encounters an ex-isting group of ®ve others. For the sake of sim-plicity, only a regular scheme is shown here. Ingeneral, regular schemes o�er faster discovery thanslotted ones, so this is a reasonable comparison.

Some quick math shows that the probabilitythat all ®ve correctly receive the ®rst broadcast is�1ÿ 0:1�5 � 59%, by the second broadcast, it is�1ÿ �0:1�2�5 � 95%, and after three broadcasts, itis 99.5%. In the other direction, the new device willlearn about all ®ve existing devices with the sameprobability, except it will usually take slightlylonger for all devices to have had a turn atbroadcasting.

Now consider DEAPspace under the sameconditions. Let us de®ne the newly arriving deviceas A, the group of ®ve devices already in steadystate as G, and particular members of G as Gi.Notationally, let us refer to the average valueschosen from X and X 0 by a single device as X andX 0; respectively, and the average lowest valueschosen from X and X 0 out of ®ve choices as ~X and~X 0; respectively. For simplicity, assume the rangeof X (Xmax ÿ Xmin) to be less than X 0min, so a latetransmission will always occur before a new roundstarts.

Initially, both A and G broadcast periodically,with independent periods. Once they have comewithin range of each other, either A or some Gi will

transmit ®rst. Under ideal conditions withoutpacket loss, one will transmit, the other will receivethe transmission, choose a timeout from X 0,transmit next, and that transmission will also bereceived, resulting in all devices having an accurateworld view. With 10% packet loss, this will succeedin only about 0:9� 0:95 � 53% of the cases andcan be expected to take about 1

3X � X 0 time. 3

This behavior is con®rmed by the simulationresults shown in Fig. 4, which compares theprobabilities of event E � {all devices have anaccurate world view} as a function of time for theregular and the DEAPspace algorithm. The resultshave been obtained with 10,000 simulation runsassuming 10% packet loss. The parameters forthe DEAPspace algorithm were chosen as X ��12; 15�, X 0 � �4; 5�, NormalExpiry � 115 s, andMinExpiry � 15 s, resulting in average time be-tween advertisements of 8.16 s. The advertisementperiod of the regular algorithm was chosen equalto this average of 8.16 s to make the comparisonfair in terms of network load. Observe the goodagreement of the simulated DEAPspace curve andthe analytically derived intersection of ordinate13X � X 0 � 9 and abscissa P �E� � 0:53. Moreover,

the DEAPspace algorithm achieves the E at aboutthe same rate as the regular algorithm.

To analyze the remaining 47% of the cases, letus consider ®rst some properties of the environ-ment under consideration:

3 The expected minimum for two random variables uniformly

distributed on [0,1] is 13, so the expected time until either A or

G broadcasts is about 13X (actually slightly less because the

expected period for G is ~X < X ).

Fig. 4. Probability PfEg � Pfall devices have an accurate worldviewg as a function of time for the DEAPspace and the regular

algorithm.


· At least one member of G will virtually always(1ÿ 0:15 � 99:999) hear a broadcast from A (as-suming that loss is independent), but all mem-bers of G will hear any particular broadcastfrom A only about 0:95 � 59% of the time.

· In general, if a device does not receive a trans-mission, it will be the next to transmit becauseit will not reset its timer. (The exceptions to thisare infrequent, so we ignore them for now.)

· During time Xmax following a transmission byany device, all devices will have either sent or re-ceived another transmission.As long as A fails to receive the broadcasts from

G, it will continue to broadcast its own local listwith a period of X . Each of these will trigger atleast one member of G to choose a timeout fromX 0, and send its own list. Some Gi that did notreceive the broadcast from A might broadcastearlier, but some member of G will certainlybroadcast its list within time X 0max of the broadcastfrom A. This implies that the DEAPspace algo-rithm allows G to discover A at about the samerate as the regular algorithm does (about one try

per round) but allows A to discover all of G fasterthan the regular algorithm does, because therounds automatically shrink while the environ-ment is changing. This behavior is illustrated inFig. 5, which compares the probabilities of theevents E1 � G has discovered A and E2 � A hasdiscovered G as a function of time for the regularand the DEAPspace algorithm. The simulationparameters are identical to those given for Fig. 4.

The discovery behavior can be considerablyimproved if the underlying physical layer canprovide a trigger indicating that a device has``joined'' a network (e.g., when it has synchronizedwith the spreading sequence of a spread-spectrumsystem and the MAC layer has been enabled).Fig. 6 shows the behavior of the algorithms withand without trigger. The regular scheme bene®tsfrom the shorter time for G to discover A, but hasexactly the same time for A to discover G, becauseG does not respond to the new arrival. In contrast,with the DEAPspace algorithm, G will recognizethe arrival of A, and respond by switching toshorter timeouts.

Fig. 5. Probabilities PfE1g � fG has discovered Ag and PfE2g � fA has discovered Gg as a function of time for the DEAPspace and

the regular algorithm.

Fig. 6. Probability PfEg � Pfall devices have an accurate world viewg as a function of time for DEAPspace algorithm and regular

algorithm with and without triggering on connection detection from physical layer.


7. Wireless communication platforms

DEAPspace applications are networked appli-cations executing across two or more nodes con-nected via wireless communication links. InSection 2 we identi®ed a set of characteristics ofDEAPspace applications that have profound im-plications on the underlying wireless communica-tions infrastructure.

As our research focus has been on networkingprotocols and algorithms rather than the design ofa new wireless technology, we have investigated anumber of candidate technologies for their suit-ability with the requirements of DEAPspace.

7.1. Requirements

As DEAPspace applications are spontaneousand ad hoc in nature (in contrast to wirelessLANs, where infrastructure networks are thecommon case), we require a distributed MACscheme. Centralized MAC schemes are not wellsuited for ad hoc environments with mobility, forinstance, take two wireless networks each with itsown ``master'' that initially are out of range: asthey move within range of one another, one ofthem must be ``dissolved'' and its member nodesmoved to the other network.

Given the pervasiveness of information appli-ances, the density of nodes in a wireless networkcan be very high. Depending on the environmentand the wireless range, the number of devices thatcan potentially interact with one another at anygiven instant can easily exceed 100 (imagine publicareas such as airports, train/subway stations, sta-diums, etc.). Thus, the MAC should possiblysupport on the order of a few hundred high-ratechannels or simultaneous users per band; further-more, all nodes should experience a fair andgradual degradation in throughput with increasingnumber of nodes.

Another issue is the time it takes to detect anetwork and attach to it. The transient nature ofDEAPspace applications, combined with the un-awareness principle underlying hidden computing,limits the time available for application-relatedtransactions. Basically, the interaction windowshown in Table 1 sets the upper time limit on the

window available not only for detecting a wirelessnetwork and joining it, but also for discoveringpeer application entities and executing applicationtransactions. Thus, we require minimal networkdetection/attach time combined with high-datarates. A further requirement is the capability tobroadcast at the physical layer as this helps im-plement e�cient and prompt service discoverymechanisms. Tempting as it may be, we cannotchange the relative velocity v of the user (i.e., slowher down to increase the interaction window) asthis would violate the unawareness principle.However, the interaction window tW increaseslinearly with the wireless range r, which suggestsmaking the range larger. Yet, this implies a highertransmit power, which adversely a�ects the batterylifetime of the information appliance and blurs thelocation context, which in turn reduces the preci-sion of location-sensitive semantics. Ideally, thewireless range should be adjustable via somephysical layer management interface.

The ad hoc nature of DEAPspace applicationsdemands that any two nodes can interact withoutprior con®guration of details, such as the physicaladdress of devices or shared secrets enabling se-curity mechanisms, about the remote node. Wire-less communication must be possible without anyprior con®guration of device addresses. Link-levelsecurity should be de®ned, but its use should beoptional and/or negotiable. This would meet therequirements of ad hoc application scenarios aswell as ``canned'' applications between a user'sprivate devices (laptop, cellular phone, PDA).

The end-user should not need to align devices toenable wireless communication between them. Thewireless range should be omni-directional and notline-of-sight.

With proximity-bound service provision, thephysical separation between client and server nodemay be a useful criterium to accept a service orarbitrate between otherwise equivalent service of-ferings. The wireless subsystem should be capableof estimating the relative distance to neighboringdevices and o�er a way to access this measure via aphysical layer management interface.

The support of audio and/or video applicationsrequires quality-of-service guarantees (throughput,latency, jitter).


Besides these DEAPspace-speci®c require-ments, there is a set of requirements common toenvironments with low-cost, battery-powered ap-pliances. In particular, the technology should ex-hibit a high level of VLSI integration, ideallyresulting in a single chip implementation of theentire subsystem. Power consumption must bekept at a minimum to increase battery lifetime.The cost to add wireless connectivity must be in-cremental to the total cost of typical consumer-oriented end-user appliances. The technology mustbe deployable in license-free frequency bandsavailable around the globe.

Below we shall take a look at currently avail-able technologies and evaluate them in the contextof the requirements described above.

Bluetooth wireless technology is an industrystandard for small-form factor, low-cost, short-range radio links between mobile PCs, mobilephones and other portable devices. It is developedby the Bluetooth Special Interest Group, an in-dustry group consisting of 3Com, Ericsson, IBM,Intel, Lucent, Microsoft, Motorola, Nokia andToshiba.

Although Bluetooth looks like an ideal candi-date for the wireless infrastructure of DEAPspaceit does not stand up to scrutiny vis-a-vis several ofour requirements. The reason for this is that, ini-tially, Bluetooth was designed to be a ``cable-re-placement technology'', which has profoundlyin¯uenced the design of its physical and mediaaccess control layers.

At the physical layer, Bluetooth is a point-to-multipoint technology using a centralized accesscontrol scheme with a master controlling the time-division duplex tra�c in the so-called piconet. Thenumber of nodes that can be active concurrently islimited to eight (including the master). This num-ber can virtually be increased via time-sharing byparking and unparking slaves. Obviously, this cre-ates overhead at the link management layer. Adevice that actively seeks a connection to someother device not part of its piconet becomes byde®nition the master of a new piconet. Either it hasto give up membership of the original piconet or itcan remain a (parked) slave in the original piconetand toggle between its two roles. Support of thisscatternet situation renders the link management

task quite complex in the general case. The cor-responding issues still have to be sorted out andtherefore link management policies for scatternetsituations are missing from release 1.0 of theBluetooth speci®cation. Bluetooth has no truebroadcast mechanism. Broadcasts only workamong members of a piconet. In e�ect, thebroadcast is a multidrop communication from themaster to its slaves. A direct broadcast from aslave to its master and all other slaves is currentlynot possible. Discovery of devices within radiorange relies on the so-called inquiry procedure.Depending on the number of active channels, in-quiry can take up to 30 s (at least 10 s). A con-nection can be established only after the address ofthe Bluetooth device has been learned via inquiry.

In conclusion, Bluetooth is ill suited for thepeer-to-peer, spontaneous and transient nature ofDEAPspace applications.

A second candidate is a technology based onthe IEEE 802.11 standards. The 802.11 workinggroup for wireless local area networks (WLAN)has successfully produced a single standard for themedium access control sublayer and several stan-dards for the physical layer. IEEE-802.11-compli-ant products have been available from a number ofvendors for some time now and, since the intro-duction of the 11 Mbps version WLAN, has in-creasingly become a viable alternative to Ethernetand token-ring LANs.

IEEE 802.11 is clearly not a technology de-signed for short-range (<10 m) networking be-tween information appliances. For that, its cost,range and power consumption are too high.However, having a distributed media access con-trol mechanism, it is well suited for ad hoc net-working and supports virtually an unlimitednumber of nodes in the same network with up to20 nodes talking concurrently. It does supportbroadcasts and the time to detect and join an ex-isting network is low. But it lacks support forisochronous tra�c. Some care is required whenestablishing a network to preclude ending up withthe situation that two devices each establish theirown network and will never see one another.Apart from chosing a common SSID (service setidenti®er) no con®guration is required. Interoper-ability is only possible between 802.11 nodes


sharing at least one physical layer implementation.In particular, frequency-hopping spread spectrum(FHSS) and direct-sequence spread spectrum(DSSS) devices cannot interoperate.

Alation Systems, Inc., specializes in developingtechnology for the wireless home network. TheirHomeCast Open Protocol (HOP) is a proprietarytechnology with similar design points as Blue-tooth. The technology ships in the WirelessHomeFree products from Diamond Multimedia.

HOP exhibits a prompt device discovery of theorder of less than 2 s and provides physical layerbroadcast capabilities. It uses a CSMA/CA host-based software MAC scheme and a FHSS low-power radio in the 2.4 GHz ISM band. Thenominal range is 150 feet. The aggregate data rateof 1 Mbps is rather low and limits the number ofnodes that can be active in a network to around10. There is no support for isochronous tra�c.

IEEE 802.15 is a working group (WG) of theIEEE 802 LAN/MAN Standards Committee anddevelops wireless personal area network (WPAN)standards for short-distance wireless networks.The 802.15 WG consists of multiple task groups(TG). The IEEE P802.15 TG1 is deriving a WPANstandard based on the Bluetooth v1.0 speci®ca-tion. Unless the standard developed deviates con-siderably from its base, the same objections as forBluetooth apply. The IEEE P802.15 High-RateStudy Group (HRSG) for WPANs is a StudyGroup (SG) with the objective of developing aphysical layer (PHY) and MAC layer speci®cationfor high rate, low-complexity, low-power con-sumption wireless connectivity.

The HRSG is still at an early stage, and it will beseveral years until a ®nal standard will be adoptedand complying products will become available.The HRSG is currently soliciting inputs for appli-cations and technical proposals. The applicationscenarios submitted will be used to de®ne of acomprehensive set of technical criteria. The tech-nical submitted proposals will then be evaluated(and re®ned) in terms of these technical criteria.

7.2. Summary of wireless communication technology

The development of short-range, low-power,low-cost wireless technology suitable for connect-

ing information appliances still is a relativelyyoung discipline. So far, Bluetooth is the onlyavailable technology with a clear focus on thisapplication area. Unfortunately, if falls short interms of spontaneous, transient, peer-to-peer,networking of mobile information appliances, asrequired for DEAPspace. Alternatively, 802.11might possibly meet the bill. Cost for 802.11components can be expected to decrease further inthe near future, which leaves the high-power con-sumption as the main obstacle to its deployment inhand-held, battery-powered appliances. Finally,the standards developed by the 802.15 HRSG (andthe respective technologies) o�er the opportunityto address the above issues and correct the de®-ciencies identi®ed with existing technologies.

Owing to the lack of an ideal technology atpresent, we have chosen 802.11 WLAN compo-nents as a substitute for our DEAPspace proto-typing work. Overall this choice o�ers the bestcompromise for our set of requirements.

8. Related research work

The core of our work revolves around promptand e�cient service discovery in transient ad hocnetworks of pervasive devices. Service discovery isnot a radical new topic. Several projects have ad-dressed the problem of discovering or locatingresources and services in a network. Best knownapproaches are probably Sun's Jini [16,17] and theMicrosoft-driven Universal Plug and Play (UPNP)project [4], others are the IETF's Service LookupProtocol (SLP) [14], the Salutation consortium [3],and HP's JetSend [7]. Of these approaches, Jiniprobably is the most-advanced project currently,followed by UPNP.

Considering its origins, it is not surprising thatJini depends on Java and Java's remote methodinvocation (RMI) concept. Jini de®nes services interms of Java interfaces and, thus, uses an appli-cation program interface (API) contract model.Service discovery relies on Jini's Lookup service(LUS), where a device wanting to share a servicewith its environment registers this service with aLUS in its environment by submitting Java code tothe LUS. A device wanting to use a service o�ered


by another device has to contact the LUS andquery it for the desired Java interface, then it hasto download the posted code to access the service.To ®nd an LUS, device either use a well-knownaddress or inquire for an LUS through IP multi-cast. With Jini, access to devices that do not sup-port a Java virtual machine occurs through aproxy that knows how to talk to the device andacts on its behalf.

In contrast to Jini, the Microsoft-driven Uni-versal Plug and Play project is speci®ed indepen-dently of the underlying platforms and languages,as UPNP uses a protocol contract model. Conse-quently, devices that desire to interact with otherdevices do not need to download code but insteadneed logic that implements a given protocol. Ser-vices are represented through pro®les that de®nethe contract between client and service. Servicediscovery is taken care of by the Simple ServiceDiscovery Protocol (SSDP): clients request a ser-vice either through IP multicast or by querying anSSDP proxy. In the case of a multicast query anydevice providing the requested service needs torespond to the request; in the case of a proxiedenvironment the proxy will respond. Also, in aproxied environment each device o�ering servicesneeds to register itself with the SSDP proxy.Clients can ®nd out more about a service byrequesting a service schema from the service-pro-viding device, which is a structured data descrip-tion that contains more information about aservice.

Both Jini and UPNP employ a pull-model forservice discovery: a client interested in a certainservice either needs to query its environment or adesignated, central service to ®nd a service pro-vider. Compared with Jini, UPNP o�ers greater¯exibility as it requires no LUS to be available andinstead can work in truly peer-to-peer fashion.While Jini's API-based contract model is conve-nient and easy to work within Java-based envi-ronments, UPNP's protocol-based contract modelallows a much larger range of devices and plat-forms. Also, Jini's use of downloadable codeintroduces code quality, security, and quality-of-service problems. Of the two approaches, however,Jini is currently widely used, whereas UPNP hasyet to make its appearance in code form.

Similar to Jini and UPNP, Salutation uses acentral service lookup server, called SalutationManager. In contrast to Jini and UPNP, Saluta-tion requires neither a speci®c platform (such asJava in Jini's case) nor a speci®c network tech-nology (such as HTTP or UDP in UPNP's case).The IETF SLP is similar in scope and operation toUPNP as it also uses a central directory agent to®nd out about and locate services.

In the context of transient ad hoc networkingJini, UPNP and the other discovery protocolssu�er from their use of a pull-model-based servicediscovery: by the time a device has issued its ser-vice request and received an answer, it might notbe able to invoke the service as it has left the rangeof the service providing environment. Jini in ad-dition introduces a considerable overhead with itsdependence on Java and sole use of Java RMI.

9. Summary and outlook

Ad hoc networking and spontaneous interac-tion between small and mobile devices over wire-less connections will be the key features of newpervasive applications which we can expect tobecome real over the next few years. The DEAP-space project presented in this paper is positionedas a ®rst step towards this goal. Starting from adescription of new application scenarios, we havederived the most important requirements to bemet by a framework supporting the developmentof pervasive applications. This paper has ex-plained the most fundamental concepts ofDEAPspace: its service model, compact and e�-cient service description and matchmaking, and anew push-based service-discovery algorithm. Thediscussion of wireless communication technologycurrently being developed and related research hasshown that transient as-hod networking is a rela-tively young discipline in which more work re-mains to be done.

9.1. Current Status

A framework based on the DEAPspace con-cepts as described in this paper has been imple-mented. This framework allows the development


of distributed applications based on ad hoc tran-sient networking whose components run on de-vices connected via a broadcast medium. Theprimary implementation was done in Java; fordevices which cannot run a virtual machine, asubset of the framework has been implementedin C.

The framework enables deploying di�erentwired or wireless communication technologies. Toaccomplish transparency from the concrete medi-um, the framework provides abstract interfacesshielding an application from the speci®cs of theconcrete network. Currently, we provide code torun DEAPspace applications over a simulatednetwork as well as TCP/IP and 802.3 MAC.

Several demonstration applications are run-ning, among them an application enabling down-loadable GUIs for devices which do no permitdirect management access. Here, a controller re-sponds to management requests using WirelessMarkup Language (WML) decks. The requestingentity is a WML browser visualizing the controllerresponses and supporting GUI-based interaction.

9.2. Outlook

Important and challenging areas of furtherwork are: security in ad hoc transient networking,location-aware and multidevice applications aswell as their con®guration and management.

The aspect of security in transient networksconstitutes a ®eld of research where very little hasbeen done so far. In particular, access control and,to some extent, information ¯ow control are themost-needed mechanisms. An open issue in thiscontext is how to introduce, describe, and qualifydi�erent levels of trust.

Transient ad hoc networking and spontaneousinteraction enable the development of new pro-gramming models and distributed applications. Interms of the behavior of these applications, relayedand choired scenarios can be distinguished. Re-layed applications sequentially utilize services asthey become available and store temporary results.In contrast to that, choired applications requirethe presence and interaction of multiple services atthe same time.

References

[1] Apple Computer Inc., Inside Macintosh: Networking,

1994.

[2] N. Brown, C. Kindel, Distributed component object model

protocol ± DCOM/1.0, Internet Draft. Technical report,

Microsoft Corporation, 1996.

[3] Salutation Consortium, Salutation architecture speci®ca-

tion, http://www.salutation.org/specordr.htm, June 1999

(cited 20 March 2000).

[4] Microsoft Corporation, Universal Plug and Play: Back-

ground, http://www.upnp.org/resources/UPnPbkgnd.htm,

1999 (cited 17 March 2000).

[5] R. Droms, Dynamic host con®guration protocol, Tech-

nical Report RFC 1541, Bucknell University, October

1993.

[6] ETSI, High Performance Radio Local Area Network

(HIPERLAN); Type 1; Functional Speci®cation, October

1996.

[7] Hewlett Packard, What is hp jetsend?, http://www.hp.

jetsend.com:80/products/hp/overview.html, 2000 (cited 20

March 2000).

[8] IEEE Computer Society, LAN MAN Standards Commit-

tee, Wireless LAN Medium Access, June 1997.

[9] International Telecommunication Union, ITU-T Recom-

mendation X.208: Open Systems Interconnection ± Model

and Notation ± Speci®cation of Abstract Syntax Notation

One (ASN.1), 1988.

[10] International Telecommunication Union, ITU-T Recom-

mendation X.690: Information Technology ± ASN.1

encoding rules: Speci®cation of Basic Encoding Rules

(BER), Canonical Encoding Rules (CER) and Distin-

guished Encoding Rules (DER), December 1997.

[11] International Standardization Organization, ISO/IEC IS

10746-3 Reference model for open distributed processing ±

part 3: Architecture, Technical report, ISO/IEC JTC1/

SC21/WG7, March 1995.

[12] Michael Nidd, Service discovery in DEAPspace, Technical

Report RZ6906, IBM Research, Zurich Research Labora-

tory, January 2000.

[13] Object Management Group, The common object request

broker architecture: Architecture and speci®cation, Revi-

sion 2.0. Technical report, Object Management Group,

1995.

[14] Charles Perkin, Slp white paper, http://playground.sun.

com/srvloc/slp_white_paper.html, May 1997 (cited 20

March 2000).

[15] R. Srinivasan, XDR: External Data Representation Stan-

dard, IETF RFC 1832, August 1995.

[16] Sun Microsystems Inc., Jini connection technology, http://

www.sun.com/jini/ (cited 28 February 2000).

[17] Sun Microsystems Inc., Jini Architectural Overview, 1999.

[18] Wireless Application Protocol Forum, Wireless Applica-

tion Protocol, Binary XML Content Format Speci®cation,

version 1.1 edition, 1999.

[19] World Wide Web Consortium, Extensible Markup Lan-

guage (XML), February 1998.


Reto Hermann obtained the Diplomain Electrical Engineering at the SwissFederal Institute of Technology, Zu-rich, in 1983. Subsequently, he joinedthe IBM Research Division, ZurichResearch Laboratory, as research sta�member. From 1983 to 1992 heworked in the area of signal processingfor digital magnetic recording systems.Since 1993 his research focus hasmoved to computer science where hehas done work in mobile computingand smart card technology. His pre-sent technical interests are pervasive

computing, wireless personal area networking and mobile in-ternet technologies. He is a member of the IEEE and IEEECommunications Society.

Dirk Husemann joined IBM's Re-search Division in 1996 and has sincethen been working on pervasive com-puting projects. Currently he is in-volved in the DEAPspace project aswell as in datacasting over digital au-dio broadcast channels. He receivedboth an MS (Diploma, 1991) and aPh.D. (Dr.-Ing., 1995) in ComputerScience from the University of Erlan-gen-N�urnberg, Germany. Husemannis a member of the IEEE, IEEEComputer, USENIX, TUG, and theGerman GI.

Michael Moser received both his Di-ploma in Electrical Engineering andhis Ph.D. in Technical Sciences fromthe ETH Zurich, Switzerland. He is aresearch sta� member with the IBMZurich Research Laboratory, where heis currently involved in various perva-sive computing projects. His researchinterests include distributed and inter-mittently connected systems, advanceduser interfaces for portable devices aswell as program design observationand execution monitoring tools.

Michael Nidd is currently writing hisPh.D. dissertation on the topic of ser-vice discovery in transient ad hocwireless networks, associated jointlywith Institut Eur�ecom and the SwissFederal Institute of Technology(EPFL), and working at the IBM Re-search Zurich Laboratory. He holdsBMath and MMath degrees in Com-puter Science from the University ofWaterloo.

Christian Rohner is working towardshis Ph.D. in Computer Science fromthe Swiss Federal Institute of Tech-nology (ETH) Z�urich, from where healso received a Diploma in ElectricalEngineering in 1997. He is doing hiswork at the IBM Research Z�urichLaboratory. His research interests in-clude security and communicationissues in ad hoc networking.

Andreas Schade joined the IBM ZurichResearch Laboratory in 1994 where hecurrently is part of the pervasivecomputing group. His research inter-ests include distributed systems, ap-plications and their management. Heholds a diploma degree (Dipl.-Inf.,1994) and a doctoral degree (Dr. rer.nat., 1998) in Computer Science, bothfrom Humboldt-University Berlin,Germany.


deapspace – transient ad hoc networking of pervasive devices

Documents