Architecture for Providing Services in the Ubiquitous Computing Environment

Abstract

Computing and telecommunications are maturing, and Ubiquitous computing has become quite interesting as a new environment in which to seek new services. The goal of Ubiquitous computing is the enhancement of computer utilization by making many computers available throughout the physical environment, but making them effectively invisible to the user. The goal of services in the ubiquitous environment is not making either services or appliances the center of attention, but rather enhancing users’ lives in an unobtrusive manner. In the ubiquitous computing environment, services should be triggered by environmental situations instead of user’s explicit actions. This paper analyzes the triggers needed to provide services from the viewpoint of time, location and objects, shows an architecture to achieve services in the ubiquitous computing environment, and presents a prototype of the real world model for the service platform.

Full text

Page 1

Architecture for Providing Services in the Ubiquitous Computing Environment
Goro KUNITOKenji SAKAMOTO Naoharu YAMADA
Satoshi TANAKA
Network Laboratories, NTT DoCoMo, Inc.
3-5, Hikari-no-oka, Yokosuka, Kanagawa, 239-0807 JAPAN
{kunito,sakamoto,yamada,tatsuo,satoshi}@netlab.nttdocomo.co.jp
Tatsuo TAKAKASHI
Abstract
Computing and telecommunications are maturing, and
Ubiquitous computing has become quite interesting as a
new environment in which to seek new services. The goal
of Ubiquitous computing is the enhancement of computer
utilization by making many computers available through-
out the physical environment, but making them effectively
invisible to the user. The goal of services in the ubiquitous
environment is not making either services or appliances the
center of attention, but rather enhancing users’ lives in an
unobtrusive manner.
In the ubiquitous computing environment, services
should be triggered by environmental situations instead of
user’s explicit actions. This paper analyzes the triggers
needed to provide services from the viewpoint of time, place
and things, shows an architecture to achieve services in the
ubiquitous computing environment, and presents a proto-
type of the real world model for the service platform.
1. Introduction
The growth of processors has raised the computing ca-
pability of appliances around us such as PDAs, PCs and
mobile phones. Processors are embedded in not only infor-
mation appliances but simpler home appliances, and now
we are surrounded by processors. The prevalence of fixed
Internet connections now permits many appliances to be
connected to the Internet, and it is now considered real-
istic to expect that all devices will soon be connected to
the network. the next step appears to be the emergence of
the environment [1] In this environment, it is expected that
3CEV[2] will be realized, where not only cyber contents
such as movies and voice but be accessible, but also even
physical things as detected by RFID tag or sensors. The
ubiquitous computing environment that Mark Weiser pro-
posed means that a huge number of computers will exist
around us and work without disturbing the user’s conscious-
ness as they appear to be invisible. That is, a computer is a
tool and the user should concentrate on the subject at hand
instead of the tool.
The most basic and important requirement to providing
services in the ubiquitous computing environment is to be
able to recognize the situation in the real world. If a system
can recognize the user’s situation in sufficient depth, appro-
priate services could be triggered without the user’s explicit
action. As an example, if your purse is watched by a secu-
rity service, the service would alert you if you drop it.
The rest of this paper is structured as follows. Section 2
begins by introducing services based on the real world in-
formation. Section 3 analyzes conditions related to the trig-
gering of services, and Section 4 describes an architecture
that provides services in the ubiquitous computing environ-
ment. A prototype service is described in Section 5 and
Section 6 concludes this paper.
2. Providing services based on the real world
situations
We feel that we are provided services though comput-
ers, because we are conscious of concentrating on the ap-
pliance used to provide the service. For example, we of-
ten concentrate on operating the PC when we try to buy
something on the Web. In the ubiquitous computing envi-
ronment, huge numbers of computers will be embedded in
the environment, but they will work without being noticed
by anyone. In such an environment services should be pro-
vided to support the user’s activity without disturbing the
user’s consciousness.
We consider 3 points in order to achieve these services.
The first is that services should be provided without the
user’s explicit order. Many appliances around us work only
when we operate them. Even if we operate them the same
way everyday, most appliances fail to learn. The reason is
that it is difficult to recognize situations in the real world,
and that most appliances have to no way of obtaining envi-
ronmental information. In the ubiquitous computing envi-
ronment, since the many embedded computers can be used
to detect environmental information, some service can be
provided without the user’s explicit action.
The second point is to make service availability very
flexible. Most current services are tightly bound to specific
appliances. In the ubiquitous computing environment, since
theservicesdemandedbytheuserwillbespecifictoaplace,
time, and user, services should be made available in flexible

