validation of context based service iscovery protocol...

International Journal of UbiComp (IJU), Vol.3, No.4, October 2012

DOI:10.5121/iju.2012.3402 19

VALIDATION OF CONTEXT BASED SERVICEDISCOVERY PROTOCOL FOR UBIQUITOUS

APPLICATIONSAnandi Giridharan and Pallapa Venkataram

Protocol Engineering Technology Unit Electrical Communication EngineeringIndian Institute of Science, India.

{pallapa,anandi}@ece.iisc.ernet.in

ABSTRACT

Service Discovery Protocol (SDP) is important in ubiquitous applications, where a large number of devicesand software components collaborate unobtrusively and provide numerous services without userintervention. Existing service discovery schemes use a service matching process in order to offer services ofinterest to the users. Potentially, the context information of the users and surrounding environment can beused to improve the quality of service matching. We propose a C-IOB (Context- Information, Observationand Belief) based service discovery model, which deals with the above challenges by processing the contextinformation and by formulating the beliefs based on the basis of observations. With these formulated beliefsthe required services will be provided to the users. In this work, we present an approach for automatedvalidation of C-IOB based service discovery model in a typical ubiquitous museum environment, where theexternal behavior of the system can be predicted and compared to a model of expected behavior from theoriginal requirements. Formal specification using SDL (Specification and Description Language) basedsystem has been used to conduct verification and validation of the system. The purpose of this framework isto provide a formal basis for their performance evaluation and behavioral study of the SDP.

KEYWORDS

Ubiquitous Computing; SDL (Specification and Description Language); Ubiquitous application; Servicediscovery; context aware.

1. INTRODUCTION

In ubiquitous applications, users are surrounded by a variety of computing devices offeringservices of different types. As users need to discover and interoperate with such services, servicediscovery represents a crucial functionality. Ubiquitous computing applications areheterogeneous both in terms of networking infrastructures and interaction protocols. Ubiquitousapplications, where not only PCs but also various other devices are connected to networks [1],are expected to offer context-aware services that match user situations and tastes. Because users'needs change dynamically according to the user context such as position or time, an idea tocompose appropriate service elements in the network dynamically based on the user context is apromising approach [2][3], as an alternative approach to the conventional way of providingservices, where service providers prepare services perfectly in advance. Context informationincludes device capabilities such as display resolution, processor speed and available memory,network bandwidth and user context such as user location, user preferences, age, and gender,goal, interest etc. Using these context information at hand, a context-aware system can providemobile users with appropriate services according to the device/user context[4]. Failures of thesystem is detected by a separate Observer Unit, which observes the inputs and generated outputsand reports its failures in real-time[5]. It determines whether a failure has occurred by comparing


20

the observed and the specified behavior. Such automated detection of software failures offers anumber of benefits. Early notification of occurrence of software failures allows the operators ofsoftware controlled systems to take corrective actions before the cumulative effects of failuresresult in major disruption of system operation. In this work, we propose a framework for theformal specification using SDL based system and conduct verification and validation of C-IOBmodel based service discovery model in a Ubiquitous museum environment. The purpose of thisframework is to provide a formal basis for their performance evaluation and behavioral study.The rest of the paper is organized as follows. Section 2 discusses Context based ServiceDiscovery Protocol. Section 3 illustrates the proposed C-IOB based Service Discovery model inUbiquitous Museum environment. Section 4 describes role of context coping with failures andvalidating the errors. Section 5 draws the conclusion.

2. CONTEXT BASED SERVICE DISCOVERY PROTOCOL

When the geographical location of the users device and the geographical location of the servicesare known in the network, it is possible provides to the user the nearest service. In this situationnew applications may appear which could offer the best nearest service that the user needs. Thecontext information is the rules that service discovery uses to select the best service for the user.The location of the users device and the location of services could be the context information ofthe service discovery. Service discovery provides a mechanism which allows automatic detectionof services offered by any node in ubiquitous environment. In other words, service discovery isthe action of timely finding a service provider for a requested service. When the location of thedemanded service is retrieved, the user may further access and use it. Each service discoveryprotocol consists of at least two basic participating elements: Server is an entity that offers theservice and client uses the service provided[6]. The development of various ubiquitous computingservice technologies with a new technological system which enables "the computing environmentany time, any place and for anything" in which human centered interface application technologiesare added on top of conventional web service technology is progressing.

2.1. Context -Information, Observation and Belief (C-IOB model)

Figure 1. C-IOB Model

