Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Device Technology & Pervasive Compu7ng: Rahul Banerjee

Download as pdf or txt
Download as pdf or txt
You are on page 1of 41

Device

Technology & Pervasive Compu7ng


Lecture-6, First Semester: 2011-2012 August 16, 2011
Topics covered: Fundamental requirements for constituent devices, types of devices, required features, desirable features, preferred features, design aspects, integration aspects, power & communication aspects, emerging trends

Rahul Banerjee, PhD (CSE)


Professor, Department of Computer Science

Birla Ins=tute of Technology & Science


Pilani 333 031, INDIA
Home Page: hJp://discovery.bits-pilani.ac.in/~rahul/ Email: rahul@bits-pilani.ac.in / Rahul.Banerjee.CSE@Gmail.com
Tuesday 16 August 11 (c) Dr. Rahul Banerjee, BITS-Pilani, INDIA

INTERACTION POINTS
Fundamental requirements for cons7tuent devices, Types of devices, Required features, Desirable features, Design aspects,
Compu7ng aspects, Power-provisioning aspects, Network communica7on aspects, Safety and Security aspects,

Deployment aspects <including Integra7on aspects>, Emerging trends, References


16/08/11 (c) Dr. Rahul Banerjee, BITS-Pilani, INDIA 2

Fundamental Requirements
Compute/Sense Device requirements:
Devices should have some local compu7ng capability Devices should be network-enabled / possible to be enhanced to be made network-enabled with liRle eort Devices have to be safe for use Devices should be congurable and controllable either alone or in group(s) Devices should be able to discover / to be discovered without user-level congura7on (plug-and-play)
Tuesday 16 August 11 (c) Dr. Rahul Banerjee, BITS-Pilani, INDIA 3

Desirable Requirements
Devices should be able to auto-discover one-another based on the level of pre-congured security creden7als and desired level of authoriza7on with the non-repudia7on feature thrown in in case of sensi7ve services Devices should have some automa7c re-rou7ng capability Devices should have automa7c load-balancing / load-distribu7on capability Devices should have secure remote-recongurability Devices should have an acceptable Mean Time Between Failure (MTBF) specica7on Devices should be self-healing either alone or in combina7on, par7cularly for cri7cal or sensi7ve service environments
Tuesday 16 August 11 (c) Dr. Rahul Banerjee, BITS-Pilani, INDIA 4

Types of Devices
Network-Addressable Devices:
Compute devices
Processing devices Memory devices

Sensory devices with limited compu7ng capability (Compute / Sense devices)

I/O Devices
Display devices (touch/non-touch) Poin7ng devices Keying devices Audio-input/output devices Secondary storage devices

Associated devices / peripherals including power-provisioning devices


Tuesday 16 August 11 (c) Dr. Rahul Banerjee, BITS-Pilani, INDIA 5

Design Aspects
Iden7ca7on of the Required / Desired Device Characteris7cs Iden7ca7on of the Available Candidate Devices / Device Technologies Iden7fying explicit and implicit constraints Iden7fying known issues from previous research / deployments / use, if any, where applicable Freezing candidate device specica7ons Choosing the candidate device / device technology for the frozen specica7on Evalua7ng the suitability of the chosen candidate device in the overall set-up from the viewpoints of compa7bility, interoperability, congurability etc. as per need
Tuesday 16 August 11 (c) Dr. Rahul Banerjee, BITS-Pilani, INDIA 6

Deployment Aspects
Iden7fying the targeted deployment environment and expected scenarios Iden7fying actual constraints that would / might inuence / dictate / aect actual physical deployment of devices chosen Evalua7ng the design in the light of new informa7on such obtained, if any <and going through the selec7ve redesign process if so needed> Iden7fying the desired ini7al deployment setup and the nal full- blown version and compu7ng the associated expenses including those of expansion / extension and maintenance<not applicable to all cases>

Tuesday 16 August 11

(c) Dr. Rahul Banerjee, BITS-Pilani, INDIA

Source: Using Context Prediction for Elderly Health Monitoring in Pervasive Computing Environments *1Ma Shou-ming, 1Wang Ru-chuan, 2Ye Ning *1School of Computer Science and Technology, Nanjing University of Posts and Telecommunications, Nanjing, Jiangsu, 210003, P.R. China, njalfonso1977@hotmail.com 2Department of Information Science, Nanjing College for Population Programme Management, Nanjing, Jiangsu, 210042, P.R. China doi:10.4156/jdcta.vol5. issue1.3

Tuesday 16 August 11 8

An Example Scenario

Case-Study-1

Intelligent Transporta7on Systems Devices & Scenarios

Tuesday 16 August 11

(c) Dr. Rahul Banerjee, BITS-Pilani, INDIA