Page 2

manner.
The last point is to apply things as a way of triggering
services. Since things basically have the purpose of exis-
tence and affordance [3] that offers people to do with them,
theycanspecifyuseractivities. WefocusontheRFIDtagas
a very promising tool for obtaining information in the real
world. Since RFIDs enable object id to be determined eas-
ily, they are an easy and reliable way of discerning things.
This paper focuses on the real world situation to triggers
services. We analyze the real world information obtained
by RFID tags, and introduce a system architecture that pro-
vides services.
EPC Global[4] proposed PML (Physical Markup Lan-
guage) as a description framework to bind RFID tags to ob-
ject information, however PML does not consider the var-
ious situations that can be inferred from RFID tags since
PML is mainly used for supply chain management. To an-
alyze services, this paper focus on location, timing and sur-
rounding objects since the information that we can obtain
from RFID tag are time, location and id. UbiUCAM[5]
describes how context can be collected by various sensors
from the 5W1H point of view, which is a similar approach.
Context modeling framework[6] describes context model-
ing based on situations, however it focus on human’s con-
text and analyzes situations from different viewpoint.
3. Real world situations that trigger services
In the ubiquitous computing environment, services
should be provided based on event or situation in the real
world instead of the users’ explicit instruction. In order to
achieve this, we consider a framework that models the real
world situation, determines the most appropriate services,
according to the situation, from among the many services
known. Under the framework, we try to build a model of
the real world situation; we call it ’the real world Model
(RWM).’ RWM describes various situations, events, and
states. In the framework, since services also use RWM to
determine their appropriateness, we believe that analysis of
the situations that trigger services is helpful in considering
the description of RWM. Accordingly, this section tries to
analyze the triggers needed to provide services.
We focus on RFID tags and focus on 3W (When, Where,
What) instead of the full 5W1H suite. The following sec-
tionsanalyzethesituationsthatwilltriggerservicesinterms
of time, location and objects.
3.1. Assumptions
In this section we make the following assumptions;
• Each object has an RFID tag.
• RFID tag readers are fixed.
• Locations of RFID tag readers are known.
• RFID holds only a uniq id; attribute information of the
object is stored in some database in the network.
• RFID detection history is stored a database in the net-
work
• Various services are available over the network.
3.2. Situation triggers not strictly bound to
location
The triggers not strictly associated with location fall into
5 categories as follows.
• TIME: e.g. Recipe service: a dinner recipe is sent at 5
o’clock every evening.
• DURATION: e.g. Refrigerator watching service: alert
message is sent when food is left for more than one
week in the refrigerator.
• CHANGE IN SITUATION: e.g. Lost-found service:
an alert message is sent when the loss of some item is
recognized through a change in the objects detected.
• SEQUENCE OF EVENTS: e.g. Smart elevator ser-
vice: person’s entrance is detected by entrance pass,
and when he approaches the elevator floor, detected
via RFID tags, an elevator is moved to the appropri-
ate floor.
• SEMANTICS OF TIME: e.g. Lunchbox menu ser-
vice: lunchbox menu is sent when a user boards a train
without having had lunch.
Time itself is the trigger in (1). In (2) and (3), services are
triggered by a comparison of present situation with past sit-
uation. In (4), the detection of a combination of information
triggers the service. In (5), the service is not bound to time
directly but to the semantics associated with actions.
3.3. Situation triggers associated with loca-
tion
The triggers associated with location fall into 3 cate-
gories as follows;
• ACTUAL PHYSICAL LOCATION: e.g. Advertising
service: an advertisement for ice cream is sent to peo-
ple in the park.
• RELATIVE LOCATION: e.g. Chemical watcher ser-
vice: Alert message is sent when household cleaners
that should not be mixed are placed next to each other.
• SEMANTICS ASSOCIATED WITH LOCATION:
e.g. Smart conference mode service: when several
people enter a room, the conference mode is activated.
In (1), services are bound to actual physical locations. In
(2), services are triggered by the relative location of objects.
RFID tags are not very accurate in terms of location, but the
service can be realized if more accurate sensors are avail-
able. In (3), services are bound to the current role of the
location. For instance, a room that is not normally used for
conferences can be provided with conference services if a
meeting is determined to be taking place.
3.4. Situation triggers associated with ob-
jects
The triggers associated with objects fall into 4 categories
as follows;
• EXISTENCE, NONEXISTENCE OF THINGS: e.g.
Point card notification services: notification message
2