C-IOB model is characterized by three components: information , observations and beliefmodule. The real world information can be modeled as a hierarchy of increasing abstract andusing intuitive theory to model cause-effect relationship between context information, observationand also predicting the beliefs from these observations, which can be formalized as causalnetworks. For instance, a learner's belief about causal network structures in context aware domainis characterized by three class variables:context information, observations and beliefs, and thereexists causal relations between theses variables[7]. Figure 1. illustrates the C-IOB model.


21

Context Information: The context information is gathered from physical environment, systemenvironment, application environment and social environment of the visitor. The example ofcontext information is: current location of the visitor, time of the day, room temperature at thatparticular instant, noise level of the room at particular instant. The behaviors are derived based onthe context data or the data from previous history. For example, some of the commonly observedbehaviors of user on some transaction: change in location and time , the surrounding noise andtemperature, change of device (PDA, LAPTOP, etc.,) and its characteristics (based on batterypower, processing power, memory capacity), network connectivity (bandwidth, latency., etc),device operating system, application data (email, file transfer). Similarly the data from physicalactions like creating, reading, writing, modifying or closing a document. The historical data fromthe average purchase frequency of the currency, vendor reliability based on past history.

Observation Formulation

The observation is a learning process that can improve the prediction capability of contextinformation and it consists of receiving knowledge of the outside world (various environments)through the senses. An observation in the design of context aware system is obtained from thebehaviors exhibited by the context environment. An observation is a summarization of the variousobserved context information parameters of a user in a particular ubiquitous environment. Theobservation formulation block formulates the observations depending on the context informationof the user. For example, the following observations like visitor is on the move, visitor is goingtowards new exhibit, visitor device is not working, device network interface is not supported canbe formulated for visitor in a museum environment.

Belief Formulator

Primarily, beliefs represent information about the world or an entity, the perceptions receivedfrom the external world, and execution of events update the beliefs. The observations made onvarious behaviors of the visitors will be deduced into beliefs[8]. Some examples of beliefs used inthe proposed scheme are: spending more time near exhibit, spending less time and in a hurry,visitor is looking disturbed etc.

3. PROPOSED C-IOB MODEL SERVICE DISCOVERY PROTOCOL

Context Information: The context information is gathered from physical environment, systemenvironment, application environment and social environment of the visitor. The example ofcontext information is: current location of the visitor, time of the day, room temperature at thatparticular instant, noise level of the room at particular instant, etc. Figure 2. shows C-IOB ModelService Discovery protocol in ubiquitous application.

The context information can be divided into four categories:

• · Physical Environment context: which includes the context information parameters likelocation, time, temperature, noise level, pressure, position, orientation, etc. ,[9].

• · System context: such as device being used, operating system present in the device,supported network interfaces, output modes of the device, screen characteristics of thedevice, etc.

•


22

Figure 2. shows C-IOB Model of a Service Discovery Protocol used in a ubiquitous application.

• Application context: It includes the type of application, different data types inapplication, status of the application, resources required by the application, etc.

• Social Context: whose parameters include social behavior of user, preferences of theuser, social identity, social trust on the user, etc.

Context information: can be represented as given below: C(nk) = (c11 , c12 , ..., c1k ), n=1 to 4.where C(1k) represents the set of context information of physical environment context, C(2k)

represents the set of context information of system context, C(3k) represents the set of contextinformation of application context and C(4k) represents the set of context information of socialcontext.

Observation Formulation: An observation is a summarization of the various observed contextinformation parameters of a user in a particular ubiquitous environment. The observationformulation block formulates the observations depending on the context information of the user.For example, the following observations like visitor is on the move, visitor is going towards newexhibit, visitor device is not working, device network interface is not supported can be formulatedfor visitor in a museum environment[10].

Belief Formulator: Primarily, "beliefs represent information about the world or an entity, theperceptions received from the external world, and execution of events update the beliefs". Theobservations made on various behaviors of the visitors will be deduced into beliefs. There existspre-established relationships between observations and beliefs, these relationships are of types"one- to-one, one-to-many and many-to-many". Some examples of beliefs used in the proposedscheme are: spending more time near exhibit, spending less time and in a hurry, visitor is lookingdisturbed. The belief formulator is a component of C-IOB which collects various temporal andsymptomatic context information parameters from the environment. At particular time of thecontext information, corresponding observations are generated. The beliefs are deduced based onthe new and available observations over a context. The belief formula which is used to representindividual belief is given by: B= (b1 , b2 , ..., bn ). Where bi is a ith beliefs in the set of beliefs, B,as literals and variables used to represent various observations on which the belief will bereasoned. The given belief representation is compatible with the working of belief formulator.


