Project Epsilon ()
Communicating Digital Devices Everywhere!

<hr&rt;

Introduction

Technology, in order to interact with humans, must be present in the physical world.  Thus we need displays, knobs, buttons, and the like.  But each such component device would provide more flexibility if it were mainly a virtual object on the world`s network. 

The Epsilon vision depicts technology such as your stereo receiver or cell phone as composed of small, independent devices, each having a virtual world proxy.  These proxies communicate in order to create the effect of a single, larger tool.

In the Epsilon limit, a component device is nearly stateless, and typically hosts very little software on the device itself.  Rather, the physical location of its software proxy is irrelevant -- it may well be out on the web, running on some possibly distant server.  With software defined connections, Epsilon devices will be easily replaced, and can be flexibly reconfigured into different and even unanticipated combinations.

The Epsilon project will demonstrate this approach to working with thin devices, and investigate how one can create, modify, monitor, and debug relationships among such devices.

Note: The name "Epsilon" was chosen to denote "vanishingly small" as in the classic definition of a limit in mathematics:

Project Proposal

Project Epsilon grew out of a need to understand the impact of thousands of digital devices all communicating with each other.  This lead to a project proposal, put together by four of us in Sun Labs.  A brief portion of the proposal illustrates the approach Epsilon makes:


(a) Conventional Technology
(b) Jini Technology

(c) Epsilon
(d) Epsilon, Centigrade Display

Figures (a) - (d): In conventional technology (a), relationships are hard wired (the sensor is wired to the display). With Jini (b) local code maintains a lease on a resource after a lookup has established the relationship (the sensor and display find/lease each other). Epsilon (c) devices typically need not be identified with a lease on a resource or go through a code download (the sensor and display are simple TCP/IP clients). Because their relationship is held in software (d), Epsilon devices are flexibly reconfigured (the sensor and display have a software converter provided "by the network").

Epsilonic Principles

There are several important principles at play within Epsilon.

  1. Minimal: An Epsilonic device need only provide the ability to communicate and export its capabilities to the network using whatever protocols and interfaces "natural" to the device.  Thus a Dallas Semiconductors "1-wire" switch provides a master-slave communications style, representing its value as a boolean.
  2. Thin: An Epsionic network provides the "interesting" functionality off-device.  Thus a temperature display provides only the ability to display alphanumeric values.  It exports the ability to modify a string value.  The temperature conversion from Farenheit to Centigrade is done off-device.  (A good example of a Thin device is the Sun Microsystems "SunRay" desktop where even the video display is kept off-device!)
  3. TCP/IP: Although many simple networks may be used within an Epsilonic environment, they all deliver the illusion of being full TCP/IP capabile devices with their own TCP/IP address.  Proxies are the primary means for this with devices that are not natively TCP/IP devices.
  4. Components:  A natural outcome of Minimal, Thin devices is a fine-grain component architecture where systems of interest are "composed" of many basic Epsilonic components.  For example, a radio could be comprised of networked speakers, a networked knob/switch, and a networked display.  The components would not be wired directly together, rather they are wired to the network.  They can be re-purposed into other systems such as an MP3 player without rewiring.

There are examples of systems exhibiting one or more of these principles in the past.

Project Activities

Epsilon currently has three activities:

  1. Devices: We are exploring a few simple networked digital devices which could be deployed in modestly large numbers (low hundreds).  The initial exploration is the Dalas Semiconductor's TINI device, a Java based (Java 1.1 SDK) system (See Slide Set) designed to interface traditional peripherial components to the ethernet. A new project uses a PIC 2022 device which is capable of greater throughput for media applications such as speakers and video displays. As we start needing Real Time capabilities, the Systronix aJile Real Time Java device will be evaluated.
  2. Software: We are investigating several potential software architectures such as Jini, Web Services and Jxta. This is a combination "due diligence" exercise, and a means for developing a core system which will interoperate with a host of infrastructures. In addition, we are investigating "self organizing" systems of various kinds. This direction hopes to grant greater autonomy to clusters of Epsilonic devices, especially those whose deployment make it difficult or impossible to centrally organize.
  3. AutoID: During our initial explorations, we made contact with Sun's Global Sales group which has established a very strong partnership with MIT's AutoID Center. The center is building a consortium of manufacturers and computer companies to standardize on the use of RFID tags and readers to provide all real world devices with a wireless 96-bit ID.  Initially this is to be used in supply chain optimizations, but promises very interesting "smart objects" uses in the not too distant future. We have a summer intern from the Center who is building a RFID testbed within Sun Labs.
RFID Tags
 TINI System