Pervasive Computing

Systems

Rahul Banerjee
Computer Science & Information Systems Group

Summary Notes
<For internal use by students of CS G 541/ SS ZG 531>

October 2005

BITS-Pilani
 Contents
Preface

Chapters
1 Introduction
1.1 Elements of Pervasive Computing Systems
1.2 Pervasive Computing Devices
1.2.1 Basic Aspects
1.2.2 Technology Aspects
1.2.3 Connectivity Aspects
1.3 Operating System Aspects
1.4 Interfacing Aspects
1.5 Voice-Recognition Technology Aspects

2 Design of Pervasive Computing Systems

2.1 Design of Pervasive Computing Hardware Systems
2.2 Design of Pervasive Computing Software Systems

3 Security of Pervasive Computing Systems

NA
4 Elements of Wearable Computing Systems
4.1 Wearable Computing Architectures
4.2 Design of Wearable Computing Systems
4.3 Security of Wearable Computing Systems

5 Case Studies of Select Pervasive Computing Systems

NA
Appendix-1: Programming aspects of pervasive computing
Appendix-2: Major research initiatives around the world
Appendix-3: Select Exercises and their indicative solutions

Bibliography

Index
 1
Introduction

Pervasive Computing is a technology that pervades the users’ environment by making

use of multiple independent information devices (both fixed and mobile, homogeneous
or heterogeneous) interconnected seamlessly through wireless or wired computer
communication networks which are aimed to provide a class of computing / sensory /
communication services to a class of users, preferably transparently and can provide
personalized services while ensuring a fair degree of privacy / non-intrusiveness.

It may also be seen as the as the technology that is a combination of Personal computing
technology and one or more of the following:
• Internetworking technology
• Invisible computing technology
• Wearable computing technology
• Mobile Computing Technology

1.1 Elements of Pervasive Computing Systems

Components of Infrastructure for Pervasive Computing include Mobile computing
devices, Fixed computing devices, Multimode RF Mobile communication infrastructure
<Fixed-to-Mobile and Mobile-to-Fixed communication system interfaces>, Trust system
(security and privacy), Protocol stacks and Personalized service frameworks.

What should the Infrastructure provide?

• Pervasive Computing Infrastructure has to comprise of computing

elements, communicating elements, sensors, actuators, and interface
devices.
• Computation to be available widely and freely (not free of cost).
• Intermittent connectivity has to be a supported feature due to physical
limitations pertaining to power, cost, bandwidth and network congestion.
• Bluetooth and other choices address small-distance networking issues
and allow intermittent connection.
• The infrastructure has to offer seamless connectivity to the devices /
entities / services.
• It has to support placement and location of uniquely identifiable
“information tags / trackable tags” to all devices / entities in the
Pervasive Computing environment.
• User’s environment must be able to be aware of the user’s context.

Roaming Environment: An environment that allows connectivity and communication to

the services outside the home zone is called a Roaming Environment. Some sample
devices that may involve Roaming-based access <fixed / mobile roaming>:
• PDAs / Palmtops / Pocket PCs / Cell phones / Smart phones / WAP
phones
• Laptops / Tablet PCs / Notebook PCs
• Desktop PCs / Se rvers / Web TVs
• Kiosks
• Invisible computing devices / Smart interactive posters
• Wearable computers
1.2 Pervasive Computing Devices
1.2.1 Basic Aspects

Device Technology for Pervasive Computing include Power-provisioning technologies,

Display technologies, Memory technologies, Communication technologies, Processor
technologies, Interfacing technologies, Sensor Technologies and Authentication
Technologies.

1.2.2 Technology Aspects

Low-power Device Technologies

Since many of the devices involved in the pervasive computing environment may have to
be small in size and may have to live on their battery / power units, consumption of
lower power, extension of power provisioning period etc. assume critical significance. In
addition, prevention from excessive heating also requires attention. Power requirements
can be reduced by several means right from material selection and chip-level designing
to software designing and communication system designing. Power provisioning
technology including the Battery design technology plays a very important role in the
process.

Batteries as Power Provisioning Devices

• Key issue: Size and weight of the batteries versus the power capacity and
price
• Bottleneck: Relatively slower advances in the battery technology
compared to those in other fields like display and storage technologies
• Major choices available: Nickel-Cadmium (NiCd: 12-27 hrs. standby
time), Nickel-Metal-Hydride (NiMH: 16-37 hrs. standby time), Lithium-
Ion (Li-ion: 21-50 hrs. standby time), Lithium-Polymer Cell based
batteries (> 60 hrs. standby time, flexible shapes) etc.

Display Device Technologies

Not all pervasive computing devices need display elements but those needing them may
have a range of different requirements in terms of:
– Display-size
– Display-shape
– Display-resolution
– Display-colour richness
– Display viewing angles to be supported
– Display power provisioning constraints
– Display refresh rates etc.

Major Display Device Technologies

• Cathode Ray Tube based Displays (CRTs)
• Liquid Crystal Displays (LCDs)
o Active Matrix Displays
§ Thin Film Transistor Displays (TFTs)
o Passive Matrix displays
§ Single Scan Displays (Colour Super-Twist Nematic:
CSTNs)
§ Dual Scan Displays (Dual Super-Twist Nematic: DSTN)
§ High-Performance Addressing displays (HPAs)
• Light Emitting Diode based Displays (LEDs)
 • Organic LED based Displays (OLEDs)
• Light-Emitting Polymer based Displays (LEPs)
• Chip-on-Glass Displays (CoGs)
• Liquid Crystal on Glass Displays (LCoGs)

1.2.3 Connectivity Aspects

Role of communication architectures in pervasiveness

• The pervasive computing system needs at least two basic elements to be
pervading everywhere they are required to pervade:
o Computing elements to take care of computational needs; and,
o Communication elements to interconnect these computing
elements either through wires or wirelessly (with / without
mobility).
• From the end user’s perspective and in many a practical situations, the
wireless communication based mobile computing is becoming
increasingly important.
• From the back-end systems’ viewpoint, however, due to its sheer traffic
volume, low error rates, better noise immunity and low cost, the wireline
communication based computing still remains an attractive option.
• Therefore, hybrid architectures will possibly continue to exist even
though end users may not be even aware of it.

Identifying multi-technology mobile communication architectures of relevance

• Several generations
• Gradual enhancements
• Coexistence & transition

Generations of Wireless Communication Networking Standards

• First Generation Global Mobile Radio standard : 1G
o Only voice, No data
• Second Generation Global Mobile Radio standard : 2G
o GSM: 9.6 Kbps <circuit switched voice / data>
o Enhanced Second Generation Global Mobile Radio standard :
2.5G
§ GSM-GPRS <combination of circuit and packet switched
voice / data>
§ GPRS-136: <100Kbps <packet switched>
• Third Generation Global Mobile Radio standard: 3G
o CDMA2000, =< 2Mbps <packet switched voice / data>
• Fourth Generation Global Mobile Radio standard : 4G (near future)
o ? 20-40 Mbps <packet switched voice / data>

Inside the GSM Network Subsystem

• MSC (Mobile Services Switching Center) acts like a normal switching
node and provides the connection to the fixed networks (such as the
PSTN or ISDN).
• HLR (Home Location Register ) contains information of each subscriber
registered in the corresponding GSM network, along with the current
location of the mobile. There is logically one HLR per GSM network
• VLR (Visitor Location Register) contains selected information from the
HLR, necessary for call control and provision of the subscribed services
 and each mobile currently located in the geographical area controlled by
the VLR.
• EIR (The Equipment Identity Register) is a database that contains a list
of all valid mobile equipment on the network,
• AuC (The Authentication Center) is a protected database:secret key of
SIM

GSM uses TDMA/FDMA to share the limited radio spectrum wherein the FDMA part
divides frequency of the not more than 25 MHz B/W into 124 carrier frequencies spaced
200 kHz apart.; and Each of these carrier frequencies is then divided in time, using a
TDMA scheme. GSM is a circuit-switched digital network.

SGSN (the Serving GPRS Support Node) keeps track of the location of the mobile
within its service area and send/receive packets from the mobile , passing them on, or
receiving them from the GGSN. GGSN (Gateway GPRS Support Node) converts the
GSM packets into other packet protocols (e.g. IP / X.25) and sends them out into
another network.