23

Figure 3: Causal graph of the model

Service Identification: Service identification is one of the challenging steps in the ServiceOriented Development life cycle. Identification of the service mainly depends on the system'slookup status which is offering the service, components of such systems, identifying the suitablecomponent in the system which provides the required service, type of interface mechanismprovided in the service providing entity, types of inputs and outputs of the servicing entity. Alsothe orientation, etc.[11]. Identification of service depends on the present context at which theservice has been requested. This identified service must be efficient in all possible ways whencompared to other servicing entities in the look-up state.

Fetching the required service: Once the service required has been identified, it had to be fetchedfrom the service providing entity. The service fetched will be based on the context, availability ofthe service in look-up table and current status of the service providing entity. The fetching ofservice also depends on the type of network interfaces used by both service requester and serviceprovider which directly affects the QoS of the service provided. Figure 3. gives the causal graphof the model representing contextual information of environment and corresponding observation.Table 1 gives the sequence of exhibit information service discovery using the C-IOB module.


24

Table 1: Sequence of exhibit information service discovery using the C-IOB module.

3.1 . Flow Diagram of Context aware Service Discovery Protocol

Context aware Service Discovery Protocol has two important entities:

1. Service Management Node (SMN): interacts with other SMN and maintains a repositoryof context data within a cluster of nodes.

2. Service Assistant Node (SAN): takes over the role as an SMN and it may also act asproxy between SMN and IP devices. SMN is again split into two parts. One part is thelower layers is called Service Management Module responsible of interacting with theexternal clients devices and services devices, by using legacy Service Discoveryprotocols such as UPnP. The other one is the Service Discovery Adaptation Layer , whichis the interface between these protocols and the upper components. The upper layers


25

contain the main modules, which make it possible to filter the best service as in figure 4.and flow chart representing operation of Service Discovery Protocol is shown in figure 5.

Figure 4: Service Discovery Components

Figure 4: Flow chart representing operation of Service Discovery

3.2. Service composition framework of C-IOB model in U-museum environment:

Interaction between various components of context aware Service Discovery Protocol is shown infigure 6. The context is a kind of information that makes it possible to the Service Discovery filterall the connected services and choose the best. The first time visitors to museum must getregistered with the ubiquitous guide for museum guide system. If the visitor is a well known bytheir profession or a celebrity, the system search their web-site and collects the visitor's profile,interest, preferences and available time for visiting the museum exhibits. Otherwise the systeminitiates the registration process to collect visitor's information online. This information is moreuseful when providing services to the visitor based on his/her interest, preference and time spendin the museum, etc. To accommodate user requests, the portal employs a composition frameworkto coordinate atomic, disparate services. There are different services available in museum seeFigure 6. Interaction between various components of context aware Service Discovery Protocol.

· DirectionsFinder: Providing exhibit information, path to next exhibit.· IdentifyingService: Identifying the nearest catering and reservation service· MedicalService: Finding Medical service nearby, ambulance service etc.

· EmergencyService: Emergency fire exit path and calling a fire extinguisher service, ambulanceservice etc.This Identification of service is done by taking the current beliefs formulated byconsidering the present context of the visitor. Table below gives the belief driven serviceidentification. After identification of the visitor required service, the system will also provide the


26

path or URL address to the service ,where it is available. The different services available inubiquitous museum are stored in different servers which are fetched via the path or URL

addresses.

Figure 6: Interaction between various components of context aware Service Discovery Protocol

Figure 7: Context aware application finder

Case 1: Catering service location: Assume that visitor is in a museum, and time is mid-day andthe belief formulated will suggests that "visitor needs the catering service", so system has toprovide the catering service. To provide the catering service to the visitor, system must know thevisitor preferred dishes, which is determined from the visitor profile. Once his/her preferreddishes are determined, then C-IOB system starts searching for the nearby restaurants , wherethese dishes are available. Once the search is complete, the system decides the best restaurantwhere visitor preferred dishes are available according to the visitor preference and also systemreserves a table in the restaurant for the visitor to have lunch. After completing these procedures,the system informs the visitor about the restaurant where dishes of his/her choice will be availablewithin the budget and provides the path to that particular restaurant.

