Challenges and Lessons Learned in Building a Practical Smart Space
Yoshihiro Kawahara1, Masateru Minami2, Shunsuke Saruwatari1,
Hiroyuki Morikawa1 and Tomonori Aoyama1
1) The University of Tokyo, 2) Shibaura Institute of Technology
kawahara@mlab.t.u-tokyo.ac.jp, minami@sic.shibaura-it.ac.jp,{saru, mori, aoyama}@mlab.t.u-tokyo.ac.jp
Abstract
Ubiquitous computing as the integration of sensors,
middleware, and networking technologies to form a“smart space” environment relies on the developmentof both software and hardware solutions. For over 3
years, our group has been developing a smart-spaceenvironment, involving the exploration of coretechnologies and attractive applications. In this paper,
we introduce the challenges faced and lessons learned
in designing and developing a smart-spaceenvironment, including device control services,
locating systems, wireless sensor nodes, andmiddleware services.

1.

Introduction

The notion of ubiquitous computing is quite distinct
from the conventional computing paradigm in that it
implies the provision of services via a network ofinvisible computers. In a ubiquitous computing
environment, tiny devices such as sensors areembedded in living spaces to collect real-worldinformation and build a model of the real world inorder to provide computer-controlled services. Using
this repository of user and world contexts, users canreap the benefits of smart and attentive services
provided by embedded computers.
The realization of ubiquitous computing relies
heavily on the miniaturization of computers andimprovement of communication protocols and power
supply technologies. However, it is also necessary todevelop novel services to complement these newtechnologies and facilitate the development of newcore technologies. This situation is quite similar to thatsurrounding the birth of the Internet. New services andapplications are inspired by the use and exploration of
the new technologies, and vice versa. Tim BernersLee, the inventor of the World Wide Web (WWW),

stated that “I just had to take the hypertext idea andconnect it to the TCP and DNS ideas and the World
Wide Web.” [1] This implies that most novel
inventions are supported by existing technologies. In
addition, the use of new services triggers the inventionof new core technologies. A good example is thesearch engine algorithm, which was developed as the
WWW was deployed. In the research and developmentof ubiquitous computing, synergistic effects cantherefore be expected between the creation of services
and the development of core technologies.
Since 2001, our group has been constructing a smartspace environment, which has involved the explorationof core technologies and attractive applications.
Through this experience, we have learned many
lessons and developed several practical systems andcore technologies. Most importantly, this experience
has lead us to conclude that the development of both
software and hardware is indispensable for ubiquitous
computing, which is realized as an integration ofvarious components including sensors, middleware,and networking technologies.

1.1.

Related works

Several other research programs are currently inprogress with a shared perspective of exploring a newresearch agenda. These include iRoom [1], the Aware
Home [3], Easy Living [4], Smart-Its [5], andSSLab[6], which are all practical approaches torealizing smart environments. Although our project
shares a similar philosophy to these other programs,
the underlying technologies, goals, and lessons learned
are different. We believe it is meaningful for eachproject to report on their respective experiences andthe solutions developed. In this report, we present thedesign considerations for our testbed room, thedevelopment of our distributed object localization
systemforphysical-spaceinternetworking(DOLPHIN) ultrasonic locating system, the U3 sensor
node, and STONE middleware.

2.

How we made things smart

In the absence of a formulaic method for building asmart environment, we began by trial and error fromsome basic principles. The testbed for this project wasa room of about 100 m2 in area (8.6 m × 12 m; Figure1) with steel trellises installed on the ceiling to allow
the easy attachment of various devices. The room wasdivided into three main spaces, a working desk
environment, a collaborative meeting space, and arelaxing living space. Up to 10 researchers actuallywork in this room everyday.

Figure 1 STONE room
The first step in the construction of our smart
environment was embedding devices into theenvironment logically. This involved the connection ofcomputers, audio-video equipment, and lighting to a
network. The appliances in the room were modified
using an off-the-shelf multipurpose infrared remotecontrol (“crossim”), which was connected to acomputer via an RS-232C interface to allow theappliances to be controlled via the network. The
infrared signal transmitter was extended in order toensure the signal reached all areas of the room.