Page 3

is sent if you have a point card at a store when you are
at the store.
• NUMBER OF THINGS: e.g. Paper empty monitor
service: an alert message is sent if there are fewer than
10 sheets in the printer tray.
• COMBINATION OF THINGS: e.g. Recipe service:
when a person passes a showcase, she receives a recipe
related to the foods in her shopping basket and in the
show case.
• SEMANTICS OF THINGS: e.g. Advertising service:
when a person who has a car is detected by the passing
of his key, an advertisement about new cars is sent.
One of the advantages of RFID tags is that they can be de-
tected even if they are not directly visible since connections
are made by microwaves. Since many company or stores
issue their own members card or point card recently, you
may often forget whether you have the point card or not
at a store. A service such as (1) enables you to make use
of your point card. In (2), the number of objects triggers
the service. In (3) services are bound to a combination of
things. Services are bound not to things themselves but the
semantics of things in (4). For instance, it is possible to in-
fer that a person who has a car key or a highway card has a
car. Therefore inference from things can be used to trigger
services.
4. Architecture for providing services in the
ubiquitous computing environment
We believe that the architecture for providing services in
the ubiquitous computing environment has four phases; ob-
taining the real world information phase (P1), building the
real world model phase (P2), service determination phase
(P3), and service provisioning phase (P4) see Fig. 1. In P1,
the real world information is retrieved from sensing devices
and stored in the network. In P2, the stored real world in-
formation is analyzed and events or situations recognized in
the real world are stored as the RWM. In P3, services to be
offered to the user are determined and the desired service
is provided in P4. The following sections describe these
phases in more detail.
Figure 1. Overview
Figure 2. Architecture of real world modeling
4.1. Obtaining the real world information
phase: P1
There are several ways of obtaining real world infor-
mation including cameras, GPS and sensors. We focus on
RFID tags; the id of an RFID tag, detected by a RFID tag
reader, is the most primitive type of real world information.
There are three categories of RFID tags: passive, active,
and hybrid. A passive tag has no battery and must be pow-
ered by the signal from the tag reader. Active tags have a
battery, and so can send their id without invocation by the
reader. Most active tags sends their id periodically. A hy-
brid tag has both characteristics.
Since an active tag has a battery, its detection range is
generally larger than that of a passive tag. A passive tag al-
lows the tag reader to determine the timing of tag reading.
On the other hand, since an active tag sends its id period-
ically, the tag reader listen continuously to detect the tag,
and it is difficult to discriminate several neighboring tags.
4.2. Building the real world model phase:
P2
The RWM represents the recognized situations and
events in the real world. We proposed three-layer descrip-
tion for the RWM that accord with abstraction levels[7].
Our architecture, shown in Fig.2, roughly consists of 4 lay-
ers. Layer 1 processes RFID ids. Layer2 retrieves informa-
tion about the objects to which the RFID tags are attached.
Layer 3 interprets the situation in the real world from data
about time, location, and objects. A more abstract interpre-
tation that involves history and semantics is performed in
layer 4. The following sections present functions to inter-
pret situations on each layer.
4.2.1. Processing detected ID information
It is necessary to process the detected IDs as follows.
Since some services are triggered by number or combina-
tion of objects as presented in section 3, it is necessary to
3

Page 4