Case 2: Fire emergency exit: If there is a fire in a museum or in any such public places, usuallypeople are more distracted and no cool mind thinking due to the situation. In such a scenarioguidance must be given to the visitors to the emergency exit so that they can come out withoutany problem. The occurrence of fire emergency can be determined by different contextinformation such as room temperature, humidity, noise level in a room. The correspondingobservations for this context informations will be sudden increase in room temperature, increasein humidity level and noise level which leads to the belief that there is some fire disaster. Oncethis belief has been formulated the system can decide that the visitor needs emergency fire exit


27

service and it provides the path to emergency exit as well as it informs the fire extinguisherservice to control the fire. Figure 7. shows the context aware application finder in case of mobileand stationary tourist.

4 Role of Context coping with failures:

Figure 8: Failure of Nodes, links & message loss in a U-Museum environment

Context has a major role in the approach. A framework needs to acquire context from differentcontext sources in a disciplined way. A mechanism is also needed to describe what action to takewhen the tourist enters a certain context. Another important challenge in providing a contextaware service composition facility is dealing with various failures. For instance, failures mayoccur at composition time, as a result of context fails or changes with missing servicedescriptions. Failures may also arise at run-time, for example, because of the loss of networkconnectivity, node failure, link failure, etc. The design of the framework must ensure its ability tooperate under increasing load, increasing complexity of requests and increasing size of resultingcomposite services. Figure 8. shows failure situations in Ubiquitous museum environment. Incase of major power failure after the discovery phase has completed, services and notificationrequests are registered,most entities lose some internal state: all nodes lose discovered SCMs;SUs lose SDs for service previously discovered. A number of different failures may occur duringthe composition of service process:

· Node failures,· link failures, network level disconnections, Sensor failure, service discoveryfailures, service execution failures.

System attempts to locate a different provider for the context type for which there is noavailability of context information. If no providers are available for the context type in questionthe system acquires historical contextual data from the Context Service. It may also construct acomposition request based on a previously executed task.

Discovery failures: Service discovery failures may occur for the following reasons:

· Inaccessible Service Registry, Network disconnection, System overload,unavailability ofrequested service in the registry, unavailability of suitable service instance, Mismatching ofservice operation. To avoid the Service Registry being a single point of failure, the system hasbeen designed to operate with multiple service registries. This can be achieved both by deployinga number of replicas of the same registry, as well as by mediating among a number of differentregistries. Unexpected environment changes: Environment changes may be due to: Different


28

composite service from that designed & Recomposition Fails. Finally, if the recompositionprocess fails as well, control is passed back to the composition request management layer, inwhich a composition request is modified or a new one assembled.

Service unavailability: Services may become unavailable for the following reasons: · NetworkDisconnection Failure can be handled by service instance, composite service.

These are some of the techniques used to overcome failures:

· Number of cached copies are backed up to avoid the delays inherent in rediscovering asuitable service instance.

· New service is fetched from the Service Registry.· The system may also opt to run redundant instances of composite services.

4.1. Consistency Maintenance in the C-IOB model during node, link failure.

In the proposed framework goal conditions are represented in Specification Description Language(SDL). This allows for easy import of goals into the software component that stores them. Eachgoal condition is a specification. Belief conditions: that form the composition request may resultfrom the task intention of the user or from the Context of the user. Goal: Any goal condition thatpurely describes a users task intention, independent of the current context, is a core goal.Examples are (directionfound) goal conditions.

Minimal goal: The minimal goal condition that needs to be satisfied to achieve a viable solutionfor a given composition request is termed a minimal goal. Context goal tags are introduced forrepresenting context goals, which are goal conditions that arise in a specific context. Each tag hasthree parts, a context type, context value and goal condition.

Figure 9. Validation for correctness

Following are the description of construction of a composition request:

User selects a desired task, Corresponding core goal conditions are fetched from the GoalService, The Context Proxy fetches the current context data from the Context Service, ·Construction of tags. The Context Service may fail to provide access to context data, for example,


29

because of a failure of respective context provider as a result of sensor unavailability or networkdisconnection. If a desired context value cannot be retrieved from the Context Service, duringconstruction of tags, the Context Proxy attempts to obtain a past context value from the ContextService. The Context Service tracks past contexts in which the user has submitted compositionrequests. The software component that implements the Context Service has the facility to cachethe historical values. context value of this type. Secondly, it supplies the most frequentlyoccurring context value of this type. This historical context data can also be used to generateprobabilistic predictions about current and future contexts. Context value orderings facilitate thesubstitution of related context values. By substituting context values new context goals arecreated. This is useful for transformation of unreachable context goals into ones that can besolved. Figure 9. shows validating error and correctness in the U-museum environment.Specification and Description Language was used to specify the functionality of each componentand communication between them to facilitate fault-tolerant, context aware servicecomposition[12].