A Visualiza7on of the Intelligent Transporta7on system

Another ITS Scenario

Sample Technologies in ITS

Japanese ITS: The SmartWay

Elsewhere in Asia: ITS

Vehicular Sensors

Vehicular Sensors

Driver State Monitors

Delphi DSM SIM Insight DSM FaceLab DSM

Gaze Detec7on: 1

Gaze Detec7on: 2

Case-Study-2

Wearable Compu7ng Devices & Scenarios

Tuesday 16 August 11

(c) Dr. Rahul Banerjee, BITS-Pilani, INDIA

22

Wearable Compu7ng
at MIT & ETH

ETH Zurichs ANT

MITs MIThril

Some Glimpses into WCs

Concluding Remarks
Technology convergence is aiding Pervasive Compu7ng device-design, fabrica7on and deployment All pervasive compu7ng solu7ons are inherently distributed in nature and all addressable devices have to t in such an environment Increasingly, a heterogeneous mix of needs and desirable features is being allowed to be designed to custom specica7ons though with varying degree of user level customiza7on

Tuesday 16 August 11

(c) Dr. Rahul Banerjee, BITS-Pilani, INDIA

25

Any ques7ons?

Thank you!

Home Page: http://discovery.bits-pilani.ac.in/~rahul/ Email: rahul@bits-pilani.ac.in / Rahul.Banerjee.CSE@Gmail.com

Tuesday 16 August 11

(c) Dr. Rahul Banerjee, BITS-Pilani, INDIA

26

Self-Configuration & its Importance


In order too achieve the pervasive computing system design goals (simplicity, versatility and pleasurability) the appliances and the networks comprising of these appliance nodes must be able to:
automatically discover other
Devices, Services and Parameters

In addition, they should be able to carry out unattended negotiation amongst themselves if needed.

Systems that can self-configure help bridge the gap among early users and the normal consumers.

Discovery Protocols & Mechanisms


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. Mobile devices 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.

Important Service Discovery Protocols Salutation

devices, applications, 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.

Salutation is an architecture for looking up, discovering, and accessing services and information. The Salutation architecture defines abstractions for

Important Service Discovery Protocols


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. Jini Sun Microsystems developed its Jini technology to address service discovery needs for networks of Java-enabled devices. 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

Important Service Discovery Protocols

Home Audio/Video Interoperability (HAVi) is a consortium of consumer electronics companies organized to define
the interoperability standards among next generation networkconnected & digital home entertainment products.

HAVi has its own proprietary service discovery protocol. HAVi is described at www.havi.org.

Bluetooth
Bluetooth is a a short-range wireless communication protocol. As part of this effort, the Bluetooth Software Special Interest Group is defining several layers of a software stack - one of these layers is Service Discovery.

Service Discovery Interoperability


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 and Bluetooth 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 SDP


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 selfconfiguring service discovery protocols:

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. 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. 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). Registry update mechanism: This pertains to the protocols the service agents use to update their entries in a registry.

Common Features of S D P
Registry cleanup: This topic addresses how obsolete or incorrect information is purged from the registry. 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. 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. 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. 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).

Any questions?

Let s move to the next point of discussion!

The pervasive computing system needs at least two basic elements to be pervading everywhere they are required to pervade:
Computing elements to take care of computational needs; and, 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.
(c) Rahul Banerjee, BITS, Pilani, India 36

Recap:
Several generations Gradual enhancements Coexistence & transition

3G UMTS / CDMA 2K /IMT 2K

GSM/EGPRS/EDGE GSM / GPRS 2G GSM


(c) Rahul Banerjee, BITS, Pilani, India 37

First Generation Global Mobile Radio standard : 1G Only voice, No data Second Generation Global Mobile Radio standard : 2G GSM: 9.6 Kbps <circuit switched voice / data> Enhanced Second Generation Global Mobile Radio standard : 2.5G
GSM-GPRS <combination of circuit and packet switched voice / data> GPRS-136: <100Kbps <packet switched>, EDGE > 100kbps, Others: > 1Mbps <often less than 5 Mbps>

Third Generation Global Mobile Radio standard: 3G UMTS / CDMA2000, 5-40 Mbps <simultaneous packet switched voice / data> Fourth Generation Global Mobile Radio standard : 4G (LTE etc.) 20 - 40 Mbps & beyond <packet switched voice / data>
(c) Rahul Banerjee, BITS, Pilani, India 38

GPRS users can share the resource (Radio link) which is used only when users are actually sending or receiving data. GPRS is based on a modulation technique known as Gaussian minimum-shift keying (GMSK). 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.

(c) Rahul Banerjee, BITS, Pilani, India

39

What is 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 multitechnology solution.
(c) Rahul Banerjee, BITS, Pilani, India 40

Any questions?

You might also like