2.1.

Smart Baton System

Although audio-visual equipment was connected to
the network, it simply was not worth the effort to bootthe computer and open a browser in order to turn on atelevision in front of the user. Moreover, when a large
number of appliances are connected, selecting theappropriate device from the list can also be quite
troublesome.
To overcome this problem, we developed a Smart
Baton System, which provided the following featuresin order to overcome these inconveniences:(1) Explicit and easy selection of appliances(2) Provision of an appropriate user interface for eachappliance(3) Support of multi-user operation(4) User identification and realization of differentiatedservices for each user
Although several middleware architectures have beendeveloped for ubiquitous computing environments,
such as Jini [7] and UPnP [8], these existingarchitectures do not satisfy the first requirement since
their directory service-based approach does not allow
users to choose appliances intuitively. Infrared remotecontrols are preferable in terms of intuitive
manipulation. However, infrared remote controls
usually provide only a poor user interface and do notallow for user customization [9], thus not satisfying thesecond requirement. A system such as that reported by
Olson and Nielson [10] allows users to explicitly
choose an appliance with a laser pointer via various
user interfaces. However, as the laser spot isrecognized by image processing, the system allows
only one user to control appliances at a time, and assuch it does not satisfy the third and fourth
requirements.
In order to satisfy all requirements, we developed
the Smart Baton System as a laser-pointer-based
manipulation technique. The system differs fromsimilar techniques in that it is possible for users to
download an appropriate user interface to a handheld
device via the network, and target appliances are able
to distinguish between multiple users and provide
differentiated services.
2.1.1.

System

An overview of the Smart Baton System is shown in
Figure 2. The system consists of smart batons, smart
baton-compatible appliances, and a certificate
authority (CA). A smart baton is a handheld device
equipped with a laser pointer, and is used to control
appliances. A smart baton-compatible appliance has alaser receiver and is connected to the network. The CA
is used to authenticate and identify users andappliances. Figure 3 illustrates the function diagram
for the smart baton and an appliance. The user chooses
an appliance by pointing to its photo detector with thelaser pointer, and the smart baton sends information by
the laser beam. The appliance detects the beam andobtains the information via its laser receiver, identifies
the network address of the smart baton, and establishes
a network connection to the smart baton. An
authentication process follows to establish the user’s
identity, allowing so the appliance to provide different

user interfaces and services for respective users. For
example, the system can prevent children from turning
on a television at night while allowing adults fullcontrol.
(1)Request(2)Session Initiation(3)User Authentication(4)Getting Authentication Information(5)Getting User Interface(6)Transferring User Interface(7)Control Command(8)Forwarding Command(4)

Authentication Server

(2)
(3)
(6)
(7)

User Interface(5)(8)
SessionKeeperSmart Baton Controller

Device Control Servertime values, the IP address of the smart baton remains
the only potential target of theft, but this is not aserious issue because the IP address can already beeasily revealed via the domain name server (DNS).
The network connection is vulnerable to wiretapping, but that can be easily prevented employing an
encryption
technology.
Inourprototype
implementation, all communication over the network is
encrypted by secure sockets layer (SSL) encryption,
making it virtually impossible for someone listening
on the network to steal private user information. Thismeasure also makes the system resistant to tampering,and the authentication of appliances prevents
impersonation attacks on the network.

(1)

Smart Baton

DeviceFigure 2. Smart Baton System
802.11b
Serial I/F
iPAQ H3660
Base
StationSub Carrier 3kHz
Data 50bps
3kHz

PIC16F628

VisibleLaser

Laptop PC

PIC16F877(b) Information Appliance

Figure 4. Prototype system

HPF

LAN

Amplifier2.1.3.

3KHz BPF

