Transcript Ph.D. defense presentation

Context-aware, Ubiquitous
Service Discovery and Delivery
for Mobile Clients
Choonhwa Lee
Department of Computer and Information Science
and Engineering
University of Florida
May 2, 2003
Outline







Introduction
Related Research
Overall Architecture for Mobile Service Discovery
Context-aware Service Discovery
Global Service Discovery Protocol
Thin-client Adaptation Service Delivery
Summary and Future Research Issues
Pervasive & Ubiquitous Computing
Category
Device
Network
Constituent Technologies and Challenges
Processing capability, form factors, power efficiency,
universal information appliance
Wireless communication, mobility support, automatic
configuration, resource discovery, spontaneous interaction
Environment Location awareness, context sensing, sensor network
Software
Information
Access
User
Interface
Context information handling, adaptation, dynamic service
composition and partitioning
Ubiquitous data access, agent, collaboration, knowledge
access
Perceptual technologies, biometrics, context-aware
computing, multiple modality, implicit input, output device
coordination
Applications vs. Services

Applications follow the traditional install model
 Services follow discovery, lease, use, and discard
model
 Affinity of the service model to ubiquitous and
pervasive.
– Stumble over a new printer to which use has no driver
– Location-based services: a nearby printer
– Location sensing component: GPS  indoor location
service
Mobile & Ubiquitous Service
Discovery

Ubiquitous/Pervasive/Invisible Computing
– Interactions modeled as impromptu service transactions,
not as predefined distributed computations.

Dynamic service discovery
– The very first step towards the vision
– A superabundance of services
– User mobility and a wide range of mobile devices.

An effective infrastructure is a key to enabling
pervasive and ubiquitous computing.
Multi-layer Discovery Paradigm
Service Delivery & Interaction
Service Discovery
Context
Context Discovery
Infrastructure Discovery

Context-aware service discovery
– The right services to the right users
– At the right time and place, in the form and delivery mode
most appropriate to the mobile device

Tightly coupled by implicitly captured context
information
Dissertation Scope
Service
Service
provider
Static/Context attr.
Service Advertisement
Service
Invocation
Service
Static attr.
Context attr.
Service
directory
Service
Discovery

User
query
Device
profile
Client



Integrated service discovery framework
Context-aware service discovery
Global service discovery protocol
Thin-client-based service delivery
Outline







Introduction
Related Research
Overall Architecture for Mobile Service Discovery
Context-aware Service Discovery
Global Service Discovery Protocol
Thin-client Adaptation Service Delivery
Summary and Future Research Issues
Service Discovery Protocols

Service Discovery Protocol [LH02]
– Service discovery is relatively new (in the late 1990s).
– IETF SLP, Sun Jini, UPnP, and Salutation
– Announce-listen model (Soft state model)

Ad-hoc Service Discovery
– IBM DEAPSpace
– Konark Service Gossip Protocol [LHD+03][HDV+03]

Wide-area Service Discovery
– Wide-area extension to SLP (WASRV)
– Berkeley Secure Service Discovery Service (SSDS)
Sever Selection Mechanisms

Selection of the best among replicated servers
– Availability, fault-tolerance, load-balance, and scalability

Server-side approach
– HTTP redirect

Network-side approach
– DNS round-robin, DNS LOC RR, DNS GL RR
– IP Anycast, Cisco DistributedRouter
– IETF RSerPool (Reliable Server Pooling)

Client-side approach
– SmartClient
Service Delivery

Four approaches to service delivery to mobile
devices
–
–
–
–
Device-specific authoring
Multiple-device authoring
Client-side navigation
Automatic re-authoring

Jini ServiceUI project
 XML-based, device-independent presentation
– W3C DI and CC/PP Work Groups
Outline







Introduction
Related Research
Overall Architecture for Mobile Service Discovery
Context-aware Service Discovery
Global Service Discovery Protocol
Thin-client Adaptation Service Delivery
Summary and Future Research Issues
Three-tier Discovery Architecture

Goal
– To provide the most appropriate service to mobile users by
exploiting any meaningful context information

