DEAPspace - Transient Ad-Hoc Networking of Pervasive Devices

Reto Hermann, Dirk Husemann, Michael Moser, Michael Nidd, Christian Rohner, Andreas Schade IBM Research, Zurich Laboratory

(rhe,hud,mmo,mni,roh,san@zurich.ibm.com

1. A Connected World

Most of the things we deal with in our day-to-day life are in- visible from a computer science point of view - they either do not even contain a microprocessor or they do not offer an interface to the outside world, let alone communicate with other devices. Nevertheless, we already are surrounded by a host of devices containing microprocessors of one sort or another. Moreover, we increasingly encounter devices that not only contain an embedded controller or system, but in addition provide an interface for exchanging data with other devices. This situation will lead to an interactive technical environment characterized by ad-hoc networking and spon- taneous interaction, all taking place transparently to the hu- man user.

The DEAPspace project is building an interaction frame- work for connecting pervasive devices over the wireless medium, supporting the development of new proximity- based collective distributed applications. The main com- ponents of this framework are the discovery algorithm and the service description model.

2. Service Discovery

The first step in coordinating devices is making it possible for them to find each other. Existing solutions, like DHCP and Jini rely on central servers to maintain lists of the ser- vices available from local devices. For many target appli- cations of transient ad-hoc networking, it is not reasonable to rely on the continued presence of a particular device, so we have developed a decentralized discovery algorithm (the DEAPspace algorithm). While some other protocols, in- cluding SLPv2, have dealt with this by allowing multicast queries when no central server is present, the speed and reliability of multicast makes this simple patch insufficient for wireless environments. The DEAPspace algorithm uses proactive single-hop broadcasts to share a world view with all proximate devices.

As with route discovery, service discovery should be fast, and should recognise changes in configuration promptly. For a pull-style solution to work, a device must decide when to request the information. One option, to send queries only when the information is actually required, does not offer a

0-7803-6534-8/00/$10.00 0 2000 IEEE 133

sufficiently fast or reliable result for our target application set. The alternative, using occasional queries to build up a world view holds promise, but when should the queries be sent? Ideally, there would be one query for every change in the local configuration, but this would require another dis- covery protocol to be running at a lower layer, and amounts to abstracting the problem away. This leaves us only with the option of polling, which is no better than having devices send regular beacons to advertise their presence. Clearly, a push-model solution is more appropriate.

Having decided that devices should push information about themselves to their peers, the biggest remaining ques- tion is when to do it. Most simply, devices could send bea- cons at fixed intervals. Slightly more power-friendly would be to have all devices race for pre-defined advertisement slots, allowing idle devices to deactivate their transceiver circuitry between slots. Our solution combines these, hav- ing devices race to transmit, but broadcast their full world view instead of just their own information. While this multi- plies the size of individual broadcasts, it divides the number of actual broadcasts by the same factor. Fewer broadcasts means less work for devices, and less current draw. Further- more, because each broadcast gives a snapshot of the world view known to a single device, other devices can use this information to see how current their own description is in other lists, and take corrective action.

In our implementation, each individual device schedules a broadcast for some time in the future, waits until that time, then broadcasts its world view as a service advertisement message (SAM). These broadcasts are single-hop, and will not be forwarded beyond the local transmission range of the device in question. If, while waiting for its broadcast time, an SAM is received from elsewhere, the first device resets its broadcast timer to some new time in the future. By choosing times with some random jitter, the devices take turns sharing their world view. When a device receives a SAM that has its local information correct, and with a rea- sonable time to live (expiry time), it has no need to send its own SAM, because the important information has already been sent for it. If it sees that its local information is absent or about to expire, it can schedule its next SAM transmis- sion sooner than usual, improving its chance of winning the broadcast race, and being known to others.

Figure 1: Time for mutual discovery with DEAPspace and with regular beacons, using connection detection

When a new device enters the transmission range of an existing group, it needs only to receive a single advertise- ment to learn about the entire set of services now avail- able. Moreover, because the transmissions are scheduled reactively, the time for mutual discovery (the existing group knows about the new device, and vica verca) is better with DEAPspace than with regular beacons.

If there is a connection event, as with CDMA synchro- nization, then the new device knows it has entered a new group (although the group doesn’t yet know it has arrived). By using this information to schedule its next broadcast immediately, the time for mutual discovery in DEAPspace simulations has been shown to be much better than with regular beacons. Figure 1 shows a sample comparison of discovery times in an environment with 10% packet-loss, where DEAPspace and regular beaconing solutions are con- figured such that similar network load is created by each, and a new device announces itself immediately after receiv- ing a connection event. This result is explained in more detail in [l].

3. Service Description

The other half of the system is the representation of a ser- vice description. In our model, each service is defined pri- marily by an input format, an output format, a name, and an address. A source is defined by a null input format, a sink by a null output format, and a transcoder by having a value for both fields. The name offers some consistent, concise, human-readable information to allow the user to discrimi- nate between similar services. If the user wishes to display a PostScript document, for example, then the system has done its job if it can locate a nearby PostScript output device. If there is a choice between a printer and a screen, that’s for the user to make. Remember that we are targeting short range platforms similar to Bluetooth, and discovering only those devices in single-hop transmission range, so there will not be a problem with choosing between fifty printers unless the user is actually in a room full of printers.

The format descriptions are hierarchical, based around the MIME types, and allowing further branching for version

numbers or other refinements. This allows service queries to be specified to whatever precision is appropriate. We also allow qualities to be specified at each level. For ex- ample, with Application + PostScript + versim2, the PostScript element is qualified with color (yesho) and pages per minute. In this way, details can be given at the most general level possible, allowing compatibilities to be exploited between similar or legacy formats. In the actual encoding, hierarchical assignments of element identifiers is used to create object identifiers (OIDs) unique to each for- mat; non-standard formats can be created through the use of string elements in the OIDs, giving functionality similar to MIME’S use of the ‘x-’ prefix.

The actual encoding of service descriptions is also impor- tant, because every device will not (and can not) be coded to understand every type of service that it may encounter. Because of this, the descriptions should be encapsulated. If a completely new device is encountered, its presence in the SAM should not interfere with the decoding of the rest of the list, and the receiver should be able to safely add the new service entry to its own list for later repetition. Further- more, if an old device encounters a later version of a service that it knows how to use, it should recognise as much of the description as it can use, and be able to repeat accurately the remainder. We have achieved this functionality by encapsu- lating each element of the tree with a size tag. Within an individual format element, the encoding must be previously known to the receiver to be interpreted.

4. Summary

DEAPspace is a framework that provides devices with use- ful information about the other devices in their surround- ings. This information can be queried in a consistent way that will tolerate evolutions, and allow legacy devices to continue to function in the fast-developing world of perva- sive gadgets. The discovery is done in a power-efficient, and network-friendly way, and will adapt to a wide range of error conditions.

This framework has been implemented, and allows the development of distributed applications that use ad-hoc transient networking as part of their function. The primary implementation was in Java. A subset of the code was also written in C, to allow the use of machines which do not have a JVM. In addition to simulation, the code has been tested over TCP/IP and the Ethernet interface of an 802.1 1 link.

Further Reading

[l] Michael Nidd. Timeliness of service discovery in DEAPspace. In The 29th International Conference on Parallel Processing (ICPP 2000) Workshop on Perva- sive Computing, August 2000.

134