Figure 4 shows a prototype implementation of theSmart Baton System. In this implementation, a
COMPAQ iPAQ Pocket PC H3660 equipped with acustom laser transmitter is employed for the smart
baton, and a laptop computer equipped with a laser
receiver is adopted as a smart baton-compatible
appliance. The laser transmitter consisted of visible
laser device and a microcontroller (PIC16F628,
Microchip Inc.), which is controlled via the iPAQ's
serial interface. The laser transmitter sends data via thevisible laser at 200 bps upon receiving data from the
iPAQ. The laser receiver consists of a photodetector(solar cell), a signal-processing circuit, and a
microcontroller (PIC16F877, Microchip Inc.), andsends received data to the laptop via a serial interface.

Detection

Figure 3. Hardware function diagram
2.1.2.

(a) Smart Baton (PDA)

Laser Pointer

50bps

Certificate
Authority

Solar Cell

Security Considerations

In a ubiquitous computing environment, appliances
will exploit user information in order to provide
flexible services, which may mean users will provide
appliances with private information. In such asituation, there may be a concern about access to thisprivate information when it is transferred to theappliances. In the Smart Baton System, there are two
communication channels between users and appliances
over which information is transferred; the laser beam
and a network connection. The former is vulnerable toimpersonating appliances, such as a fake appliance set
to collect information received by a laser beam. To
avoid such security problems, the laser beam conveys
only unimportant information, such as the Internet
protocol (IP) address of the smart baton, the TCP port
number, and a randomly generated session identifier.
As the TCP port number and session identifier are one-

Implementation

In this implementation, HTML and HTTP are used as
the basis for the user interfaces in order to simplify thesystem. When an appliance serves a user, a Device
Control Server sends the URL of the user interface tothe smart baton, and a web server runs the appliance.
On the smart baton, a web browser is invoked andaccesses the URL, and the user then controls theappliance via the web browser. As the system candistinguish between users, appliances can providedifferentiated services for each user. For example, by
checking the user’s age, the system can provide aremote control interface that prohibits access toprohibited programs.

3.

Obtaining Contexts in Real World
Environments

Our next challenge was to develop a platform that
included a computer model of the real-world
environment. This system required the implementationof a locating system and the deployment of sensor
nodes.

3.1.

3.1.1.

Positioning Algorithm

Figure 5 shows an overview of the DOLPHIN
system. The system consists of a number of DOLPHIN
nodes consisting of a 2400 bps radio frequency (RF)transceiver for time synchronization and message
exchange
among
nodes,
several40
kHzomnidirectional ultrasonic transducers, and a Hitachi
H8S/2215 16 MHz microprocessor for calculating thelocation of the nodes.

DOLPHIN

In a ubiquitous computing environment, the physicallocation of indoor objects is key information forsupporting context-aware applications. Several
positioning systems have been proposed for obtaining
indoor location information, including Active Bat [11]and Cricket [12], which use ultrasonic time differenceof arrival (TDOA) data to measure the threedimensional position and orientation of objects in anindoor environment with high accuracy. However,such ultrasonic positioning systems require additional
hardware for the transmission and reception ofultrasonic pulses, and usually require manual preconfiguration of the locations of reference beacons or
sensors. The setup and management costs of such asystem would be unacceptably high if the system were
to be applied to a large-scale environment such as an
office building. An ad-hoc localization mechanism[13] can be applied to such problem. In [13], theauthors proposed a collaborative multilateral algorithm
to solve the localization problem in a distributedmanner, and performed a detailed simulation-based
analysis of a distributed localization system. To designa practical location information infrastructure, we
believe that experimental analysis is also required inorder to discover practical problems with the
distributed localization system.
From this point of view, we developed a distributed
positioning system called the Distributed Object
Localization
Systemfor
Physical-space
Internetworking (DOLPHIN), which determines the
position of an object using only a few manuallyconfigured references. The system was constructedfrom off-the-shelf hardware devices, and represents a
simple but practical distributed positioning algorithm.

