pervasive computing systems-rahul-oct-2005-summar-notes · 2012. 3. 25. · bits-pilani . contents...

Pervasive Computing Systems

Rahul Banerjee Computer Science & Information Systems Group

Summary Notes

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 , 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 :

• 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 o Enhanced Second Generation Global Mobile Radio standard :

2.5G § GSM-GPRS § GPRS-136:

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

• 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

§ 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 • 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 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

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 need 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 scalability, 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, negotiates 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) 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 client 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:

John The Server could respond with:

Hello John, How are you?

Actual Soap Request

John

Actual Soap Response

Hello John, How are you doing?

SOAP Header Section

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

5 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:Server Server Error Sorry, I cannot say hello on Tuesday. 1001

Soap Error Response for Header Error

SOAP-ENV:MustUnderstand SOAP Must Understand Error

SOAP Request via HTTP

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

Content-Type: text/xml

Content-Length: 587

SOAPAction: urn:helloApp

activation.jar

SOAP Processor Your Tomcat web server needs a web application that is a SOAP Processor Put soap.war in your /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 /lib

Creating the Application Server

package hello;

public class HelloServer {

public String sayHelloTo(String name) {

return "Hello " + name +

", How are you doing?"; } }

Deploying the Web 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

org apache soap server DOMFaultListener

< isd faultListener>







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://:/soap/servlet/rpcrouter deploy HelloDescriptor.xml

where and 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://:/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://:/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);



















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.

Appendix-2 Major Research Initiatives around the World

MIT Project Oxygen MIT Project LLiizzzzyy:: MMIITT''ss WWee aarraabbllee CCoommppuuttee rr DDeess iiggnn 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

TriclopsColor Stereo

Cameras

Stereo Processingand Person Detection

PersonTracking

© Microsoft Research, Redmond

EasyLiving Person Tracking

none maintain recognize identity

0% 50% 100% occlusion

stand stand & sit stand, sit, lay postures

one image

video tape

always on

show canned

sequence

live demos

naïve user

real time

number of people in view

number of cameras

1 2 3 n

1 2 3 n


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


EasyLiving

Source: Steve Shafer et al. Ubiquitous Computing group http://research.microsoft.com/easyliving

??


SSoommee ssnnaappsshhoottss ffrroomm llaabboorraattoorriieess ……

A development board based around the Intel SA1110 microprocessor

16-Bit M16C Microprosessor from

Renesa

700MHz PC104 board

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.

PPrroojjeecctt BBIITTSS--WWeeaarr CCoommpp:: AA ppeerrssppeeccttiivvee ffrroomm tthhee BBIITTSS WWeeaarraabbllee CCoommppuutt iinngg SSyysstteemmss GGrroouupp,, AAnn ooffff iicc iiaall ppooss iitt iioonn ppaappeerr ooff BBIITTSS,, PP iillaannii ((IInnddiiaa)).. UURRLL:: hhttttpp:://// ddiissccoovveerryy..bbiittss--ppiillaannii..aacc..iinn//rraahhuull//BBIITTSS--WWeeaarrCCoommpp--PPoossiitt iioonn--PPaappeerr..ppddff

SSmmaaiillaaggiicc,, AAssiimm aanndd MMaarrttiinn,, RR iicchhaarrdd.. MMeettrroonnaauutt:: AA WWeeaarraabbllee CCoommppuutteerr wwiitthh SSeennssiinngg aanndd GGlloobbaa ll CCoommmmuunniiccaattiioonn CCaappaabbiilliitt iieess.. UURRLL:: hhttttpp::////wwwwww22..ccss..ccmmuu..eedduu//aaffss//ccss//pprroojjeecctt//vvuummaann//wwwwww//ppuubblliiccaattiioonnss//mmeettrroonnaauutt..ppddff..

MMaarriiaa SSuunnsseerrii,, CCrraaiigg BB.. LL iiddeenn,, JJoonnnnyy FFaarrrriinnggddoonn,, RRaayy PPeelllleett iieerr,, SSccootttt SSaaffiieerr,, JJoohhnn SStt iivvoorr iicc,, AAssttrroo TTeelllleerr,, aanndd SSuurreesshh VViisshhnnuubbhhaatt llaa.. TThhee SSeennsseeWWeeaarrTTMM AArrmmbbaanndd aass aa SSlleeeepp DDeetteeccttiioonn DDeevviiccee.. UURRLL::

hhttttpp::////wwwwww..bbooddyymmeeddiiaa..ccoomm//ppddff//SSeennsseeWWeeaarrAAssSSlleeeeppDDeetteeccttiioonnDDeevviiccee..ppddff..