Service classification by coverage
Service class
Coverage
Primary selection
criteria
Example
Proximity service
Local area
Proximity
Nearby printer
Domain service
Domain
Global service
Proximity and service Area guide service
features
Global area Service quality, user
Media service,
memory, or
storage service
availability
Conceptual Model of the
Three-tier Discovery Architecture
Services
Contexts
Service
Profile
Device
Description
Other Context
Information
•Different selection criteria
•Guided selection
•User transparency
•Scalability (Performance)
BA
GSR
Proximity Services
Domain Services
Profile Server
at home
Global Services
Domain Discovery Sub-system

On-campus registry hierarchy example
campus
…
CSE Bld
MSL Bld
…
Printer
serivce
4th floor
3rd floor
Printer?
…
E 451
E467
Global Service Discovery
…
Domain hierarchy
GSR
BA
GSR-capable registry
BA-capable registry
…
Domain-3
GSR
Domain-2
BA
service
BA
BA
Domain-1
Client
Outline







Introduction
Related Research
Overall Architecture for Mobile Service Discovery
Context-aware Service Discovery
Global Service Discovery Protocol
Thin-client Adaptation Service Delivery
Summary and Future Research Issues
Current Service Discovery
Technologies

Diverse service description model
– Java interface and object, string-based attribute-value pairs,
XML description, and ISO 8824 ASN.1

Service matching based on declarative, static service
description
 Limited capability to capture context
– An unmanageably large set of candidate service instances
(similar situation to Web search engines)
– A much broader range of service quality
– Minimal service selection and filtering support: manual
selection
Sun Jini
Srv proxy attrs
Srv proxy attrs
Lookup service
Discovery
Srv proxy attrs
Client


Announcement
Service
invocation
Service
Service provider
Static only attributes: Address, Comment, Location, Name,
ServiceInfo, ServiceType, Status, and StatusType
Bit-wise attribute matching (equality matching only)
A Proposal for Context-aware Jini

Context attribute that embodies service-specific selection logic
for discovery or pre-condition for propagation
 Static attribute matching  A candidate service set  Context
attribute evaluation  A smaller set of qualified services
service proxy
object

static
attr.
static
attr.
…
context
attr.
A framework for any service-specific selection logic: a general
agreement and its real implementation
 Provided by service authors and blindly evaluated by JLS (Jini
Lookup Service) without having any knowledge of the internals
 Dynamic service selection that captures various kinds of service
qualities (including communication- and application-related
aspects)
 Evaluation result is cached by JLS
 Transparent to clients (backward compatibility)
Implementation of Context Attributes




Built on Sun’s Jini reference implementation v1.2
Support for remote and local context attributes
Discovery and advertisement context attributes
Service registry interconnection
– Extend JLS to implement a prototype of the domain
service discovery system
– Service discovery, advertisement, and lease
management along the hierarchy


No change to standard Jini APIs
Deployment: Harris lab
A Sample Context Attribute
public interface RDContextEvaluator extends Remote {
ContextEvaluation evaluate() throws RemoteException;
}
public class ContextEvaluation implements Serializable {
long validUntil;
// duration + current time.
long contextIndex; // indicates service quality.
}
public abstract class AbstractRDContextEntry extends AbstractEntry implements RDContextEvaluator {
public Object rObj;
public ContextEvaluation val;
}
import net.jini.lookup.entry.AbsractRDContextEntry;
import net.jini.lookup.entry.ContextEvaluation;
public class ServerLoad extends AbstractRDContextEntry {
public ServerLoad() throws RemoteException {}
private long getSystemLoad() {
// get current load and return it
}
public ContextEvaluation evaluate() throws RemoteException {
long sysLoad = getSystemLoad();
return new ContextEvaluation(1*60*1000, MAX_LOAD – sysLoad);
}
}
Context Attribute Processing
ServiceMatches lookup(ServcieTemplate tmpl, int maxMatches) {
int candidateSetSize = maxMatches * CANDSETSIZE;
candidates = slookup(tmpl, candidateSetSize);
for (each instance in candidates.items) {
if (it has an instance of Abstract[LD|RD]ContextEntry) {
if (previous evaluation expired)
evaluate the context attribute;
}
}
sort the candidate set according to contextIndex
remove context attributes from each service;
return top maxMatches instances;
}
Service Registry Performance

Sun Ultra-60 with 512M RAM, running J2SE v1.3.1_02
load
domain
location
ping