Figure 5. DOLPHIN system
The key premise of our positioning algorithm is hopby-hop localization. For example, in the bottom left of
Figure 5, node D can determine its position byreceiving ultrasonic pulses from the reference nodes A,
B, and C. However, nodes E and F cannot receive
ultrasonic pulses from reference nodes due to physicalobstacles such as a wall. Here, if the position of node
D is determined, and node E can receive ultrasonicpulses from node D, node E can compute its position
using the distances from nodes B, C, and D. If thelocations of nodes D and E are determined, node F cancompute its position using nodes C, D, and E. In thisway, all nodes in the DOLPHIN system can be located.
There are two main advantages to this mechanism.
First, the system requires only a few (minimum three)nodes to determine the positions of all nodes. Second,nodes can determine their positions even if unable toreceive ultrasonic pulses from reference nodes directly.
The positioning algorithm runs by exchanging several
messages as shown in Figure 6: and identification (ID)notification message (IDMsg), measurement message(MsrmtMsg), and location notification message(LocMsg). The nodes in the system are assigned suchthat there is one master node, one transmitter node, andthe rest receiver nodes. Consider the example depicted
in Figure 5, where nodes A, B, and C are reference
nodes, and nodes D, E, and F are normal nodes (thepositions of the nodes are unknown). Here, we assume
that nodes A, B, and C have node lists [B, C], [A, C],
and [A, B], respectively. We also assume that node E
and node F are unable to receive ultrasonic pulses fromnode A because of an obstructing wall.

Figure 6. DOLPHIN positioning algorithm
With node A acting as the master node, Figure 6
shows the timing chart for the positioning algorithm.
First, node A chooses one node randomly from its
node list [B, C]. If node B is chosen, node A transmits
MsrmtMsg including the ID of node B. On receiving
the message, node B becomes the transmitter node andgenerates ultrasonic pulses. At the same time, nodes
C, D, E, and F become receiver nodes and start internalcounters (synchronization phase). When a receiver
node detects an ultrasonic sign from node B, it stops its
internal counter and calculates its distance from node
B. After several milliseconds, depending on the time
taken by the overflow of the internal counter, node B
sends LocMsg to notify the receiver nodes of its
position. The receiver nodes that are able to detect theultrasonic signal from node B store the location ofnode B and their distances to node B in their position
table (measurement phase). All nodes then listen for
IDMsg for several milliseconds (advertisement phase).
If there is a node that could determine its position
based on three or more distances, it advertises its ID inthis phase. This ID is added to the node list of every
other node.
In the above example, because nodes D, E, F cannot
determine their positions, no IDMsg is sent by those
nodes in this phase. This sequence of phases defines
one cycle of the positioning algorithm in the
DOLPHIN system. In the next cycle, node B, which

acted as a receiver node in the previous cycle, becomesthe master node, and the positioning algorithm
proceeds in the same manner. After three or morecycles of positioning, node D can determine its
position based on measured distances from nodes A,
B, and C. At which time, node D can send its IDMsg
in the advertisement phase. All other nodes thatreceived the IDMsg from node D add the ID of node D
to their node lists, and node D is recognized as a
candidate master node. After node D becomes master
node, node E and node F can measure their distancesfrom node D. Then, node E can determine its position
and advertise its IDMsg. Finally, based on nodes C, D,
and E, node F can determine its position. In this way,
we can locate all nodes in the DOLPHIN system.
In the DOLPHIN system, it is necessary to prepare
for node failure. To recover from node failure, eachnode in the system has a recovery timer and an
advertisement timer. The recovery timer is set whennodes receive MsrmtMsg, and expires if there has beenno MsrmtMsg for a certain period. If the recovery
timer expires, a node in the system is chosen randomly
to become master node, and the positioning algorithm
resumes. If a candidate node does not receive
MsrmtMsg from other nodes within a certain period,
the advertisement timer in the node expires, meaningthat the node is not recognized as a master node by theother nodes. In this case, the node retransmits IDMsg
in the advertisement phase of each positioning cycle.
3.1.2.

Experimental Result

As an experimental evaluation of the algorithm, weplaced
seven
nodes
as
shown
in
Figure 7, and computed the average and variance ofthe measured position of each normal node (nodes DG) over 1000 cycles. The results revealed that thesystem could determine the position of objects with anaccuracy of around 15 cm in a real indoor
environment. However, the positioning error for nodes
E-G was higher than that for node D, as the
positioning error at node D affects the position
determination of nodes E-G, which determine theirposition based on node D. Although this error
propagation problem is inherently unavoidable in the
DOLPHIN system, we expect to minimize positioning
error by placing reference nodes at appropriate
locations.
Our group has obtained a large amount of data
through experimentation in our laboratory. We are
currently designing an improved version of thepositioning algorithm that can handle practicalproblems such as multipath propagation and node
mobility.