Context Entity: Each composition request is a formal definition of the users task intention. TheContext entity has been modeled to receive context signal creq from Ubiquitous museumenvironment (based on user's location, device, user's movements, gestures, behavior etc.) RawContext data received from U-museum environment undergoes acquisition cacq and processing forappropriate data format cpro .

Observation Entity: Context data signal cdata is later sent to Observation Entity as show in figure10. Entity performs context analysis and reasoning Canaly and Observation formulation is carriedout Obsformu to formulate Beliefs. This Belief data Bdata is sent to Belief Entity.

Belief Entity: This Belief entity is the abstract service composition management module, that hasabstract plans that executes specified service instance. Receiving Belief Data, Belief entityautomatically identifies the the service SId with help of Service Discovery scheme without user'sintervention and fetches Fser the required service from appropriate service provider entity andpresents it to the Visitor as shown in figure 11.

Figure 12 shows the Message sequence charts that represents the transaction between variouscomponents generating belief under normal working conditions. By introducing activities, we canimprove the system's response by returning different URL's according to the current usersituation. Three handlers like Location of the user, Navigation type and route and Activity to becarried out by user is configured as shown in Figure 13.

5. Simulation and Results

For Consistency analysis of C-IOB model , simulation scenarios were done to check the behaviorof C-IOB model in Ubiquitous Museum environment. A experiment room with many statues andphotos dispersed at fixed locations. As the visitors visited the room, simulation were conductedconsidering various failures like node, link etc. and latency time of communication was noted ateach instant.

All the Performance metrics were measured like total number of hits, when the tourist viewedcertain statue in the room and number of misses, when the the information was not availableimmediately to the visitor due to node, link failures were also noted. Graphs for number of hitsand number of misses are as shown in Figure 10. Figure 11 gives number of hits, when touristwere successful in viewing information without any delay.


30

Figure 10. Plot of number of visitors to museum vs number of missesFigure 11. Plot of number of visitors to museum vs number of hits

Success ratio and delay were also observed. C-IOB model provides more relevant services forvisitors with reduced latency as seen in the figure 12.

Figure 12. Plot of number of visitors to museum vs Latency


31

4.2 Validating Errors using Specification and Description language:

Specification of System context , system process (protocol behaviors) and procedures usingSpecification and description language is shown in figure 13 and 14.

Message sequence chart , a graphical specification language that graphically displays interactionbehavior of the C-IOB system as shown in figure 15.

Figure 13. System context

Figure 14. System Process (behavior of protocol)

Figure 15. Message sequence chart showing normal operation of system

System tracks the context features as they change due to certain communication failures. C-IOBmodel keeps track of history of the visitors (e.g. the visited nodes) existing features (e.g. theweather conditions tagged as good or bad), navigation map etc. Thus, C-IOB model supports


32

these scenarios that allows combining these features accordingly as situation changes as shown infigure 16. In case of node failure or link failure or if web server is down, Adaptation

Figure 16. Triggering handlers like location, navigation and activity based on visitor's situationenvironment has a set of handlers that are in-charge of reacting to these context changes and

generates its specific context- aware behavior accordingly based on the user's navigationalFigure 17. Context situations based on various failures like node, link etc.

Figure 18. Verification and validation of system for better functionality.

behavior and history as shown in figure 17. Verification and validation of errors is shown basedon history of user in figure 18. Once an executable application is generated from a model, SDLbrings up a Simulator user interface, which can be customized for the particular application. Thesignals received from U-museum environment are run until there are no more transitions toexecute, or run until a certain value of the modeled system time. Tracing execution is recorded


33

using a detailed Message sequence chart of all process state transitions and signals exchangedbetween processes and between processes and the environment. The Validator can be used both toexplore the system in an unguided mode looking for errors, and to perform a guided explorationin order to check whether a given system-level MSC is satisfiable.

5. Conclusion