• GPRS users can share the resource (Radio link) which is used only when
users are actually sending or receiving data.
• GPRS is based on GMSK which is a modulation technique known as
Gaussian minimum-shift keying. It can support a theoretical upper limit
of speed up to 171.2kbps as against the GSM ‘s 9.6Kbps.
• In GPRS, a channel that is 200kHz wide, is divided into 8 separate data
streams, each carrying maximum 20kbps(14.4kbps typical) whereas in
GSM we use only one channel.

The 3G:

• 3G Stands for the Third Generation,

• Used in the context of new wireless mobile communication systems /
services,
• Leverages the progress made in cellular technologies with the advances
made in the Internet-based communication / services and the fixed
wireline communication technologies,
• Is a general-purpose communication network / service architecture,
• Allows freedom to end users from being aware of location of request /
provision of services,
• Puts more emphasis on the services than on the underlying delivery
technologies,
• Aims to play a key role in aiding the On-Demand service paradigm.
• Is not a single -technology architecture; instead allows a multi-technology
solution.

Processor technologies
• Intel’s SpeedStep processor technology
Intel’s SpeedstepTM technology based processors and their
successors are capable of:
• Changing the internal clock frequencies
• Adapting core voltage to changes in power supply
• Switching of selective parts of the CPU cores / CPU on or
off depending on whether the current calculations
require them to be available
 • Using the reduced the clock rate and voltage of the
processor core while on batteries, leading to significant
power saving.
• Switching between these modes is transparent to user and
is usually fast <however, while the system is connected to
external power supply, the full clock rate and core
voltage is available to processor resulting into maximum
performance>

• Transmeta’s Crusoe processor technology

• Total number of transistors are reduced in an attempt to
save the power consumption
• Software replaces the functionalities which otherwise
would have been provided in hardware by the eliminated
set of transistors
• Software dynamically translates the original instructions
into another set of instruction for the processor
• A technology called LongRunTM reduces the power
consumption even more by reducing the processor's
voltage on the fly when processor is idle

• Motorola’s Dragon Ball processor technology

• Deprecated now!

• Intel’s X-Scale processor technology

• This is next generation of ARM -processors that have
replaced the Intel StrongARM series

Memory Technologies
• Register class elements
• Cache memory elements
• Primary Memory elements
o RAM
§ SRAM
§ DRAM
§ Ut-RAM
§ MRAM
§ FRAM
§ MBM
o ROM
• Secondary Memory
o Flash Disks
o Magnetic Disks
o Optical Disks
o Magento-Optical Storages
o Magentic Tape Storage

1.3 Operating System Aspects

Operating Systems for Pervasive Computing Environments
• Types of Operating Systems
o Classification based on location of functionalities:
§ Centralised OSes
§ Networked OSes
§ Distributed OSes
 o Classification based on Kernel / Core Styling
§ Monolithic Kernel based OSes
§ Microkernel based OSes
§ Exokernel based OSes
o Classification based on hardware form-factor and scope
§ Server-class OSes (with and without real-time support)
§ Workstation-class OSes (with and without real-time
support)
§ Embedded OSes (with and without real-time support)

Identifying Requirements of Operating Systems for Pervasive Computing Systems

• Identify classes of applications to be run atop the target OS
• Estimate the exact set of corresponding functionalities to be supported at
the lower levels
• Identify additional performance and security-specific constraints that
may be required to be satisfied
• Identify the hardware architectures over which the solution is expected
to be built
• Identify the availability of ready-to-use device drivers for the devices
expected to be supported
• Weigh the effects of various trade-offs at the OS-level to affect the
targeted class / classes of applications

A Brief Comparison of Select Operating Systems

• Symbian OS:
o Set of application engines for PIM, messaging, browsing; object
exchanging (e,g. vCalendar & vCard);
o Integrated APIs for data management, text, clipboard and
graphics
o Multithreaded kernel with real-time support
o Support for a range of CPU architectures, peripherals, memory
types
o Support for a range of messaging systems including multimedia
messaging (MMS), SMS; internet mail using POP3, IMAP4,
SMTP etc. with attachments
o Support for audio / video recording / playback / streaming;
image conversion; voice recognition etc.
o Support for protocols including TCP/IP (dual mode IPv4/IPv6)
and WAP; infrared (IrDA), Blue tooth, USB;
o Support for multihoming capabilities and link layer Quality-of-
Service (QoS) on GPRS/UMTS networks
o Support for 3G along with GSM circuit switched voice and data
and packet-based data (GPRS and EGPRS); CDMA circuit
switched voice, data and packet-based data (IS -95, cdma2000 1x,
and WCDMA);
o Extensible telephony subsystem APIs
o Support for Internationalisation through the Unicode Standard
version 3.0
o Over-the-air (OTA) data synchronization support using
SyncML; PC-based synchronization over serial, Bluetooth,
Infrared and USB; a PC Connectivity framework providing the
ability to transfer files and synchronize PIM data
o Support for device management
 o Support for security through full encryption and certificate
management, secure protocols (HTTPS, SSL and TLS), WIM
framework and certificate -based application installation
o Support for content development options for C++, Java (J2ME)
WAP etc.;
o Support for variety of user inputs – generic input mechanism
supporting full keyboard, 0-9*# (numeric mobile phone keypad),
voice, handwriting recognition and predictive text input.

• Variants of Microsoft Windows

o Windows XP Embedded
o WinCE
§ Memory management:
§ Support for protected Virtual Memory Management
(upto 32 MB per process), special heap-support for File
System / Registry / Object Store <max. size of Object
Store:256 MB>
§ Security:
§ Support for cryptography with a Crypto Library+
Crypto API, support for SD and Smart Cards
§ Footprint:
§ About 400 kb for the OS Core / Kernel
§ About 3 MB with Kernel + all modules
§ About 8 MB with Kernel + all modules + MS Word /
PowerPoint / IE etc.
§ User-interface:
§ Simple, intuitive, generally consistent, Menu-driven,
Iconic
§ User management:
§ Designed for single user support only
§ Energy-awareness aspects:
§ Support for energy-saving enabled at the kernel level

• Variants of Linux
o ARM-Linux
o BlueCat Embedded Linux
o RT-Linux
• PalmOS
• QNX Neutrino
• Variants of JavaOS
o JavaOS
o Java for Business
• BeOS

Major constraints specific to recognition accuracy of Speech Recognition Systems as

components of pervasive computing environment:
• Resource availability in terms of processing power, memory and
available time for each instance of recognition
• Complexity due to isolated and continuous recognition needs,
• Secondary storage’s capability to store required supporting data
affecting dictionary and other data
• Context-variance implications
 • Complexity arising out of Speaker-dependent and Speaker-independent
device requirements
• Extent of training needed and its regulation
• Security and other implications

1.4 Interfacing Aspects

Interfacing technologies
Respective significance of Fitaly, Tegic T9, Octave methods of keyboards vis -à-vis
traditional QWERTY layout based keyboards / keypads, in the context of mobile
handheld devices:
§ Fitaly:
• Merit / Significance: Speeds up input of text, letters
selected as per likely occurrence frequencies and
ensuring minimization of inter-letter travel distance (to
no more than 2 positions), supports 220 ANSI/ISO Latin-
1 character set, supports accents, available in on-screen
as well as mechanical forms
• Demerit: Specific to English language’s estimated usage
patterns, needs to be practiced for a while before use,
needs to learn ‘sliding’ for accents’ use etc.

§ Tegic T9:
• Merit / Significance: Requires lesser number of
keystrokes for textual input due to support for predictive
text by combining use of dictionary and linguistic rules’
embedding, resolution of word-ambiguity is supported
through prompts, available in on-screen as well as
mechanical forms
• Demerit: Requires sizeable software support and
computing resources (instruction cycles and memory)
§ Octave:
• Merit / Significance: Commands available to support
multiple language dictionaries, available in on-screen as
well as mechanical forms although second form is more
popular, gesture -based iconic support for certain
insertions, word-recognition supported by dictionary,
ability to resolve stroke-ambiguity with the help of
dictionary
• Demerit: Requires sizeable software support and
computing resources (instruction cycles and memory)