Figure 7. Experimental results
3

U

In addition to location information for users andobjects, real world information is helpful for contextaware applications. When designing a practical sensor
network architecture for future ubiquitous computing
environments, it is desirable that the requirements offuture applications be made clear. However, it has
been difficult to envision what such future applications
will be like. To assist in the implementation andevaluation of prototype applications and to clarify
technical challenges, we have developed a sensor
network development testbed called U3 (U-Cube) thatallows developers to flexibly implement various
applications. The U3 device is a 50 mm cube
containing a power module, a microprocessor module,
an RF communication module, and a sensor module.
The first implementation of U3 is capable of sensing
several types of data such as temperature, brightness,and the presence of humans, and can send thisinformation to other nodes and/or peripheral devices
including computers and PDAs.

Figure 8. U3 hardware components
3.1.3.

Hardware Design

There is a wide range of potential applications andprotocols for sensor networks. For environmental

monitoring applications, it would be useful if thewireless nodes could provide a generic sensor
interface, which would allow the sensors to be easily
replaced. For practical reasons, it would also be
preferable to be able to provide solar panels andrechargeable batteries. Moreover, users might want tochoose more appropriate computing and wirelesscommunication devices according to the power
consumption and required processing/transmission
speed. To meet these kinds of requirements, thehardware components of the sensor node should beconstructed as an ensemble of independent modules
that can be easily replaced. However, conventional
sensor network nodes [13][15][16] such as MICA
Mote only allow replacement of the sensor board.
Other components such as the microprocessor andwireless communication module are not replaceable.
In order to achieve this flexibility, we divided thefunctionality of the sensor node into four physicallyseparated modules: a power control module, aprocessing module, a communication module and asensing/actuating module. Each module is thenconnected to others by a bus connector to achieve
extensibility.
3.1.4.

Software Design

Due to the small physical size of the sensor nodes andthe limited power consumption, software on the sensor
node hardware must make efficient use of processor
andmemorywhile
providing
low-power
communication. In this section, we describe taskscheduling and application programming interface(API) layering in the sensor node.
1) Event and task scheduling
In general, one sensor node plays several roles in thesensor network. For example, information may besimultaneously captured by sensors, manipulated, andstreamed onto a network. Alternatively, data may bereceived from other nodes and forwarded in multi-hop
routing or bridging situations. To realize suchconcurrent execution using such resource-restricted
hardware, we allow the interruption of tasks by events.
Here, an event is defined as a process that must be
executed immediately and is assumed to complete
immediately, such as the arrival of wireless packets. A
task is defined as a process that takes longer than an
event to complete, such as the periodic capturing ofenvironmental data. Event-based task schedulingincurs only a low overhead for state transition
compared to a stack-based approach. Accordingly, thisscheme reduces processor load and power
consumption.