100000
CPU time (msec)


10000

1000

Measure added overhead of context attributes
Context evaluation result caching disabled
Static attribute: Location
Context attribute: Domain, Load, and Ping
Additional CPU time for 10 srv instances
–
100

10
Additional CPU time for 1,000 srv instgances
–
1

1
10
100
Number of returned service instances
Jini lookup service performance
1000
54ms (Location 139ms, Ping 193ms)
12,002ms (Location 1,657ms, Ping 13,659ms)
Service registry need accommodate
additional CPU cycles to provide scalable
context evaluation
Service Registry Performance (Cont.)

CPU time (percentage)
TaskThread.run()
ContextTask.run()
Ping.evaluate()

90

80

70

60

50
40
Anatomy of CPU time spent on context
evaluation in the case of Ping attribute
Context evaluation result caching disabled
TaskThread: thread package used by JLS
ContextTask: instance for context evaluation
Ping.evaluate(): pure evaluation time
Analysis to be used to optimize service
registry performance
30
20
Multithread execution and
switching
10
0
ping-1
ping-10
ping-100
ping-1000
Nubmer of returned service instances
Composition of lookup service CPU time
Thread synchronization to access
a shared data structure
Client Experiments
Lookup time (msec)
compute
dictionary
ftp


12000
10000
8000


6000
4000
2000
0

static miss-0 missattr.
25
miss50
miss75
miss100
Context m iss ratio (percentage)
Client lookup time


“compute” service – the “Load” attribute
“dictionary” service – the “Ping” attribute
“ftp” service – a new “Bandwidth” attribute
Service instances of service quality 1x, 2x, 4x,
8x, …, and 128x.
“miss-25” – 25% of the candidate services
have outdated context evaluation results
Context evaluation time varies across service
types and instances of the same type
Re-use of cached evaluation results
Client Experiments (Cont.)
Service time (msec)
compute
dictionary
ftp


30000
25000
20000


15000
10000
5000
0

static
attr.
cand-25 cand-50 cand-75 cand100
Candidate set size (percentage)
Service time experienced by client

“compute” service – the “Load” attribute
“dictionary” service – the “Ping” attribute
“ftp” service – a new “Bandwidth” attribute
Service instances of service quality 1x, 2x, 4x,
8x, …, and 128x.
“Service time” – time to start, use, and end
service use
“cand-25” – 25% of cached context
evaluation results are valid. Selection is made
without further evaluation.
Outline







Introduction
Related Research
Overall Architecture for Mobile Service Discovery
Context-aware Service Discovery
Global Service Discovery Protocol
Thin-client Adaptation Service Delivery
Summary and Future Research Issues
Global Service Discovery
Main obstacle – scalability of discovery or
advertisement of services.
 Introduce the concept of Popular Service
Attributes which is a classification of service
attributes based on actual service population data.
 Design and evaluate a global service discovery
protocol based on popular service attributes.

The Centroid



Whois++ index service
The Centroid is a collection of every word that appears in
service attribute value
An example of the Centroid
Color: Yellow Green
Fruit: Banana Papaya
Color: Yellow Fruit: Banana
Color: Green Fruit: Banana
Color: Green Fruit: Papaya
Class-based Service
Propagation (CSP) Protocol

The Centroid
– Every word propagates to the top, regardless of its
occurrences in the sub-tree.
– To update the whole world on every change is not scalable.

CSP protocol
– A morass of services in the future ubiquitous computing
world.
– Queries specified using popular, common attrs rather than
specific terms.


Zipf distribution
“a color ps printer” vs. “a printer with id = BB9F246063”
– Classification (first and second classes)
CSP Protocol

Class profiling threshold (pt)
– We use only first and second classes
– First class: no degradation or TTL-based degradation to
the second class
– Second class: attenuates as it propagates

Minimal word length (mw)
– The longest string length not subject to further attenuation

Attenuation unit (au)
– Unit of attenuation