§ Traditional QWERTY:
• Merit / Significance: Simplicity in design and use,
available in on-screen as well as mechanical forms
• Demerit: Requires more space and may be difficult in use
in case of devices with very small form-factor

Major Interfacing technologies:

• Navigation technologies
• Haptic interfacing technologies
• On-screen / Touch-panel technologies
• Voice interfacing technologies
• Video-interfacing technologies
• Handwriting-based interfacing technologies
• Hybrid interfacing technologies
 2
Design of Pervasive Computing Systems

Pervasive Computing System Design Approaches

Recollect that Four Principles of Pervasive Computing are:
• Distributedness / Decentralization
• Diversification / Specialized services
• Connectivity (regular or intermittent)
• Simplicity

Possible solution approaches

• Top-down approach
• Bottom-up approach
• Hybrid approach
• Ad-hoc / one -off approach

Each approach may involve usual steps of analysis, streamlining of specifications,

identification of constraints, issues and choices; and finally, validation through formal or
informal methods.

Principal issues related to design of Pervasive Computing Systems include:

• Feature -specific issues
• Form-factor-(size)-specific issues
• Power-provisioning issues
• Weight-specific issues
• Shape -specific issues
• Cooling-specific issues
• Connectivity-specific issues
• User Interface -specific issues
• Body-safety-specific issues <not for all devices>
• Security-specific issues
• Processor-choice-specific issues
• Operating System-specific issues
• Development and execution-environment-specific issues
• Cost-specific issues
• Regulatory issues

Criteria for acceptable pervasive computing design solutions include characteristics like
the
• Privacy & Security
• Effectiveness of Approach Across Networks
• Economic considerations
• Quality considerations
• Monitoring mechanisms
• Adaptability and Flexibility
• Practicability
• Sustainability
 4
Elements of Wearable Computing Systems

Wearable versus Pervasive / Computing

Wearable computing has Computers/sensors on people whereas in the Pervasive computing,
Computer/sensors are embedded in the environment. Wearable systems know more about
people whereas the Pervasive Computing Systems know more about environment. Both are
complimentary.

Performance Evaluation of Wearable Computers

Systematic performance evaluation may include:
Many types of communication mechanisms may be used:

Introduction to the BITS Wearable Computing Project

The “Project BITS-WearComp” research programme
Conceptualized in 1999
Started in the early 2000
First white paper and roadmap published in 2001
First specific project, the BITS-Lifeguard, begun in May 2001 <Blueprint discussed at the
NGNi’s Brussels Meet in May 2001>
Objectives:
Saving human lives with the help of non-intrusive wearable computing devices
Using the advances in computer communication and networking technologies to complement
the wearable device capabilities

A little bit about the BITS-Lifeguard system

This research aims to protect human lives from those road accidents that result from the
reduced levels of the physical fitness or mental alertness of the driver.
Initially, it is focusing on light vehicles and their drivers / occupants. However, the concept is
easily extensible to large vehicles and their drivers / occupants as well.
This research also draws on the works done by life scientists on human sensory system, brain
and select externally measurable parameters (that can be measured, calibrated or accurately
estimated without piercing human body).

Motivation behind
the BITS-Lifeguard system
More people die of road accidents than due to natural calamities or other reasons
Out of these road accidents, as per various reports,
About 8% accidents were due to mechanical problems / failures in the vehicle
About 12% accidents were found to be due to traffic violations, wrong assessment of the
situation-on-hand by the driver or activities that tend to distract drivers (including changing
cassettes / CDs / speaking on mobile etc.)
Approximately, 73% of the accidents were attributed to the possibilities that the driver’s
physical and mental alertness levels may have been unfit for driving at the time of accident
Remaining 7% accidents were accounted to various reasons including those of suicidal
attempts / forced accidents etc.

The Vision behind

the BITS-Lifeguard System (1 of 2)
The overall life-saving environment in which the BITS-Lifeguard is envisioned to work shall
have two core components:
The wearable computing component: The BITS-Lifeguard
The vehicular computing component
The scenario of action would include:
Part-I:
sensing of select critical parameters that help estimate the current level of alertness and
physical ability to drive safely,
comparing these with the pre-fed threshold levels and generate an alert to the driver;
in case, driver fails to respond quickly enough, send and SoS signal to the vehicular computer
wirelessly

These responsibilities are handled by the wearable computer

The Vision behind

the BITS-Lifeguard System (2of 2)
The scenario of action would include:
Part-II
Taking over control from the driver,
Safely attempting to move the vehicle as per the pre-fed GIS map and GPS data
Stopping the vehicle on a side
Sending information wirelessly to the rescue / recovery agencies providing the location
details, vehicle’s details and driver’s details
Intimating to the pre-registered rela tive / friend about the event and location

These steps are taken by the vehicle’s computer

Elements of the BITS-Lifeguard Non-Intrusive Wearable Computing System

A wearable computing system of this category needs at least five basic elements:
Non-Intrusive Sensory elements to sense the wearer’s environment,
Computing elements to take care of computational needs; and,
Communication elements to interconnect these computing elements (with mobility)
Body safe Power Supply / Generation elements to provide the necessary power to the
wearable computing system
Fabric or placeholder elements to allow interconnected elements in place <could server other
purposes also>

Identifying Challenges
It was required to identify:
elements of relevance
Factors influencing the choices
Roles of Hardware technologies (including CPU, Power system, Sensor and Communication)
Roles of Software technologies (including System and Application software)
Challenge was also to consider Trade-offs between
functionalities,
form factor,
weight and
cost of device elements

Research Issues
Sensory Issues
Selection of parameters required to be sensed
Identifying the inter-relationship of these parameters with one-another, if any,
Comparison of these parameters’ usefulness to the target system from the viewpoint of their
measurability, ease of measurement, estimation or calibration
Identification of any conflicting requirements of any two or more of these parameters due
their measurement process that may interfere with each-other
Identification of best possible method of direct or indirect sensing the chosen parameters
Evaluating the best candidate methods from the viewpoints of their being appropriate to be
embedded into the wearable computer’s fabric
Identifying the best mechanism and location to embed one or more of these sensory elements
in the fabric
Identify the reliable interfacing mechanism to connect these elements with the appropriate
part of the target system

Processing Issues
Ascertaining the exact scope of real-time processing
Estimating average and peak processing power needed
Identifying the level and mechanism of fault-tolerance required
Evaluating the available processor families and short listing the candidate choices
Deciding about a safe and secure embedding mechanism, deciding the location of placement
of processors, integration of the chosen processors with the rest of the target system
Planning power needs of the processing sub-system

System Software Issues

Identifying the critical and optional features needed to be supported by the Operating System
Evaluating available Operating Systems on the chosen processors with respect to
real-time support in the scheduling mechanism,
power-management support,
efficiency of operation,
memory requirements,
availability of ready-to-use device drivers,
security support,
robustness (crash-resistance and recovery included),
availability of source code for modification and customization,
application development support available etc.

Application Software Issues

Identification of techniques and tools that would allow:
efficient,
verifiable,
self-correcting and
time-sensitive application level software design and development
Deciding about the critical and optional modules,
Formulating security (privacy included) strategies to be implemented at the application level

User-specific Issues
Choice of mechanism to be used for the User (Driver in this case) registration and
authentication prior-to-use
User-specific critical data acquisition, sensor output calibration and verification prior-to-first
use as well periodically afterwards (say every two years or after any major injury / prolonged
treatment etc.)
Deciding upon the minimal set of training (ideally none) on use of the wearable and
precautions, if any
Carefully evaluating the least irritating but adequately effective interface to the user for alerts
(say audio only, audio and vibratory alert etc.)
Communication Technology Issues
Identification of the low-power, short-distance, low / medium-speed wireless communication
mechanism (technology, protocol included) for the wearable computing element
Ensuring that the technology and mechanism work even if accidentally an object of common
use or any body part may come between the wearable computer’s transceiver and vehicle’s
transceiver
Identification of Higher-level Protocol Stack for local as well as global identification of the
wearable computer as well as that of the vehicle’s computer
Identification of appropriate wireless mobile communication technology that could allow
vehicle’s computer to communicate with the external world in the event of the need