determine groups of ID in order to count the number of ob-
jects or to detect combinations of objects. For this we as-
sume that ids that are detected by the same RFID tag reader
over a certain period can be treated as a group. We be-
lievethatthingsthatarephysicallygroupedintherealworld
have some logical relationship. Furthermore, ID processing
should mask the different characteristics of the 3 types of
RFID tags.
4.2.2. Obtaining object attributes
Since most RFID tags have very limited information
carrying capacity, basically just their id, it is necessary to
bind each id to more detailed object information. This is
achieved with an attribute DB.
4.2.3. Recognition of situations
We analyzed the situations triggering services in Section
3 from the rather simple viewpoints of time, location and
objects. To achieve recognition of situation from locally
point of view, it is necessary to determine the coordination
of points firstly, and convert description type and accuracy
of location to suit application requirements. Furthermore
recognition of relative locations between things is also re-
quired.
To achieve recognition of situation from timing point of
view, detecting time, and measuring duration are required.
Furthermore detecting coincidence of multiple events is re-
quired.
To achieve recognition of situation from thing point of
view, recognizing existence, non existence, number and
combination of things is required.
4.2.4. Recognition of semantics and history
As described in analysis in section 3, semantics of loca-
tion, semantics of time, and semantics of things can trigger
services. From function point of view, however, it is con-
sidered that common functions can be applicable to these
semantic recognitions. Semantic recognition can be catego-
rized roughly into two approaches, rule based and probabil-
ity based. In order to perform semantic recognition based
on rules, a database which binds real world information
with semantics is required. On the other hand, to achieve
recognition based on probability, it is necessary to learn the
probability.
In analysis in section 3, history based recognition is a
kind of timing condition, however, history based recogni-
tion is applicable to both locally condition and things con-
dition since transition of situations recognized under tim-
ing or things condition can also trigger services. Therefore
history based recognition can be consider as a function in-
dependent of recognition of situation from timing point of
view.
In history based recognition, comparison between situa-
tions recognized in different time makes it possible to detect
change and duration of situation, and tracking of the transi-
tions make it possible to detect sequence, cycle or pattern.
Furthermore it is consider that detecting unusual situation
and prediction would be possible this.
4.3. Service determination phase: P3
The service determination phase has two parts: service
detection phase and service coordination phase. Since we
assume that the conditions under which the service is to be
provided is described in the service itself, the service detec-
tion phase compares all known condition to the real world
situation, and lists the candidates. The service coordina-
tion phase detects similar or competitive services among the
candidates, and coordinates them. This coordination pre-
vents many redundant services from being provided.
Service Coordination phase
Service Finder phase
Model builderModel builder
??????
??????
??????
??????
??
??
??
??????
??
??
??
??
??????
??
??
??
??
??????
??
??
??
??
??
Location based
situation
??????
??????
??????
??????
??
??
??
??????
??
??
??
??
??????
??
??
??
??
??????
??
??
??
??
??
??????
??????
??????????????????
Timing based
situation
????????????????????????
?? ??????
?? ??????
?? ??????
?? ??????
Things based
situation
Real World ModelReal World Model
Location based
situation
??????
??????
??????????????????
Timing based
situation
?? ??????
?? ??????
?? ??????
Things based
situation
??????
?????? ??????
Location based
situation
??????
Location based
situation
??????
????????????
Timing based
situation
??????
Timing based
situation
?? ??????
?? ??????
?? ??????
Things based
situation
?? ??????
?? ??????
?? ??????
Things based
situation
service
DB
Service
coordination
Contention
detection
Similar service
detection
Service
Decider
Situation
search
Coincide
situation
Service
selection
serviceserviceservice
Service
contentscontentscontents
situationsituationsituationsituation
ServiceService
serviceservice
Service
contentscontents
situationsituationsituation
Service
Figure 3. Service determination phase
4.4. Service provision phase: P4
The service provision phase has three parts. In order to
provide a service, the first phase identifies information re-
lated to service provisioning, such as destination, method,
and required devices. When multiple services are to be pro-
vided simultaneously, the second phase has to resolve any
device contention by coordinating the services. Finally ser-
vices are evaluated in the last phase. Currently it is difficult
to evaluate services automatically, however, observing user
behavior would be a way of realizing this.
Service Decider Service Decider
Service ServiceService
Service
contentscontents contents
situationsituation situationsituation
ServiceService
Device
DB
Device detection Device detection
Determination of
service destinationservice destination
Determination of
provision methodprovision method
Determination phase Determination phaseDetermination phase
Determination of Determination of
Detection of
Inconsistent
servicesservices
Coordination of
inconsistent
servicesservices
Detection of
device conflict device conflict
Resolution of
device conflictdevice conflict
Coordination phase Coordination phaseCoordination phase
Detection of
Inconsistent
Coordination of
inconsistent
Detection of Resolution of
Service
Evaluation Evaluation
Evaluation phaseEvaluation phase Evaluation phase
Service
Figure 4. Service provision phase
4