A media access control (MAC) algorithm
significantly improves the system performance of thesensor nodes. Specifically, MAC ensures accurate
synchronization between sending and receiving nodes,
which is crucial for high-speed, reliable transfers. As
application tasks can be frequently interrupted bywireless communication events, an additional
microprocessor dedicated to wireless communication
and application tasks is provided to reduce the load on
the main processor.
2) Functional layering
The primary objective of U3 is to provide a testbed
sensor network for the development of ubiquitous
computing environments. Having a testbed
development environment is essential for the
innovation of attractive applications. For example, if auser wants to design an appropriate communication
protocol for a specific application, it would be useful if
various APIs for controlling communication
functionality could be provided in the development kit.
While TinyOS [17] is a component-based runtime
environment designed to provide support forembedded systems such as MICA Motes (UCBerkeley), it does not provide a separate
communications module. To date, we have defined
several APIs that provide layered abstracted
communication functions (application, media access,physical layer of RF and IrDA 1.0). This layering
allows developers not only to reuse the APIs but also
to concentrate on the development and evaluation of
the specific functions or protocols in which they areinterested. Of course, it is conceivable thatconventional layering may no longer be valid forsensor networking. In that case, however, developers
can choose not to use the APIs and conventional
layering.
Communication Module: this module consists of an
RF monolithic transceiver (300 MHz band, On-Off
keying, 115.2 kbps), a helical antenna, and second PIC
microcontroller for processing network protocols. The
current implementation realizes data transmission of
up to 100 kbps with our current implementation of thecarrier sense multiple access/collision avoidance(CSMA/CA) protocol. The transmission range iswithin a radius of 30 m. The communication module
hosts a dedicated processor to drive the RF transceiver.
As mentioned in the previous section, it is possible toimplement various MAC and network layer protocols
using this processor.
Sensor/Actuator Module: the sensor module isdedicated to obtaining information about thesurrounding environment. The implementation of thesensor node only includes a motion sensor, abrightness sensor, and a thermometer, but varioustransducers can be connected to the board via a genericbus connector.
3) Software Implementation
Figure 9 shows the software architecture of U3. We
adopted C as the programming language due to thewide availability of commercial C compilers, which
provide plenty of built-in functions for handlingfeatures such interrupts.

Figure 9. U3 software architecture
The U3 software consists of the application software,
wireless communication software, and a development
environment. The application software and wirelesscommunication software are implemented in PICs on
the main processor board and the wirelesscommunication board, respectively. Messages between
the software travels via the I2C bus.
Application software controls the sensor andactuating devices, and forwards processed data to thewireless communication software. Multiple tasks arescheduled in a first in, first out (FIFO) task scheduler.
The application software also provides APIs forcommunicating with a computer or PDA (via IrDA), as
well as other nodes (via the RF module). After all tasks
in the scheduler have been processed, the system sets
the main processor in sleep mode to save power. Timerevents generated by the calendar integrated circuit (IC)and packet arrival events generated by the IrDA chipand the wireless communication software can wake themain processor.
The wireless communication software provides APIs
that bridge the application processor and the wirelessRF modules. The wireless communication software
includes a routing protocol and MAC protocol, whichare implemented independently such that each of the
protocols can be replaced according to user
requirements. In the physical layer, we provide
periodic transmission and reception control for the RFcommunication module. The RF module transmits databy amplitude shift keying (ASK), where each bit isencoded with the Manchester Code, and encoded data
is sent after the transmission of a preamble (1 Byte)and header (2 Bytes).
3.1.5.

Related works

MICA Motes and U3 share a similar motivation: todevelop an off-the-shelf sensor network testbed.
However, they differ on several points. Although
MICA Motes and U3 use similar RF wirelesscommunication modules for communication between
nodes, the frequencies used differ due to legal
regulations (the 916 MHz used by MICA Motes isrestricted to transmission over less than 1 m in somecountries including Japan). In U3, we use two PICs, asa processor and network controller. Compared to the
ATMEL 90LS8535 controller installed in MICA
Motes, PIC has advantages with respect to power
consumption, particularly with the sleep mode feature.
Due to the use of these two controllers, U3 therefore
has a potential advantage in terms of power
consumption. In addition, MICA Motes is only
equipped with replaceable sensor board; in U3, boththe sensor board and main processor, network andpower modules can be replaced. IrDA communication
with other peripheral device is also unique to U3.
Finally, TinyOS as used by MICA Motes provides
event-based development environments, but does notprovide layering of the network stacks due to themonolithic networking module.

4.

transcoder function to reformat the PDF file. If theuser wishes to use a voice-only device such as apersonal digital cellular (PDC) to obtain information in
the PDF document, the application will need to locate
and use a PDF-to-text function as well as a text-tovoice function. Thus, to enable ubiquitous Internet
applications with adaptable functionality on the fly, amechanism capable of finding and synthesizing theappropriate functions transparently on the Internet isnecessary.

4.1.

STONE