Power-specific Issues
Identifying the methods and mechanisms to minimize the power requirements of the wearable
computer system since providing power from vehicle’s power system is both impractical and
unadvisable
Ensuring that the chosen mechanism of reduced power requirement does not adversely affect
the critical aspects of operation of the wearable computing system
Identifying possible power-system elements that could supply required power to the identified
elements of the wearable computer for reasonably long hours before any recharging or
replacement becomes necessary
Assessing the robustness of the power-sub-system against likely failures / exposures /
damages

Security Issues
Identification / development of low-overhead based efficient security mechanisms and
protocols for providing:
Data integrity check
Failsafe User (driver) authentication
Implementation of verifiable privacy policy to protect privacy of the user from the
unscrupulous offenders
Protection against any over-the-network or EMI-based attacks on the wearable or vehicular
subsystems

User-Safety Issues
Evolution of a verifiable framework that could be used to ensure that the overall system in its
entirety or any individual sub-system / element of which does not pose any threat to the
physical security or mental comfort level of the user
Ensuring that a built-in self-test be executed on the wearable computer as well as on the
vehicle’s computer at appropriate intervals to ensure that the system continues to conform to
the specified safety norms.

Current Status Vehicular Computing System

Vehicle’s communication subsystem design is ready, fine tuning and verification are yet to be
done
GPS software modules have been developed
A minimal GIS mechanism is being developed
Vehicle’s environment is planned to be simulated over next one year
Real prototype for the vehicle’s computing system is slated for 2008.

Wearable Computing System

Architecture for the Sensory Sub-system is ready and several sensory simulation tests are
under way
First phase of the Processing Subsystem Architecture has been completed, verification and
prototyping is being planned
Software decisions for the wearable computing element have been made, initial choices have
been frozen and a development environment is ready for use
Application software for the wearable computing system is slated for 2006
Security architecture is nearly complete and shall be evaluated within next 6 months

Some Bottlenecks
Retrofitting the older vehicles with the suggested computing system
Interfacing a large variety of microcontrollers / microprocessors used in many modern cars
with the suggested vehicular computing system
Creation of an exhaustive test environment at a reasonable cost at the university
Acquisition of some of the sensors identified for the purpose for the purpose of prototype
building
Ensuring human-safe design through simulation and prototyping

As of now, there are several technical research issues(particularly those related to sensors)
that need to be resolved and therefore any inputs are welcome.
 Appendix-1
Programming Aspects of Pervasive Computing

Mechanisms involved in Designing Solutions for the Pervasive Computing

Environments

Self-Configuration
Self configuration means that these network devices / services should be able to:
discover each-other / one -another,
negotiate what they need to do and
determine which devices ne ed to collaborate without any manual intervention.
Systems that can self-configure have the ability to handle both the early users and the
potential large-scale consumers without any retraining.

Discovery of Services
Discovery is a term used to describe the protocols and mechanisms by which a network
connected device or software service becomes aware of the network to which it is connected
and discovers which network services are available.
Service discovery can be all pre-configured (as in DHCP, DNS and LDAP)
For a relatively static system with infrequent addition of new devices or software services,
this may be a viable approach. For relatively static networks where central administration
is needed or desirable, this sort of pre-configured service discovery may be appropriate.
In real life, new information appliances are purchased and added to the network with some
frequency.
Mobile devices, such as cellular phones and PDAs, can enter and leave a home network
quite frequently.
Closed systems violate the axiom of versatility, as they are not amenable to easily adding
new functionality. In these situations, it is difficult to rely on manual configuration of the
network services without violating the axioms of simplicity, versatility and pleasurability.
Therefore, we need service discovery in the home, mobile, and similar environments to be
self-configuring.

Service Discovery Mechanisms

Salutation
Salutation is an architecture for looking up, discovering, and accessing services and
information. The Saluta tion architecture defines abstractions for devices, applications, and
services; a capabilities exchange protocol; a service request protocol; "personalities"
(standardized protocols for common services); and APIs for information access and session
management. Its heritage has been (and most implementations to date have focused on)
enabling access to office equipment (FAX, printers, scanners, and so on). However, the
architecture also supports other information appliances such as telephones and PDAs
through definitions for telephony, scheduling, and address book. Details on Salutation can
be found at www.salutation.org.
SLP
Service Location Protocol (SLP)3 is a standard developed by a working group of the
Internet Engineering Task Force (IETF). SLP addresses the problem of self-configuring
service discovery by applying existing Internet standards to the problem. SLP is designed to
be a lightweight, decentralized protocol with minimal administration requirements. Many
companies, including IBM, have implemented SLP in products.
Jini
Sun Microsystems developed its Jini technology to address service discovery needs for
networks of Java-enabled devices4. Jini addresses the axioms of simplicity and versatility
directly. Leveraging the Java platform, Jini uses very simple techniques to solve the hard
problem of distributed service discovery. Jini is described at www.sun.com/jini/.
HAVi
Home Audio/Video Interoperability (HAVi) is a consortium of consumer electronics
companies organized to define the interoperability standards among next generation
network-connected, digital home entertainment products. HAVi has its own proprietary
service discovery protocol. HAVi is described at www.havi.org.

Interoperability in terms of Service Discovery

None of these discovery protocols is likely to dominate. Some of these protocols (SLP,
Salutation) are deployed primarily within the enterprise or office environment, reducing
the likelihood of penetrating the home networking market.
Other technologies like Jini, UPnP etc. were conceived for a more informal, casually
connected environment, which could include networked vehicles and small offices as well
as home networks. Each has its strengths, and none has a dominant position in the
marketplace.
Consequently, good consumer networking solutions should be able to accommodate
heterogeneity, both in terms of underlying connectivity, and in terms of the discovery
infrastructure that is supported.

Common Features of Service Discovery Protocols (SDPs)

The discovery protocols discussed above share some common attributes, which could form
the basis for a high degree of interoperability. Let's examine a set of common
characteristics of self-configuring service discovery protocols:
1. Client agent: The client agent is a software component that runs in a device and searches
the network to find services needed by applications running in the device. Note that services
themselves can be clients of other services.
2. Service agent: For devices that provide services to other devices, the service agent is a
software component that advertises the services provided by the device. In the case where a
service provider implementation does not require hardware, a service agent can be based
entirely in software.
3. Registry: In order to provide efficiency and scala bility, some of these protocols provide
for a (perhaps optional) registry where information about available services is maintained.
Typically a registry contains an entry for each service advertised by a service provider. The
registry can be centralized or decentralized (distributed).
4. Registry update mechanism: This pertains to the protocols the service agents use to
update their entries in a registry.
5. Registry cleanup: This topic addresses how obsolete or incorrect information is purged
from the registry.
6. Discovery mechanism: The discovery mechanism is that part of a service discovery
protocol that specifies how a client locates the service discovery infrastructure such as a
registry.
7. Client lookup mechanism: The client lookup mechanism defines how a client queries the
registry (if there is one) to locate a service it needs, and how it locates the service in the
absence of a registry.
8. Client access to service: This topic addresses how a client, once it has located the service
that it needs, ne gotiates access to the service, including "quality of service" issues and
security issues.
9. Client use of services: Once a client has located a service, and has successfully negotiated
access to the service, it must determine (and perhaps acquire) the protocols to actually
interact with the service (for instance: IPP, LPR, HTTP, FTP, Java RMI).
HTTP: The Principal Web Protocol
HTTP: The Hyper Text Transfer Protocol
Works at Application Layer, provides stateless services
Uses TCP as its underlying transport
Default port: Port 80, Defined in RFC 2616
Has no implicit restrictions on types of documents and their formats for transfer
HTML and its variants remain popular for document transfer over HTTP