CSP forces unpopular words to fade out faster,
thereby enabling quick convergence and minimizing
query penalty.
CSP TTL Degradation
Second class
propagation
First class
propagation
S1{a1=v11(4)}, TTL=1
S 1 {a 1 =v 11 (2)}
S1{a1=v11(2)}, TTL=1
S1 {a1 =v 111 (2);a2 =v21(1),v22(1)}
S 1 {a 1 =v 11 ;a 2 =v 21 }
S 1 {a 1 =v 11 ;a 2 =v 22 }
S 1 {a 1 =v 11 (1)}
S 1 {a 1 =v 11 }
S 1 {a 1 =v 11 }
S 1 {a 1 =v 11 }
TTL=ceil(log(frequency))
An Example of the 2nd Class Ad
and Query
at;ng;re;ro;so;ss;st;th
at;ng;re;so;ss;st;stre;stro;thro
“sore throat” ?
yes by “so;re;th;ro;at”
“sore throat” ?
yes by “so;re;thro;at”
sore;stress;throat
“sore throat” ?
rest;strong
yes by “sore;throat”
mw=2, au=2
CSP Protocol Simulation

Simulation workload
– The freedb CD database (http://www.freedb.org)
– DISCID, DISC TITLE, YEAR, GENRE, and TITLE0 –
TITLE5 attributes
– 4,000 records
– 255-node complete binary tree
CD Database Word Distribution

Zipf distribution
no split
1split
2 splits
3 splits
4 splits
(mw=3, au=3)
10
4 split s
9
5935)
3 Split s
8
Word frequency
(1st,
7
2 split s
6
1 Split
5
No Split
4
3
(7536th, 2)
2
1
0
0
2
4
6
Word popularity
8
10
Query Performance
aggregation-2
aggregation-3
aggregation-4
centroid
25

Number of hops
20


15
10

5

0
ratio 2:0
ratio 2:1
ratio 2:2
ratio 2:3
General-to-specific query ratio
ratio 2:4
“aggregation-n” indicates
“mw=n” and “au=n.”
General: YEAR, GENRE
Specific: DISC ID, DISC
TITLE, SONG TITLE0 –
TITLE5
2,040 services over the
255-node tree
255 queries
Database Size and Update Traffic
by Layers
16000
300000
14000
250000
12000
aggregation-2
aggregation-3
150000
aggregation-4
centroid
100000
Update traffic
Database size
200000
10000
aggregation-2
aggregation-3
8000
aggregation-4
centroid
6000
4000
50000
2000
0
0
0
1
2
3
4
5
6
7
Tree depth
2040 services over the 255-node tree
0
1
2
3
4
5
6
Tree depth
127 service insertions to the 255-node tree
with 2040 services pre-loaded
Outline







Introduction
Related Research
Overall Architecture for Mobile Service Discovery
Context-aware Service Discovery
Global Service Discovery Protocol
Thin-client Adaptation Service Delivery
Summary and Future Research Issues
The Jini Proxy System

VTC (Virtual Thin Client) approach to
service delivery
 Built on top of Sun Jini and AT&T VNC
 Smart-phone client (J2ME capable phone)
 Three delivery modes
- Client executable
- MIDlet service emulation
- J2SE service emulation
Overall Jini System Architecture
Jini Lookup Services
Client Device
Jini Proxy
Application Space
ResidentClient
Jini
Protocol
VTC
Client
Jini Protocol
MIDP
JAM
CLDC
KVM
Dispatcher
Verifier
Adapter
VTC Server
MIDlet Emulator
VNC Channel
PNG Support
VNC
Jini Services
MIDlet Emulator
(4) Display update
KVM
event
(3) KVM
event
(3) KVM
event
X11
input
event
MIDlet
runner
(2) Jini
protocol
Jini
Proxy
(1) VNC server
pool
VNC desktop pool

“Disappearing software” [Roy Want et. al]
Performance Measurement
Comparison of Local Execution Startup
and VTC Startup
300
Seconds
250
200
Local Execution
150
VTC
100
50
0
iCoffee
~35kB Jar
File
Shopping
~23kB Jar
File
PhoneClient
~24kB Jar
File
MIDlet Name & Size
MapIt ~34kB
Jar File
Summary

Multi-layer discovery paradigm
– Context information as component integrator

A three-tier mobile service discovery architecture
– Context-aware service discovery framework and prototype
– Class-based Service Propagation protocol and simulation
study
– Adaptive thin-client based service delivery prototype
Future Research Issues

Ad-hoc service discovery proxy
 CC/PP support
 Extended Context-aware Service Discovery
Model