Our group is currently developing the STONE
network service platform, which dynamicallysynthesizes a desired context-aware service from a setof resources. STONE provides service discovery,
context awareness, service synthesis, and service
mobility in a unified way using a naming service[18][19].
Figure 10 depicts the STONE architecture. STONE
has three major components: a functional object, aservice resolver, and a service graph. The functional
object is the most basic element of a service, and has
the mechanisms required for providing the requested
service by dynamic linking to another functional
object. Functional objects may be either hardware orsoftware, and include objects such as the display, acamera, speaker, microphone, various types oftranscoders and proxies, and streaming videos. A
synthesized service is a string of functional objects
such as the dynamic combination of functions of thesource of world news, a transcoder, and a display.

Middleware technologies

The technologies we have introduced to make anenvironment“smart”
represent
fundamental
components for realizing ubiquitous computing, but a“glue” for creating applications and services isrequired. This glue is implemented in the form of
middleware to coordinate the ubiquitous devices on the
network, and forms an indispensable part of thesystem. As ubiquitous computing environments can be
expected to be highly dynamic, heterogeneous, andcontext-dependent, the functionality of applications
should be able change depending on the dynamicallychanging user context. For example, when a user
wishes to brows a portable document format (PDF) file
on a PDA display, the document-browsing application
running on the PDA will require an additional

Figure 10. STONE architecture
In this system, even if a change in the environment
around the functional object or user occurs, the service

can be maintained and be transparent to mobility or
failure as long as the functions composing the service
can be maintained (i.e., distribution transparency).
Alternatively, the service provided can be tailored tothe environment by modifying one function into a
more appropriate function as the environment changes(i.e., context awareness).

Location-independent naming, however, often has aflat name space, resulting in a scalability problem, incontrast to location-dependent naming such as DNS
which has a hierarchical name space. The introductionof interface names in STONE naming mitigates thescalability problem by grouping interface names toform a two-level hierarchy.

STONE achieves distributed transparency andcontext awareness through appropriate naming offunctional objects. Networking systems are
traditionally organized using a layering modelcomposed of applications, transport/networks, and link
layers. This model is useful for clearly defining the
responsibilities and restrictions of software that exists
at each level. To be implemented fully, a layer requires
a naming scheme, a means of resolving those names,
and a means for routing communications. On theInternet, the naming types used in each layer include
MAC addresses in link layers, IP addresses in network
layers, and URLs and email addresses in theapplication layers. In STONE, we extend the model toinclude a new top layer.

The service resolver network overlaid on the Internet
is used to route a request to the appropriate locations
by maintaining a mapping between interface
descriptions and their network locations. The service
resolver network is a logical overlay network, andfinds and connects functional objects using interface
names. As an IP router routes data by examining its
destination IP address, the service resolver routes databy examining its interface name.