Methods in HTTP
CONNECT: reserved, used for ‘Proxy connection’
TRACE: used to ‘trace the request chain’ between client and server, a form of remote
loopback
OPTIONS: used to specify ‘communication options’ as available
HEAD: used to allow client to get only the ‘Header’ of a message rather than the ‘Body’ of
the message, helps in selective indexing and interpretation amongst other things
GET: used for ‘retrieval’ of stored data / document / resource associated with the requested
URI
PUT: used to request ‘storage’ of retrieved data enclosed within the request
POST: used to ‘post’ the data enclosed in the request for adding / annotating sub-ordinate
data associated with a URI
DELETE: used to ask the server to delete a document / resource associated with a URI
mentioned in the request

Classes of HTTP Responses

Return code: 1xy: request received, under processing
Return code: 2xy: request succeeded, action completed as asked
Return code: 3xy: redirected to a URI
Return code: 4xy: error due to client (like syntax incorrect, invalid request, page
unavailable etc.)
Return code: 5xy: error due to server (like valid request but service unavailable etc.)

HTTPS: The HTTP over Secure Connection

The plain HTTP over SSL or TLS provides a secure connection-oriented transport based
application environment and is thus known as HTTPSecure or simply HTTPS.
Current popular practice: HTTP over SSL (port 443) RFC 2246
Growing usage and Future trend: HTTP over TLS (port 443) RFC 2818
Continues: Plain HTTP (Port 80) No encryption, RFC 2616
Future: HTTP & HTTP over TLS or any other?

SSL: The Secure Socket Layer

Uses Public key cryptography and private key cryptography combination for encrypting and
transmitting information securely
Works atop the TCP
Uses port number: 443
Uses a shared session key using which information is encrypted and decrypted by the Client
and the Server
Uses Digital Certificates
Defined in RFC 2246

TLS: The Successor to SSL

TLS: Transport Layer Security protocol
Unlike its predecessor SSL, it is a multi-layer security protocol
Works atop TCP
Uses port number: 443
Offers data integrity, reliable transfer, encapsulation, privacy option, mutual
authentication (client authentication is optional)
Uses public-key and private-key cryptography combination for authentication and shared
key based encrypted transfers respectively
Uses Digital Certificates
Defined in RFC 2818

Enabling Web-based Applications for Pervasive Computing Devices

Goal: Efficient transformation of input formats to required output format for delivery and
use by pervasive computing devices OR dynamically generating data in required format
The respective mechanisms used to accomplish the task: ‘Transcoding’ and ‘Device-specific
Content Generation’
Example: HTML to WML transcoding
Best suited to structured documents written in mark-up languages like XML, XHTML etc.
Involves post-processing of Server-generated web-based content
Transcoding can happen at: Application Servers (full or selective), Application Proxies
(full) <former is a better choice in most cases>
In many cases, Transcoders come with their own sets of APIs.

Merits and Demerits of Transcoding in the Application Server versus Application Proxy
Transcoding at the Application Server has the advantage that it allows SSL/ TLS support,
selective transformation of content as per need and user-level transparency
Transcoding at the Application Proxy takes away all these advantages but allows ease of
deploying transcoding over just any Webserver, without necessarily being dependent on the
Application Server-specific implementation-dependent restrictions.

Transcoding versus Device -specific Content Generation

The latter (DSCG) suits freshly developed applications
DSCG is also preferable when minimal access is available to back-end system services
It provides better performance
It is more scalable than Transcoding
Allows optimization specific to devices
Costs more
Client Authentication over the Internetworks
There exist four possibilities:
No Authentication
Basic Authentication
Moderate Authentication
Advanced Authentication
Basic Authentication: It may be provided as an extension to the HTTP 1.1 (HHTP: RFC
2616, Extn.: RFC 2617)
Moderate Authentication: Digest Access Authentication using Challenge-Response
technique
Advanced Authentication: There are two choices, depending upon the requirements:
Kerberos -based Authentication (K-5: RFC 1510)
Public-Key Cryptography-based Authentication (SSL: RFC 2246, TLS: RFC 2818)

Basic Authentication …
Client may use it to authenticate itself to either the Origin Server or an intermediate Proxy
Server.
In this basic scheme, if an unauthorized access attempt is made by a client, server / proxy
sends it back an Error Code: 401 / 407: Unauthorized Access Error
However, server / proxy may ask / challenge the requesting client to supply / respond to one
or more pieces of information and if the client sends the correct piece (s) in its response the
access to restricted resource is granted.
In this scheme, user’s ID and his/her password are transmitted using base64-ended
plaintext.
This clearly is as insecure as the default Telnet authentication scheme.
Moderate and Advanced schemes of authorization attempt to tackle this issue by offering
cryptographic measures.

Moderate Authorization using Digest Access

In this case, a client requesting a restricted service receives a nonce-challenge from the
server and is expected to generate a message digest using this nonce containing the user Id,
password, numeric value of the received nonce, the requested HTTP method and the URI.
This digest is then transmitted over the insecure network to the server who upon receipt,
knowing the nonce and algorithm itself, verifies the response and if found to be correct
provides the requested access to service / resource.

Advanced Authentication using SSL / TLS

In this case, as discussed earlier, if a clie nt requests an access to a restricted service, the
server generates a random secret / challenge to the client.
Client is expected to respond by signing the sent challenge by using its Private Key and
transmit this signed response along with its digital certificate.
Upon receipt, the server verifies the authenticity of the certificate, extracts client’s public-
key from it and using this verifies the client’s signature.
If the process succeeds, the client is granted access to the requested service / resource.
Advanced Authentication using Smart Cards
In this case, if a client requests an access to a restricted service, the credit-card-sized
special access card known as Smart Card (designed using an anti-tamper mechanism) is
asked to be inserted in a specially designed reader unit which
receives and
transmits

data using a protocol-dependent APDU format involving cryptographic

mechanisms.
PC/SC and OCF are two major smart card interface mechanisms.
Smart Cards may be used in association with SSL / TLS (in case of HTTP) / WTLS (in case
of WAP) or by in conjunction with custom-designed application-level units.

A brief Recap on JINI

Jini is not a name server even though it supports its own lookup service
Jini should not be confused with Java Beans whose communication is based on direct
method invocation, whereas JIN use the (Java RMI based) remote method invocation.
Unlike JINI objects, Java Beans do not have the property of automatic awareness of other
beans.
JINI, due to the Java RMI’s security constraints, is not considered reasonably secure as of
this discussion.

UPnP Services
Description is stored as XML file
Control via SOAP messages: SOAP developed for web service
Most every language/platform has SOAP/XML libraries
Event notification with XML in General Event Notification Architecture
Presentation URL can be supplied by device
Description is stored as XML file
Control via SOAP messages: SOAP (Simple Object Access Protocol) developed for web
service
Most every language/platform has SOAP/XML libraries
Event notification with XML in General Event Notification Architecture
Presentation URL can be supplied by device
On the Web Services, SOAP, UDDI and WSDL

Web Service

A Web Service is simply a service available via the Web. Service can be implemented in any
language.

Problems with Web Services:

It is not practical to automatically find web services for your needs (UBR contains a lot of
junk)
There is no built-in mechanism for payment for use of a web service
There is no built-in security control
When a web service changes (e.g., adds a parameter to its method), the program using it
breaks

SOAP
SOAP stands for "Simple Object Access Protocol"
Used for "Remote Procedure Calls", similar to:
IIOP (for Corba), ORPC (for DCOM), RMI (for Java)
Difference: SOAP is text-based (actually XML), not binary. Firewall Friendly
Difference: Language independent, can call a program in any language
Difference: Uses standard port, since uses standard protocols
SOAP is simply a standard for sending messages (think of it as an envelope)
We can send two types of messages using SOAP:
RPC: Remote Procedure Call, a request to call a method
DOC: A document (this is used for more complex client - server communication)

Illustration
Consider the Java interface:

public interface Hello {

public String sayHelloTo(String name);

}
Suppose that a client wants to call the server's sayHelloTo method. Could send an XML
message:

<?xml version="1.0"?>
<Hello>
<sayHelloTo>
<name>John</name>
</sayHelloTo>
</Hello>
The Server could respond with:

<?xml version="1.0"?>
<Hello>
 <sayHelloToResponse>
<message>Hello John, How are you?</message>
</sayHelloToResponse>
</Hello>

Actual Soap Request

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header> </SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo xmlns:ns1="Hello"

SOAP-ENV:encodingStyle="

http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

