Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
Bibliography
Index
1
Introduction
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
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.
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:
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>
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
• 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
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
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
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.
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
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.
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
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.
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
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.
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.
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.
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:
}
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>
<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>
<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">
</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
<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-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-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
Content-Type: text/xml
Content-Length: 587
SOAPAction: urn:helloApp
<SOAP-ENV:Envelope …
HTTP/1.0 200 OK
Content-Type: text/xml
Content-Length: 615
<SOAP-ENV:Envelope …
Programming SOAP
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
package hello;
<isd:service
id="urn:helloApp">
<isd:provider type="java"
scope="application"
methods="sayHelloTo">
<isd:java class="hello.HelloServer"/>
</isd:provider>
<isd faultListener>
</isd:service>
Deployment Descriptor
<isd:service
id="urn:helloApp">
<isd:provid er type="java"
scope="application"
methods="sayHelloTo">
<isd:java class="hello.HelloServer"/>
</isd:provider>
<isd faultListener>
</isd:service>
Deployment Descriptor
<isd:service
id="urn:helloApp">
<isd:provider type="java"
scope="application"
methods="sayHelloTo">
<isd:java class="hello.HelloServer"/>
</isd:provider>
<isd faultListener>
</isd:service>
java org.apache.soap.server.ServiceManagerClient
http://<host>:<port>/soap/servlet/rpcrouter deploy HelloDescriptor.xml
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
import java.net.URL;
import java.util.Vector;
import org.apache.soap.*;
import org.apache.soap.rpc.*;
"/soap/servlet/rpcrouter");
// Build the call.
Call call = new Call();
call.setTargetObjectURI("urn:helloApp");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
import java.net.URL;
import java.util.Vector;
import org.apache.soap.*;
import org.apache.soap.rpc.*;
"/soap/servlet/rpcrouter");
// Build the call.
Call call = new Call();
call.setTargetObjectURI("urn:helloApp");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
import java.net.URL;
import java.util.Vector;
import org.apache.soap.*;
import org.apache.soap.rpc.*;
"/soap/servlet/rpcrouter");
// Build the call.
Call call = new Call();
call.setTargetObjectURI("urn:helloApp");
call.setMethodName("sayHelloTo");
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
args[0], null));
call.setParams(params);
} catch( SOAPException e ) {
e.getMessage());
System.exit(-1);
}
args[0], null));
call.setParams(params);
// Invoke the call.
Response resp = null;
try {
resp = call.invoke(url, "");
} catch( SOAPException e ) {
e.getMessage());
System.exit(-1);
}
System.out.println(value);
} else {
fault.getFaultCode());
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
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
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.
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?
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?
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
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 ?
16-Bit M16C
Microprosessor from
Renesa
A development board
based around the Intel
SA1110 microprocessor
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.
Energy-Aware Computing
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.
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:
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:
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
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 .