Page 5

<Object id="object00002673">
<TagID>00002673</TagID>
<Name>mobile-phone</Name>
<Owner>Hanako</Owner>
<Role>mobile</Role>
</Object>
<Object id="object00002953">
<TagID>00002953</TagID>
<Name>jeans</Name>
<Owner>Taro</Owner>
<Role>merchandise</Role>
</Object>
<Object id="object00003409">
<TagID>00003409</TagID>
<Name>jeans</Name>
<Owner>Taro</Owner>
<Role>merchandise</Role>
</Object>
Figure 6. Attributes
of things
<Reader id="readerA102_1">
<ReaderID>A102_1</ReaderID>
<Name>park-reader-2</Name>
<Location>park</Location>
<Location>
<Place idref="placeP001"/>
</Location>
</Reader>
Figure 7. Attributes of a
reader
<Exist>
<Reader idref="readerA102_1"/>
<Object idref="object00002673"/>
<SSI>104</SSI>
<Motion>false</Motion>
<Timestamp>1122530522640</Timestamp>
</Exist>
(a) Existence of a thing
<ExistWith>
<Reader idref="readerA104_1"/>
<Object idref="object00023928"/>
<Object idref="object00023416"/>
<Timestamp>1122530522640</Timestamp>
</ExistWith>
(b) Existence of multiple things
Figure 8. The real world model
5. A prototype implementation
In order to verify the possibility of providing services
based on our architecture, this section presents a prototype
implementation of a service platform based on the RWM.
Although the architecture is independent of any program-
ming languages, the current implementation is built on a
Java. Weprototypeaserviceplatformandtwoservicebased
on the RWM.
Figure 5. Implemented Functions
5.1. Situations in the real world model
Our prototype implementation is built with Sun’s J2SE
version 1.4. We focus on RFID tags to obtain the real
world information as described in section 3, and our pro-
totype supports two commercial active RFID systems: RF
Code’s Spider and Mantis. We implement this system in
our laboratory, and used about 20 Mantis tags and 3 Mantis
tag readers. The tags represent things as follows: mobile
phones, jeans, coats, jackets, paper and cans, and the read-
ers represent a park reader, one of the flea market booth
reader in the park and a home reader. In this implementa-
tion, name, owner and role of things are stored as things’
attributes, which are described in XML as shown in figure
6.
We implemented functions shown in figure 5.
functions except the probability based location seman-
The
tics detection are performed based on rules generated
manually. The probability based location semantics
is detected based on Activity Spaces[8], which uses a
multi-class Naive Bayesian approach.
tion of reader is described as figure 7. <Location> park
</Location> is manually defined, and <Location><Place
idref="placeP001"/></Location> indicates meaning of
the location recognized by the probability based location
semantics detection function.
The RWM is described by primitive situations described
as table 1. EXIST is recognized by detection of RFID tags,
The representa-
Table 1. Implemented situations
Situations
EXIST
EXISTWITH
APPEAR
Meanings
existence of a thing
existence of multiple things
appearance of a thing within the detection
range of a reader
disappearance of a thing within the detection
range of a reader
movement of a thing
taking up a thing
DISAPPEAR
MOVE
TAKEUP
and when multiple RFID tags are detected by a same tag
reader, EXISTWITH is recognized. If a RFID tag, which
is not detected before, is detected, APPEAR is recognized.
On the other hand, DISAPPEAR is recognized if a RFID
tag, which is detected before, is not detected. MOVE is de-
tected when a tag is detected by a different tag reader from a
tag reader which detected the tag before. In addition, since
Mantis tags which we used have motion sensors, which en-
able TAKEUP to be recognized.
The RWM is written in XML. Figure 8 shows a part of
the RWM generated from detected RFID tag information.
Figure 8(a) and (b) indicate examples of EXIST and EX-
ISTWITH respectively. Since the transmission interval of
the available Mantis tag is 7 seconds, the RWM is built ev-
ery 7 seconds.
5.2. Service scenarios
We implemented two services, context aware informa-
tion provision service (fig. 9) and real world search engine
service (fig. 11). The scenarios of them are as follows;
5