Actual Soap Response

<SOAP-ENV:Envelope

xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse xmlns:ns1="Hello"
SOAP-ENV:encodingStyle="

http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">

Hello John, How are you doing?

</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

SOAP Header Section

The SOAP Header can contain information that describes the SOAP request.

<SOAP-ENV:Header>
<t:Transaction xmlns:t="some -URI"

SOAP-ENV:mustUnderstand="1">5
</t:Transaction>
</SOAP-ENV:Header>
5 is the transaction ID of which this method is a part
SOAP envelope's mustUnderstand attribute is set to 1, which means that the server must
either understand and honor the transaction request or must fail to process the message

SOAP Response on Error

There can be many errors in processing a SOAP request. Error in Running Method: Error
in Processing SOAP Headers: e.g., Problem running method as part of a transaction
Soap Error Response for Method Error

<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:Server</faultcode>
<faultstring>Server Error</faultstring>
<detail>
<e:myfaultdetails xmlns:e="Hello">
<message>
Sorry, I cannot say hello on Tuesday.
</message>
<errorcode>1001</errorcode>
</e:myfaultdetails>
</detail>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Soap Error Respo nse for Header Error

<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<SOAP-ENV:Fault>
<faultcode>SOAP-ENV:MustUnderstand</faultcode>
<faultstring>SOAP Must Understand
Error</faultstring>
</SOAP-ENV:Fault>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP Request via HTTP

POST http://www.Hello.com/HelloApplication HTTP/1.0

Content-Type: text/xml

Content-Length: 587

SOAPAction: urn:helloApp

<SOAP-ENV:Envelope …

SOAP Response via HTTP

HTTP/1.0 200 OK

Content-Type: text/xml

Content-Length: 615

<SOAP-ENV:Envelope …

Programming SOAP

The Main Component

There are 3 components that take part in a SOAP application:
Client Application: A program/Servlet/etc. that sends a SOAP request. Wants to use a
service.
SOAP Processor: A program that can receive SOAP requests and act accordingly (e.g., call
an method of the Application Server)
Application Server: A program that supplies the Web service
We won't directly read or write SOAP messages
Instead, use Java methods that create request and analyze result
Use a SOAP processor that is actually a Servlet (you will download it)
Code the Client Application and the Application server

Application Server
Your application server does not need anything special
In fact, your application server does not have to "know" that it is being used as a Web
Service!!
However, you will need to put the application server somewhere in the classpath of Tomcat
so that the SOAP Processor can find it and run it. More details on this soon...

Client Application
Your SOAP client will use special packages to generate a SOAP request
Need the following packages in your CLASSPATH to compile:
soap.jar
mail.jar
activation.jar

SOAP Processor
Your Tomcat web server needs a web application that is a SOAP Processor
Put soap.war in your <tomcat_home>/webapps directory
To actually run the SOAP Processor, it needs the soap.jar, mail.jar, activation.jar files in its
classpath
Easiest way to get the files in its classpath: Add them to the directory <tomcat_home>/lib

Creating the Application Server

package hello;

public class HelloServer {

public String sayHelloTo(String name) {

return "Hello " + name +

", How are you doing?";

}
}

Deploying the We b Service

The SOAP Processor must be told about your application. This is called "deploying"
Deploying is a two-step process:
Create a deployment descriptor
Call the java command that deploys the web application
Deployment Descriptor

<isd:service

xmlns isd http xml apache org xml soap deployment

id="urn:helloApp">

<isd:provider type="java"

scope="application"

methods="sayHelloTo">

<isd:java class="hello.HelloServer"/>

</isd:provider>

<isd faultListener>

org apache soap server DOMFaultListener

< isd faultListener>

</isd:service>

Deployment Descriptor

<isd:service

xmlns isd http xml apache org xml soap deployment

id="urn:helloApp">

<isd:provid er type="java"

scope="application"

methods="sayHelloTo">

<isd:java class="hello.HelloServer"/>

</isd:provider>

<isd faultListener>

org apache soap server DOMFaultListener

< isd faultListener>

</isd:service>
Deployment Descriptor

<isd:service

xmlns isd http xml apache org xml soap deployment

id="urn:helloApp">

<isd:provider type="java"

scope="application"

methods="sayHelloTo">

<isd:java class="hello.HelloServer"/>

</isd:provider>

<isd faultListener>

org apache soap server DOMFaultListener

< isd faultListener>

</isd:service>

Scope of Web Service

page: The service instance is available until a response is sent back or the request is
forwarded to another page
request: The service instance is available for the duration of the request, regardless of
forwarding
session: The service instance is available for the entire session
application: The same service instance is used to serve all invocations

More on the Deployment

Save the deployment descriptor in a file, e.g., HelloDescriptor.xml
Run the command:

java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter deploy HelloDescriptor.xml

where <host> and <port> are those of Tomcat

Note that Tomcat must be running for this to work
You can get a list of all deployed web services using the command

java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter list
You can undeploy a web service, so that it is no longer recognized by the SOAP Processor
using the command
java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter undeploy urn:helloApp
Note that the last argument is the URI of the web service to be removed

What must the client do?

Create the SOAP-RPC call
Set up any type mappings for custom parameters
Set the URI of the SOAP service to use
Specify the method to invoke
Specify the encoding to use
Add any parameters to the call
Connect to the SOAP service
Receive and interpret a response
Creating the Client Application

import java.net.URL;

import java.util.Vector;

import org.apache.soap.*;

import org.apache.soap.rpc.*;