Observer observes the inputs and outputs of the target software system and automatically detectsits failures. To determine whether the observed behavior is correct, the Observer internallyexecutes (interprets) a Reference model derived from the specification of external behavior of thetarget system. In our, C-IOB model in case of node failure or link failure or if web server is down,Adaptation environment has a set of handlers that are in-charge of reacting to these contextchanges and generates its specific context- aware behavior accordingly based on the user'snavigational behavior and history. C-IOB model provides more relevant services for visitors withreduced latency. The paper considered the case, when the specification is expressed in aformalism based on communicating extended finite state machines, specifically the ITU-T SDL.

REFERENCES

[1] M. Weiser, Ubiquitous Computing, Communications Of ACM 36(1), 75-84 (1993).[2] S. Gribble, et al., The Ninja Architecture for Robust Internet-Scale Systems and Services, Special

Issue of Computer Networks on Pervasive Computing, 2000.[3] M. Takemoto, et al., A Service-Composition and Service-Emergence Frame-work for Ubiquitous-

Computing Environments, SAINT2004, pp. 313-318, Jan. 2004.[4] Sejong Gu, Hongzhou Shi, Jian Ye, Zhenmin Zhu, "A Service Discovery Framework for Ubiquitous

Computing", 8th Intl. IEEE 2007[5] Tianyin Xu, Baoliu Ye, "A Gnutella Inspired Ubiquitous Service Discovery Framework for

Pervasive Computing Environment", Tokyo 163-0914, JAPAN, 2008 IEEE.[6] "Service Advertisement and Discovery in Mobile Ad hoc Networks", Bethlehem, PA 18015[7] E. Guttman, C. Perkins, J. Veizades, and M. Day. "Service Location Protocol", Version 2, Request for

Comments (RFC) 2608, June 1999.[8] B.Miller and R.Pascoe, "Salutation Service Discovery in Pervasive Computing Environments",

Technical Report, IBM White Paper, February2000.[9] Paramesh C. Upadhyay, and Sudarshan Tiwari, 1Sant Longowal , "Fault Tolerant Distributed and

Fixed Hierarchical Mobile IP", Institute of Engineering and Technology, India and Motilal NehruNational Institute of Technology, India, IJU 2010,Volume 1.

[10] Anis Ismail, Abd El salam Al Hajjar, ziad ismail, Liban and Telcom paristech, "A New systemarchitecture for pervasive computing", Liban and Telcom paristech, France, IJU 2011 volume 2.

[11] Marzieh ilka, Mahdi Niamanesh and Ahmad Farrah, Paam Noor univerity, "A Group-based Methodfor Context-Aware Service Discovery in Pervasive Computing Environment", Tehran, Iran, IJU2012.

[12] Alireza Souri, Fault Tolerant Location-Based Service Discovery Protocol (LBSDP): A NewApproach in Vehicular Networks, American Journal of Scientific Research, ISSN 1450-223X Issue57 (2012), pp. 84-89. © EuroJournals Publishing, Inc. 2012

.


34

Authors

Venkataram Pallapa received his Ph.D. Degree in Information Sciences from the University of Sheffield,England, in 1986. He is currently the chairman for center for continuing education, and also a Professor inthe Department of Electrical Communication Engineering, Indian Institute of Science, Bangalore, India.Dr. Pallapa's research interests are in the areas of Wireless Ubiquitous Networks, CommunicationProtocols, Computation Intelligence applications in Communication Networks and Multimedia Systems.Dr. Pallapa is the holder of a Distinguished Visitor Diploma from the Orrego University, Trujillo, PERU.He has published over 150 papers in International/national Journals/conferences. Written three books:\textbf{Mobile and wireless application security} Tata McGraw-Hill, \textbf{Communication ProtocolEngineering}, Prentice-Hall of India (PHI), New Delhi, 2004 (Co-author: Sunil Manvi), and\textbf{Multimedia: Concepts \& Communication}, Darling Kinderley(India) Pvt. Ltd., licensees ofPearson Education in South Asia, 2006. Written chapters for two different books, and a guest editor to theIISc Journal for a special issue on Multimedia Wireless Networks. He has received best paper awards atGLOBECOM'93 and INM'95 and also CDIL (Communication Devices India Ltd) for a paper published inIETE Journal. He is a Fellow of IEE (England), Fellow of IETE(India) and a Senior member of IEEEComputer Society.------------------------------------------------------

Anandi Giridharan, received MSc(Engg) from Indian Institute of Science. She iscurrently working as Senior Scientific Officer in ECE Department, Indian Institute ofScience, Bangalore. Her Research Interest are in area of Ubiquitous learning,Communication Protocols and Multimedia systems.

validation of context based service iscovery protocol...

Documents