RRaahhuull BBaanneerrjjeeee.. JJuunnee 22000011.. TTHHEE BBIITTSS LLiiffeeGGuuaarrdd SSyysstteemm,, FFiirrsstt tteecchhnniiccaall mmeeeettiinngg ooff tthhee EEuurrooppeeaann CCoommmmiissssiioonn’’ss NNeexxtt GGeenneerraattiioonn NNeettwwoorrkk IInniitt iiaatt iivvee pprroojjeecctt,, BBrruusssseellss..

22000022 MMoottoorr VVeehhiiccllee CCrraasshh DDaattaa ffrroomm FFAARRSS aanndd GGEESS.. JJaannuuaarryy 22000044.. TTrraaffffiicc SSaaffeettyy FFaaccttss 22000022:: AA CCoommppiillaatt iioonn ooff MMoottoorr VVeehhiicc llee CCrraasshh DDaattaa ffrroomm tthhee FFaattaalliitt yy AAnnaallyyss iiss

RReeppoorrttiinngg SSyysstteemm aanndd tthhee GGeenneerraall EEssttiimmaatteess SSyysstteemm.. AAnnnnuuaall RReeppoorrtt.. WWaasshhiinnggttoonn,, DD..CC..:: NNaattiioonnaa ll HHiigghhwwaayy TTrraaffffiicc SSaaffeettyy AAddmmiinniissttrraattiioonn..

EEuurrooppeeaann TTrraannssppoorrtt SSaaffeettyy CCoouunncciill.. 22000011.. TThhee RRoollee ooff DDrriivveerr FFaattiigguuee iinn CCoommmmeerrcciiaall RRooaadd TTrraannssppoorrtt CCrraasshheess.. TTeecchhnniiccaall RReeppoorrtt ,, IISSBBNN:: 9900--7766002244--0099-- XX.. EEuurrooppeeaann TTrraannssppoorrtt SSaaffeettyy CCoouunncciill,, RRuuee dduu CCoorrnneett 3344,, BB--11004400,, BBrruusssseellss..

NNCCSSDDRR // NNHHTTSSAA EExxppeerrtt PPaanneell oonn DDrriivveerr FFaattiigguuee aanndd SSlleeeeppiinneessss.. 11999988.. DDrroowwssyy DDrriivviinngg aanndd AAuuttoommoobbiillee CCrraasshheess.. UURRLL:: hhttttpp::////wwwwww..nnhhllbbii..nniihh..ggoovv//hheeaalltthh//pprrooff//ss lleeeepp//ddrrssyy__ddrrvv..ppddff

TThhee RRooyyaall SSoocciieettyy ffoorr tthhee PPrreevveennttiioonn ooff AAcccciiddeennttss ((RRooSSPPAA)).. FFeebbrruuaarryy 22000011.. DDrriivveerr FFaattiigguuee aanndd RRooaadd AAcccciiddeennttss:: AA LLiitteerraattuurree RReevviieeww aanndd PPoossiittiioonn PPaappeerr.. UURRLL:: hhttttpp::////wwwwww..rroossppaa..ccoomm//ppddffss//rrooaadd//ffaattiigguuee..ppddff

LLiizzzzyy:: MMIITT''ss WWeeaarraabbllee CCoommppuutteerr DDeessiiggnn 22..00..55.. UURRLL:: hhttttpp::////wwwwww..mmeeddiiaa..mmiitt..eedduu//wweeaarraabblleess//lliizzzzyy// lliizzzzyy//..

SStteevvee MMaannnn,, 11999977 SSmmaarrtt CCllootthhiinngg:: TThhee WWeeaarraabbllee CCoommppuutteerr aanndd WWeeaarrCCaamm,, UURRLL:: hhttttpp::////wweeaarrccaamm..oorrgg//ppeerrssoonnaalltteecchhnnoollooggiieess//

RRhhooddeess,, BB.. JJ.. 11999977.. TThhee WWeeaarraabbllee RReemmeemmbbrraannccee AAggeenntt:: AA ssyysstteemm ffoorr aauuggmmeenntteedd mmeemmoorryy.. PPeerrssoonnaall TTeecchhnnoollooggiieess JJoouurrnnaall,, SSppeecciiaa ll IIssssuuee oonn WWeeaarraabbllee CCoommppuutt iinngg 11:: 221188--222244..

AAbboowwdd,, GG..,, AAttkkeessoonn,, CC..,, HHoonngg,, JJ.. ,, LLoonngg,, SS.. ,, KKooooppeerr,, RR..,, aanndd PPiinnkkeerrttoonn,, MM.. 11999977.. CCyybbeerrgguuiiddee :: AA mmoobbiillee ccoonntteexxtt--aawwaarree ttoouurr gguuiiddee.. AACCMM WWiirreelleessss NNeettwwoorrkkss 33:: 442211--443333..

pervasive computing systems-rahul-oct-2005-summar-notes · 2012. 3. 25. · bits-pilani . contents...

Documents