public class Client {

public static void main(String[] args) throws Exception {

URL url = new URL("http://localhost:8080" +

"/soap/servlet/rpcrouter");
// Build the call.
Call call = new Call();
call.setTargetObjectURI("urn:helloApp");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);

Creating the Client Application

import java.net.URL;

import java.util.Vector;

import org.apache.soap.*;

import org.apache.soap.rpc.*;

public class Client {

public static void main(String[] args) throws Exception {

URL url = new URL("http://localhost:8080" +

"/soap/servlet/rpcrouter");
// Build the call.
Call call = new Call();
call.setTargetObjectURI("urn:helloApp");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);

Creating the Client Application

import java.net.URL;
import java.util.Vector;

import org.apache.soap.*;

import org.apache.soap.rpc.*;

public class Client {

public static void main(String[] args) throws Exception {

URL url = new URL("http://localhost:8080" +

"/soap/servlet/rpcrouter");
// Build the call.
Call call = new Call();
call.setTargetObjectURI("urn:helloApp");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);

Vector params = new Vector();

params.addElement(new Parameter("name", String.class,

args[0], null));

call.setParams(params);

// Invoke the call.

Response resp = null;
try {
resp = call.invoke(url, "");

} catch( SOAPException e ) {

System.err.println("Caught SOAPException (" +

e.getFaultCode() + "): " +

e.getMessage());
System.exit(-1);
}

Vector params = new Vector();

params.addElement(new Parameter("name", String.class,

args[0], null));

call.setParams(params);
 // Invoke the call.
Response resp = null;
try {
resp = call.invoke(url, "");

} catch( SOAPException e ) {

System.err.println("Caught SOAPException (" +

e.getFaultCode() + "): " +

e.getMessage());
System.exit(-1);
}

// Check the response.

if( !resp.generatedFault() ) {

Parameter ret = resp.getReturnValue();

Object value = ret.getValue();

System.out.println(value);

} else {

Fault fault = resp.getFault();

System.err.println("Generated fault: ");

System.out.println (" Fault Code = " +

fault.getFaultCode());

System.out.println (" Fault String = " +

fault.getFaultString());
}

Note on Parameters
It must be possible to "serialize" the parameters that the method invoked receives and
returns. Why?
The following have default serialization/deserialization:
primitive types: int, long, double, etc.
primitive Objects: Integer, Long, Double, String, etc.
complex Objects: Vector, Enumeration, Hashtable, arrays
easy to use JavaBeans

UDDI - Universal Description, Discovery and Integration Service

UDDI is a standard for describing and finding web services

UDDI Business Registry (UBR), Public Cloud

Nodes contain all UDDI information
Nodes are synchronized, so they retain the same data
You can query any node
You can add UDDI to a node, and it will be replicated to all others

Interacting with the UDDI

UDDI is itself a web service!!!
Interaction is via SOAP messages
The JAXR package defines a standard way to interact with registries (can work with other
types of registries too, e.g., ebXML)
Two types of interaction:
Inquiry: Does not need authentification
Publish: Needs authentification

WSDL - Web Services Description Language

Describing a Web Service

SOAP is just one standard to access a web service, there are many others (XML-RPC,
WDDX)
Need a standard way to describe a Web Service:
the methods available
their parameters

WSDL is a standard for describing web services using XML, i.e., a language for green
pages

With respective input from MIT Project Oxygen, MIT Project iCampus, HP CoolTown Project, VirginiaTech, UIUC, ETH-
Zuich, MSR, Project WearComp BITS, Project Grid-One BITS, UoW, CMU, IETF, ITU, Sun, W3C, KU, CU, LU, IEEE PC
etc..

Use of copyrighted material for pure academic reference herein is thankfully acknowledged. <Not meant for re-distribution!>
 Appendix-2
Major Research Initiatives around the World
MIT Project Oxygen
MIT Project Lizzy: M IT's We arable Co mpute r Des ig n
HP CoolTown
BITS-LifeGuard
Stanford Lifeguard
MSR EasyLiving
Appendix-3
Select Exercises and Their Indicative Solutions

Exercise-1:
Consider a situation wherein you have been asked to suggest a simple pervasive
computing infrastructure design that could should support the following features:
– Identification and location-tracking of all staff and students on campus
– Textual / Voice / Multimedia Messaging between people as per need
– Capability to use the high-end computing stations on campus for
compute -intensive jobs
– Basic security while allowing mobility

Your solution should address:

• Choice of the default networking protocols / schemes at lower
and higher layers
• Mechanism for location management / awareness
• Mechanism for route optimization for needs like simple textual
data transfer, voice transfers, short text messages, MMS, large
data packet transfers
• Choice of the minimum hardware configuration with respect to
processing features
• memory size & memory technology
• Secondary s torage capacity & technology
• Choice for power system & Management
• Choice of frequency bands for transmission & reception
• Choice of modulation / demodulation and / or coding / decoding,
if any
• User interface design features
• Choice of Operating systems
• Choice of Application Software

Hint: See the respective live session recordings if you missed the live session!

Exercise-2:
• What do you mean by the term Pervasive Computing System and why is it
called so? How do we, if at all, distinguish such a system from any other
computing system?
Pervasive Computing is a technology that pervades the user’s environment by
making use of multiple independent information devices (both fixed and mobile,
homogeneous or heterogeneous) interconnected seamlessly through wireless or
wired computer communication networks which are aimed to provide a class of
computing / sensory / communications services to a class of users, preferably
transparently and can provide personalized services while ensuring a fair degree of
privacy / non-intrusiveness.

Since the user’s environment is omnipresent or pervading always, the technology

which makes it possible could be termed as Pervasive computing.

Exercise-3:
• What is the relationship between a virtual pervasive residential block and
personalized end-user services?
 • Which ingredients go into building such blocks and how are?

Relationship between a virtual pervasive residential block and personalized end-user

services:
• The term pervasiveness includes capability of personalization
• Virtual Pervasive Residential Blocks need to have embedded PC elements,
some of the collectively provided services of which can be personalized
• Such services may include authentication and associated access control
services
• Custom alerts about interfaced items / devices / areas of the residential block
• Customized secure online pre -ordering for select items within the pre -
specified range of monetary consequences

Ingredients that go into building such blocks and how are:

• Sensors, microprocessors / microcontrollers , communication devices,
network interfaces, communication media, redundant power-provisioning
elements, authentication-support devices
• Corresponding firmware and software including device drivers, operating
systems, protocol stacks, application programs, communication networking /
service gateways, anti-intrusion and anti-theft support etc.
• Back-end services support in terms of appropriate hardware and software
• Mobile communication system’s presence with a live subscription to the
relevant services
• Hermetically sealed water and fire -resistant packaging for select critical
devices in case such a protection makes adequate sense in terms of the value
of protected items

Exercise-4:
• What is the reason that a designer of a pervasive computing system for a
passenger car may require integration of an OSGi Gateway into the
embedded information system designed for the car?

Several car manufacturers used a sizeable number of microprocessors /

microcontrollers for controlling different units known as Electronic control units
(ECU’s). These units need to communicate with each other on a bus (like CAN bus)
specially designed for car systems. At times it becomes necessary to communicate part of
this set of information not only within the car for the car’s and driver’s / passengers’ use
but also to communicate it selectively with one or more designated agencies in the
outside world. For this purpose one service gateway is needed.
The Open Services Gateway Initiative (OSGi) is an industry group that has defined an
open standard for such a Gateway known as OSGi Gateway that is meant for networked
consumer and business devices connected to the Internet.
o Support for an Open standard,
o Language neutral nature,
o OS neutral nature, automated controlled software download /
update,
o Application life cycle management,
o Gateway services security,
o Attached peripheral device access,
o Resource management &
o Remote administration
o Framework supporting bundles of services
o Compatibility with several transport systems including Bluetooth,
HomeRF etc.
Integrating the OSGi gateway into a CIS (Car Information System) allows transmission
/ reception of data wirelessly to the outside world where a back-end system maybe
known to exist. The OSGi , in such cases, acts as an interface between the CIS and the
outside world / back-end system. This is due to the fact that the OSGi gateway has an
ability to access information from the car’s ECUs and disseminate it, as required, to the
designated targets in the world outside the car. The car’s driver / owner / passenger /
manufacturer / maintenance-shop can benefit from such provisioning amongst others.
The user can access a range of free / paid services including email, voice calls etc. as per
need. Similarly, the car-manufacturer can make good use of the feedback by monitoring
critical parameters obtained from car sensors ‘periodically’ / ‘upon occurrence of any
specified event’. This ultimately helps him to improve quality / safety / marketability of
his cars subsequently as well as at times may allow to act proactively and help the driver
/ owner.

Exercise-5:
• What are the common features of Intel SpeedStep and Transmeta Crusoe
processors?

Both processors are able to have sizeable savings in power requirements by making
optimisation in architecture (although entirely differently).
 Case-Studies

Person Tracking
System of MSR
EasyLiving

Triclops
Color Stereo
Cameras

Stereo Processing
and Person Detection

© Microsoft Research, Redmond

<Extracted for educational case Person
study purpose only> Tracking

EasyLiving Person Tracking

number of
people in view 1 2 3 n

number of
cameras 1 2 3 n

identity
none maintain recognize

occlusion
0% 50% 100%

postures
stand stand & sit stand, sit, lay

show
one canned video live always naïve
image sequenc tape demos on user
e real time
© Microsoft Research, Redmond
<Extracted for educational case study purpose only>
World Model

What is described?
o Computing devices
n What they are, where they are, their status, the
proxy agent, the service area
o People:
n Who they are, where they are, their preferences,
what they are doing
o Services
o Rooms and doorways
o Inert things in the world
The world model has many parts
© Microsoft Research, Redmond
<Extracted for educational case study purpose only>

EasyLiving ?

Source: Steve Shafer et al.

Ubiquitous Computing group
http://research.microsoft.com/easyliving
© Microsoft Research, Redmond
<Extracted for educational case study purpose only>
 Some sna psho ts from la boratorie s …

16-Bit M16C
Microprosessor from
Renesa

A development board
based around the Intel
SA1110 microprocessor

700MHz PC104 board

<Courtesy: U niversity of Birmingham >

<Courtesy: CSD, BITS-Pilani>

A Car with an Embedded OS-based Set-up

A System-Board for Wearable Jacket