STONE adopts location-independent naming fordescribing the objects being searched for by users
and/or applications, not the location of those objects.
Current naming types for IP addresses and URLs
specify the network location of server and clientmachines, and as such these names are locationdependent. The advantage of location-independent
naming is to be able to achieve distributed
transparency with respect to access, location, failure,
and replication. Location-independent naming allows
nodes that provide a function to precisely describe
what they provide and users to describe what theyrequire. This makes it possible to achieve service
discovery, context awareness, service synthesis, andservice mobility in a unified way. The following is an
example of STONE naming. Every name isrepresented as an attribute-value pair, and includes aninterface name for describing the function of afunctional object.
[FO Name =[Location=x.y.z@myhome.net],[InterfaceName=//Physical Location//Function Description[Output Interface = Rendered Video],[Input Interface = MPEG4/IP],[Relation = Convert Input Interface to Output Interface],[Ctrl Interface = Display Control/GUI]]][Access Pointer List= [Address=xx.xx.xx.xx:yy], //IP+Port ]The service graph specifies the service request of aclient, for example,”I would like to see the camera
images for room 409 on the nearest monitor”. The
service graph may be created by the client, or may be
downloaded from the network. It describes theinterconnection between functional objects (e.g., toconnect a camera output function with a monitor input
function), and a context script to specify context
awareness explicitly (e.g., to select the output functionof the nearest monitor). When a user issues a service
graph, STONE finds suitable functional objects andsynthesizes the requested service by combining several
functional objects dynamically in a context-awaremanner.
We have implemented STONE in a testbed room andconstructed several application prototypes, including
mobile video conferencing, a ‘connect to’ service, anda ‘media kitchen’ service. The locations of objects andpeople can be determined using the indoor positioning
system installed in the testbed room.

5.

Conclusion

In this paper, we have introduced our approach forrealizing a ubiquitous computing environment. Our
smart space testbed is comprised of networked
appliances, a device control system (Smart Baton), an
ultrasonic location system (DOLPHIN), wirelesssensor nodes (U3), and service synthesize middleware(STONE). This testbed is unique in that research on
both hardware and software are conducted using asingle testbed environment with coordination between
research topics.
Our next step is to develop a variety of context-aware
applications using these technologies, and deploy theseapplications in the smart space. It is only through such

practical experimentation that the real functionality ofubiquitous computing can be realized and new
research opportunities be discovered.

6.

References[1]

Berners-Lee, T., “Answers for Young People,”
http://www.w3.org/People/Berners-Lee/Kids[2]

Johanson, B., Fox, A., and Winograd T., “Theinteractive workspaces project: experiences withubiquitous computing rooms,” IEEE Pervasive
Computing, Volume 1 , Issue 2 (April 2002), pp. 67 –74, 2002[3]

The Aware Home, http://www.cc.gatech.edu/fce/ahri/[4]Brumitt B., Meyers, B., Krumm, J., Kern, A. andShafer, S., "EasyLiving: Technologies for intelligent
environments," Proc. Handheld and Ubiquitous
Computing, September 2000

[5]

The Smart-Its Project, http://www.smart-its.org/[6]

Smart Space Laboratory,
http://www.ht.sfc.keio.ac.jp/SSLab/[7]

Sun Microsystems Inc., JiniTM Network Technology,
http://wwws.sun.com/software/jini/, 2000

[8]

UPnP,
Universal
Plug
http://www.upnp.org, 2002

[9]

Brouwer-Janse, M.D., Bennett R.W., Endo, T., vanes
F.L., Strubbe, H.J., and Gentner, D.R., “Interfaces for
consumer products: 'How to camouflage thecomputer?” Proc. CHI'1992, pp. 287-290, 1992

and

Play

Forum,[10] Olsen, D. R., and Nielsen, T., “Laser PointerInteraction,” Proc. CHI '2001, pp. 17-22, 2001[11] Ward, A., Jones, A., and Hopper, A., “A new location
technique for the active office,” IEEE PersonalCommunications Magazine, Vol. 4, No. 5, pp 42-47,
1997[12] Priyantha, N.B., Miu, A.K.L., Balakrishnan, H., Teller,
S, “The Cricket Compass for contextaware mobile
applications,” Proc. MOBICOM 2001, 2001[13] Savvides, A., Han, CC, and Strivastava, M. B.,“Dynamic fine grained localization in ad-hoc sensor
networks,” Proc. MOBICOM2001, 2001[14] Pottie, G. J., and Kaiser, W. J., “Wireless integrated
network sensors,”Comm. ACM, Vol. 43, pp. 51–58,
2000[15] SCADDS, Scalable Coordination Architectures for
Deeply Distributed Systems,
http://www.isi.edu/scadds/[16] WEBS, Wireless Embedded Systems,
http://webs.cs.berkeley.edu/[17] TinyOS, http://webs.cs.berkeley.edu/tos/[18] Minami, M., Sugita, K., Morikawa, H., and AoyamaT., “A design of internet application platform for

ubiquitous computing environment,” IEICE Trans.
Comm., vol. J85-B, no. 12, pp. 2313-2330, 2002[19] Minami, M., Morikawa, H., and Aoyama T., “Thedesign and evaluation of an interface-based naming
system for supporting service synthesis in ubiquitous
computing environment,” IEICE Trans. Comm.,
vol.J86-B, no.5, pp.777-789. 2003