 Bibliography
Recommended Reading in Pervasive Computing

General reading:
1. C. Kozyrakis, D. Patterson: ?A New Direction in Computer Architecture
Research,? in IEEE Computer, vol. 31, no. 11, November 1998 (pp. 24-32).
2. Guruduth Banavar, James Beck, Eugene Gluzberg, Jonathan Munson,
Jeremy Sussman, Deborra Zukowski. Challenges: an application model for
pervasive computing Proc. 6th ACM MOBICOM , Boston, Mass., August 2000.
3. Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kristofer
Pister, System architecture directions for network sensors , ASPLOS 2000.
4. M. Weiser. Some computer science issues in ubiquitous computing.
Communications of the ACM, 36(7):75-85, July 1993.

5. Michael Bedford Taylor, Jason Kim, Jason Miller, David Wentzlaff, Fae
Ghodrat, Ben Greenwald, Henry Hoffman, Jae -Wook Lee, Paul Johnson, Walter
Lee, Albert Ma, Arvind Saraf, Mark Seneski, Nathan Shnidman, Volker
Strumpen, Matt Frank, Saman Amarasinghe and Anant Agarwal, The Raw
Microprocessor: A Computational Fabric for Software Circuits and General
Purpose Programs, IEEE Micro, Mar/Apr 2002..
6. Stuart Cheshire and Mary Baker, "Internet mobility 4x4." Proceedings of the
ACM Conference on Applications, Technologies, Architectures, and Protocols for
Computer Communications (SIGCOMM '96), August 1996, Stanford, California.
Pages 318-329.
7. Victor C. Zandy and Barton P. Miller, "Reliable Network Connections."
Proceedings of the eighth ACM/IEEE Inte rnational Conference on Mobile
Computing and Networking (MobiCom '02), September 2002, Atlanta, Georgia.
Pages 95-106.

Pervasive Computing Environments

8. David Garlan, Dan Siewiorek, Asim Smailagic, and Peter Steenkiste, ?Project
Aura: Towards Distraction-Free Pervasive Computing?, IEEE Pervasive
Computing, special issue on "Integrated Pervasive Computing Environments",
Volume 1, Number 2, April-June 2002, pages 22-31.
9. Robert Grimm, Janet Davis, Eric Lemar, and Brian Bershad, Migration for
pervasive applications.
10. Umar Saif, Chris Terman, Steve Ward, A Case for Goal-oriented
Programming Semantics.

Energy-Aware Computing

11. Real-Time Dynamic Voltage Scaling for Low-Power Embedded Operating

Systems, Padmanabhan Pillai and Kang G. Shin, in Proc. of SOSP 2001.

12. Cooperative I/O: A Novel I/O Semantics for Energy-Aware Applications ,

Andreas Weissel, Bjórn Beutel, and Frank Bellosa, University of Erlangen, OSDI
2002

13. ECOSystem: Managing Energy as a First Class Operating System Resource,

Heng Zeng, Carla S. Ellis, Alvin R. Lebeck, Amin Vahdat, ASPLOS-X, 2002.
14. Energy Aware Lossless Data Compression, Kenneth Barr and Krste
Asanovic, Massachusetts Institute of Technology, MobiSys 2003.

15. Energy-Adaptive Display System Designs for Future Mobile Environments,

Subu Iyer, Hewlett Packard Labs; Lu Luo, Carnegie Mellon University; Robert
Mayo and Parthasarathy Ranganathan, Hewlett Packard Labs, MobiSys 2003.

16. Energy-aware adaptation for mobile applications, Jason Flinn, M.

Satyanarayanan, SOSP 1999.

17. Investigating Upper Bounds on Network Lifetime Extension for Cell-Based

Energy Conservation Techniques in Stationary Ad Hoc Networks , Douglas
Blough, Georgia Institute of Technology, USA, Paolo Santi, Istituto di Informatica
e-Telematica, Italy, MobiCom 2002.

18. Kravets, R., and Krishnan, P. Application-driven power management for

mobile communication. ACM Wireless Networks 6, 4 (2000), 263{277.

19. Minimum-Energy Broadcast in All-Wireless Networks: NP-Completeness

and Distribution Issues, Mario Cagalj, Jean-Pierre Hubaux, Swiss Federal
Institute of Technology, Christian Enz, Swiss Center for Electronics and
Microtechnology, Switzerland, MobiCom 2002.
20. Operating System Modifications for Task-Based Speed and Voltage
Scheduling, Jacob R. Lorch, Microsoft Research; Alan Jay Smith, University of
California, Berkeley, MobiSys 2003.

21. Power management for energy-aware communication systems, ACM

Transactions on Embedded Computing Systems, August 2003.

22. PowerScope: A Tool for Profiling the Energy Usage of Mobile Applications,
Jason Flinn, M. Satyanarayanan, IEEE WMSCA, 1999.

23. Ronny Krashinsky, Hari Balakrishnan, Minimizing Energy for Wireless Web
Access with Bounded Slowdown, MobiCom 2002.

24. Self-Tuning Wireless Network Power Management, Manish Anand, Edmund

B. Nightingale, and Jason Flinn, MobiCom 2003.

25. Wake on Wireless: An Event Driven Energy Saving Strategy for Battery
Operated Devices, Eugene Shih, Massachusetts Institute of Technology, USA,
Paramvir Bahl, Michael Sinclair, Microsoft Research, USA, MobicCom 2002..

Other readings:

Pervasive Computing Handbook (ISBN: 3-540-67122-6) by Uwe Hansmann, et al, Springer-

Verlag, Berlin, 2001.

Internet and Wireless Security, (ISBN 0-85-296197-9) by R. Temple and J. Regnault, The
IEE Press, United Kingdom, 2002.

P roject BITS-Wear Comp: A perspective from the BITS Wearable Comput ing S ystems
Group , An off ic ial pos it io n paper of BITS, P ilan i (In d ia). URL: h ttp :// d iscovery.bits-
pilan i.ac.in/rahu l/BITS-WearComp-P osit io n-P aper.pdf

Smailag ic, Asim and Martin, R ichard. Metronaut: A Wearable Computer with Sensing and
Globa l Co mmu n icatio n Capabilit ies. URL:
http ://www2.cs.cmu.edu/afs/cs/project/vuman/www/pub lications/metronaut.p df.

Maria Sunseri, Craig B. L iden , Jon ny Farring don , Ray P ellet ier, Scott Safier, Joh n St ivor ic,
Astro Teller, and S uresh Vishnu bhat la. The SenseWearTM Armband as a Sleep Detection
Device. URL:

http ://www.bodymed ia.com/pdf/ SenseWearAsSleepDetectionDev ice.pdf.

Rahul Banerjee. June 2001. THE BITS LifeGuard System, F irst technical meeting of the
European Commission’s Next Generation Network Init iat ive pro ject, Brussels.

2002 Mot or Vehicle Crash Data from FARS and GES. January 2004. Traffic Safety Facts
2002 : A Comp ilat io n of Motor Vehic le Crash Data from the Fatalit y Analys is

Reportin g System and the General Estimates System. Annual Report. Washingt on , D.C.:
Nationa l Hig hway Traffic Safety Admin istration.

European Transport Safety Council. 20 01. The Role of Driver Fatigue in Commercial Road
Transport Crashes. Technical Report , ISBN: 90-7 602 4-09- X. European Transport Safety
Council, Rue du Cornet 34, B-10 40 , Brussels.

NCSDR / NHTSA Expert Panel on Driver Fatig ue and Sleep iness. 1998. Drowsy Driv in g and
Automob ile Crashes. URL: http ://www.nhlb i.n ih.gov /health/ prof/s leep/drsy_ drv.pdf

The Royal Society for the P revention of Accidents (RoSP A). February 2001. Driver Fatigue
and Road Accidents: A Literature Review and P osition P aper. URL:
http ://www.rospa.com/pdfs/road/fatigue.pdf

Lizzy : MIT's Wearable Computer Design 2.0.5. URL:

http ://www.media.mit.edu/wearables/lizzy/ lizzy/.

Steve Mann, 1997 Smart Cloth ing : The Wearable Computer and WearCam, URL:
http ://wearcam.org/personaltechnolog ies/

Rhodes, B. J. 1997. The Wearable Remembrance Agent: A system for augmented memory.
P ersonal Technolog ies Journal, Specia l Issue on Wearable Comput ing 1 : 2 18-2 24.

Abowd, G., Atkeson , C., Hong, J., Lon g, S. , Kooper, R., and P inkerton , M. 1997.
Cybergu ide : A mob ile context-aware tour guide. ACM Wireless Networks 3:
4 21 -4 33 .