Context Management System for Pervasive WMN

Shivanajay Marwaha Jadwiga Indulska The University of Queensland and National ICT Australia (NICTA), Brisbane, Australia

{smarwaha, jaga}@itee.uq.edu.au

Abstract—Conventional layered protocols are not capable to handle the vagaries of Wireless Mesh Networks (WMN) such as rapidly changing wireless channel quality, battery power and network topology. Most WMN cross-layer proposals to overcome these problems utilize only a limited set of parameters from the concerned layers rendering them incapable of network and system wide optimizations as they do not consider global network context. Additionally, their application is limited by the use-case and deployment scenarios as well as technologies considered and can also lead to destructive interaction due to the lack of a global view and also the lack of communication between the numerous cross-layer adaptations. To make WMNs truly pervasive, there is an urgent need to make the WMN protocol stack context-aware, so that it can adapt dynamically to the deployment scenarios and operating conditions. Early designs for global network context management for WMN do not reflect WMN limitations such as scarce network capacity and CPU and RAM constraints of mobile devices. Most also do not consider higher-level context and situation reasoning models and lack a simplified way of representing, managing and gathering context information. Some of the current proposals utilize generic context gathering concepts from Distributed Systems that could lead to excessively high communication overhead in WMN. This paper presents the requirements for developing a Middleware for managing WMN protocol and network context, evaluates the state of the art and proposes a concrete, extensible, lightweight and comprehensive context management system for WMN named MESH-CMS which can overcome the aforementioned problems.

Keywords-wireless mesh networks; cross-layer; context-aware.

I. INTRODUCTION AND MOTIVATION Wireless Mesh Networks (WMNs) [1] offer many

advantages such as rapid deployment and self-configuration and have numerous applications [2] for example in disaster relief and emergency response, intelligent transportation systems and building automation etc. Figure 1 shows an example of a WMN.

WMN protocols that perform well in one scenario or deployment may not work well or as desired in another. Furthermore, WMNs face many challenges such as unreliable communication medium, dynamic mesh topology, device and application heterogeneity etc. Conventional strict layered protocol stack architecture for WMN, which is based on the OSI model of ISO, suffers from many problems [3], such as: (a) it is not

capable to handle the vagaries of WMN such as the changes in network topology, wireless link quality, battery power and traffic load to name a few [4], (b) it may also lead to slower adaptations, as upper layer protocols are not immediately and directly informed about the lower layer adaptations and reconfigurations [3]. Therefore, it takes the upper layers a long time to detect and adapt to the new network conditions, layer by layer and this may not meet the strict performance requirements of WMNs [3]. By the time the complete protocol stack adapts to a change in network context, the network condition may have changed manyfold [3].

Figure 1: Example of a Wireless Mesh Network

Figure 2: Example of a Cross-Layer Protocol Stack

To alleviate these problems, many cross-layer optimisation mechanisms have been proposed for WMN in the recent years. For example, routing protocols for WMN often consider link quality, battery life etc [5] [6]. Cross-layered protocol stack approaches allow interactions between two or more layers in the protocol stack as shown in fig. 2 by sharing information among the layers and breaking their encapsulation and separation [4] [7]. In spite of the advantages offered by cross-layer designs, there are some limits, beyond which cross-layer designs become ineffective, such as: (i) Cross-Layer mechanisms merely consider a Local

View [4] of the information, which may not achieve system wide cross-layer performance improvement and network objectives.

(ii) Cross-Layer protocol designs are not generic and do not look at the problem of protocol adaptation in its totality. They are generally limited to a few use-case scenarios and network technologies [3].

Seventh IEEE PerCom Workshop on Pervasive Wireless Networking

978-1-61284-937-9/11/$26.00 ©2011 IEEE 606

(iii) Cross-Layer mechanisms may not encompass all the protocol stack layers [3].

(iv) There is a possibility of unintentional negative interaction [3] [8] in two or more simultaneously operating cross-layer mechanisms as they may not communicate with each other and take into account the system in its entirety.

(v) Cross-layer only provides local optimisations and not global optimisations [3]. Furthermore, WMN protocol stack needs to be

aware of a variety of WMN dynamics that require protocol and network adaptation in order to continue performing well, such as: (i) Network Conditions: Continuously varying

network conditions, such as link quality, interference, traffic loads, network mobility, battery power, network size etc.

(ii) Deployments: Wide variety of deployments such as emergency and rescue operations, satellite networks, battlefields, metropolitan mesh networks. Different deployments have different network requirements.

(iii) Node characteristics: WMN nodes have varying capabilities in terms of battery power, number of antennas, CPU and RAM resources etc.

(iv) Node requirements: Different WMN nodes may have different requirements based on their role in the network.

(v) Application requirements: Different communication applications that run on WMN may require different protocol functionalities.

As one protocol stack or one cross-layer mechanism can neither meet nor foresee [9] all of the aforementioned network conditions as well as application and deployment scenarios, there is therefore an urgent need to develop an integrated, multi-layer, extendible local and global network context sensing, managing, distribution and subsequent protocol stack adaptation framework that can work efficiently in different WMN situations and deployments [5] [9] [10].

This paper is organised as follows. Section 2 presents the background on network context information, protocol stack adaptation using context-awareness as well as advantages of context-aware protocol stack design over cross-layer mechanisms. Section 3 presents the requirements for Context Management System (CMS) for WMN Protocol Stack. Section 4 presents the previous work in the area of WMN Context Management. Section 5 presents the proposed framework for the Context Management System for WMN and section 6 concludes the paper with a brief conclusion.

II. BACKGROUND

A. Network Context Information As per [11], “Context is any information that can be

used to characterize the situation of an entity”. WMN context information consists of various facts and parameters that define a particular state of the Wireless Mesh Network [12]. Examples of WMN context information include sensed context such as remaining battery power, link quality, interference, network size, node mobility, network traffic load, as well as higher level context such as ETX, ETT which may require certain processing of sensed context.

B. Context-Aware Protocol Stack Adaptation WMN protocol stack operation can be improved by

sharing cross-layer information between various nodes and adapting the protocols accordingly [13]. The use of context information is relatively new in WMN [4], though there have been some early works. WMN protocols can be adapted by measuring the global network context as shown in fig. 3.

WMN Context Adaptive

Framework

WMN

Context Sensing

Context Adaptation

Figure 3: Example of Context-Aware Protocol Stack Adaptation

Framework

C. Advantages of Context-Aware Protocol Stack Adaptation Context-aware WMN protocol stack adaptation

systems offer many advantages in comparison to stand-alone cross-layer adaptations, such as the following:

(i) Faster and accurate protocol adaptation: By having a single unified CMS that gathers both stack related context and network wide context, adaptation advice can be provided to each protocol layer for globally optimized, faster and more accurate adaptation in response to the changes in the network context [3].

(ii) Protocol simplicity: Individual protocol implementations are not required to interpret the context information collected from other layers and across the network [14] [15].

(iii) Global view: A number of non protocol stack related conditions also impact the performance of the network such as topology of the network and network mobility etc. Therefore, such context information about the network and its environment can benefit the network protocol stack optimization process [3] [13].

607

(iv) Self-management: Global view of the WMN can facilitate Autonomic network management [5] [14].

(v) Exploiting network resources: With the use of a CMS that gathers global network context instead of just the local context information, the WMN can best exploit the network resources available.

(vi) Seamlessly blend: In order to blend with the environment, the protocols should adapt to the network context [5].

(vii) Manages cross-layer interactions centrally: An integrated and unified Context-aware system can decrease the difficulty of managing different cross-layer mechanisms that are running simultaneously [15].

(viii) Self-configuring: By monitoring the network and the environment, the context-aware cross-layer protocol stack can self-configure and adapt to changes in the network infrastructure, traffic load, battery power etc [15].

(ix) Self-healing: By sensing and predicting network-wide conditions, appropriate adjustments and adaptations can be made in time [15].

(x) Self-optimisation: Context-aware information can be used to optimise the network and node objectives [15].

(xi) Adaptation: Context-Awareness allows the context-aware cross-layer system to adapt to network and node situations, such as prioritising certain monitoring, adaptation or context communication tasks over others.

(xii) Integrated solution: In place of having a patch-work and complex implementation [8] where protocol layers and cross-layer mechanisms gather context-information, operate, adapt and communicate individually, an integrated solution offers many advantages in terms of reducing duplication of work and the ability to make global optimisation as well as multi-criteria decisions.

(xiii) Avoids duplication: Duplication of effort, overhead and memory required for gathering context information can be avoided with an integrated solution.

III. REQUIREMENTS FOR CONTEXT MANAGEMENT MIDDLEWARE FOR WMN PROTOCOL STACK

This section presents a comprehensive and detailed list of important requirements for developing WMN Middleware for protocol adaptation [16] [17] [18]:

(i) Identifying relevant context-information and sources: The Middleware should be able to identify relevant context-information and the place where it is available. Context-information needed to be monitored for adaptation is based on the objectives of the network, deployment and application requirements etc.

(ii) Adaptive context gathering and Timeliness: This is required to strike a balance between the

freshness of the context-information gathered, which relies on the frequency and the process of gathering context information and the communication overhead of gathering that information [17]. Furthermore, other network context information and situations may also impact on the choice of the context gathering mechanism and the frequency of update [16] [18]. These could be network data traffic load, network mobility, remaining battery power and size of the network etc. For example, a network with high data traffic load may be able to afford less communication overhead of context-information gathering and monitoring, unless the context information is pivotal.

(iii) Lightweight context model: The context model should be lightweight in terms of storage memory as well as computational and communication overhead as it needs to operate on mobile nodes which have scarce resources [16] [18].

(iv) Extensible context model: The context model also needs to be extensible, as the context information needed for protocol stack adaptations for all future situations in which the network might operate may not be known at the design phase. Therefore, future users and designers should be able to add new context information to the context model.

(v) Context distribution: The middleware should be able to distribute context-information [17] to nodes which require them or need to act on them (such as sending route error notification to the source node).

(vi) Situation reasoning: A situation reasoning mechanism [17] is needed to reason on the gathered context information in order to identify various situations in the WMN.

(vii) Knowledge of Relationships: To ensure correct adaptation, the Context management middleware should be aware of the associations between different context types [17].

(viii) Partial knowledge and imperfections: Context information may have imperfection and sometimes it may not be available, correct or accurate. Thus, to achieve appropriate adaptations for the protocol stack, the context model should take into account such inaccuracies. Furthermore, network capacity constraints, traffic load etc may lead to partial gathering of the WMN context information [17].

(ix) Protocol Stack Adaptation: The middleware should provide appropriate WMN protocol stack adaptation based on not only local but also global context information in order to make global optimisation decisions [16] [18].

IV. PREVIOUS WORK WMNs require context information for adapting and

for selecting protocols and protocol components. Such context information could be size of the network, network mobility, remaining battery capacity, location of nodes, received signal strength etc. Most of these

608

protocols run independently to gather and manage context information and to make protocol adaptation decisions. Recently, few schemes have been published which aim to manage and gather the context required for WMN protocol stack adaptation, such as: (i) Morpheus: Morpheus [9] [19] [20] supports

collection of state information and reconfiguration of protocol stack by a coordinator that can apply global optimization. Morpheus has a set of context retrievers, present in the nodes and uses publish-subscribe for disseminating the collected information. However, as per the authors it is a simplified and non-scalable version of publish-subscribe system. Having a centralized coordinator can increase communication overhead.

(ii) ConEx: ConEx [13] [21] uses Local Event Notification Agent (LENA) at each layer which caches the subscriptions and disseminates information to the interested processes about an event. A Global Event Notification Agent (GENA) at each host manages subscriptions to and from an elected leader (Event Notification Handler - ENH) that manages global (network wide) message subscriptions and notifications. Communication to and from the ENH can increase overhead. Duplication of effort and functionality can occur by having the notification agent at each layer.

(iii) MOBCROSS: MOBCROSS [16] is a middleware that uses a publish-subscribe system. Brokers, forward messages and cache them for a fixed time. Cross-layer optimization is performed in a module shared by all protocol layers. Broker discovery and selection as well as context gathering and management are not very clear.

(iv) CROSSTALK: CROSSTALK [22] [23] proposes a cross-layer middleware. It considers both local and global network information. However, it does not propose any model for higher layer situation reasoning as well as models to manage context information and situations. Lastly, it is designed for MANETs and does not consider the presence of mesh routers in WMN.

(v) MANKOP: MANKOP [5] uses a Knowledge Plane (KP) to store information about the protocols and the network. It recommends flooding based query strategy for collecting information for networks up to 80 nodes, and random walk for bigger networks. It also uses piggybacking of information onto packets. MANKOP does not present a detailed situation and context model.

(vi) Context-Adaptive Vehicular Network Optimization: [3] proposes unification of context information gathered from the protocol stack, sensors as well as the network and using a constraint solver for finding optimal network parameters. It is not clear how context and situation reasoning models as well as context exchange and management would be done.

(vii) Context-awareness through Cross-Layer Network Architecture: [4] also uses a common Knowledge plane with gossiping, and out-of-band signaling to generate the network-wide view. However, it does not present a detailed context and situation reasoning model.

V. MESH-CMS: CONTEXT MANAGEMENT SYSTEM FOR PERVASIVE WMN

This paper proposes MESH-CMS Context Management System for Pervasive WMNs, to make the WMN protocol stack adaptive in response to changes in the environment, operating scenario and deployments. The objective of MESH-CMS is to make the protocol stack context-aware using a lightweight, extendable, distributed and integrated middleware solution which requires low communication and computational overhead. MESH-CMS offers many unified and integrated functions for the all protocol layers of WMN such as gathering context, situation reasoning, managing context information and situations as well as their semantics, handling subscriptions and ultimately providing adaptation decisions for global optimisation. Fig. 4 provides an overview of MESH-CMS working alongside the protocol stack of a node, gathering context information locally from the protocol stack and operating system of the node within which it resides as well as also globally from the network and providing advice about situations that require adaptations to the protocol stack locally and to other nodes in the network.

Figure 4: Overview of MESH-CMS Framework

MESH-CMS functions have been broadly classified into the Context-Situation-Adaptation/Action pyramid as shown in fig. 5, wherein, the lower layer context information gathered is used to deduce the situations in the WMN, which are subsequently fed to the adaptation mechanism to take appropriate action if necessary, such as to send a notification to another node, change protocol components, take protocol decisions and adjust protocol parameters and metrics etc.

Figure 5: Context-Situation-Action pyramid

609

Following are the functions of the layered architecture of MESH-CMS as shown in fig. 7, which has been inspired by [24] and adapted to meet the requirements of context-aware WMN protocols: (i) Context Gathering Layer: At the bottom of the

context-management system is the context gathering layer, which acquires the network context information locally from the mobile device as well as globally, i.e. from other nodes in the network. The functions for context gathering that are managed by this layer include, active network measurements, context subscription from other nodes, gathering information about the network and node policies, device context as well as cross-layer context information and performing passive network measurements. Context can be sub-divided into local and global context as shown in fig. 6. Local context can be derived locally at the device. Global context on the other hand is the context that pertains to the entities external to the

device, such as the neighborhood context, flow context, group context, gateway or mesh router context and the finally the network-wide context.

(ii) Context Pre-Processing Layer: Pre-processing of context information is done [25] to clean the context data gathered, aggregation of the data, checking the quality of the received context information as well as timeliness, error handling and for sending any immediate notifications if required.

Figure 6: Classification of context in MESH-CMS

Figure 7: Detailed view of MESH-CMS Protocol Stack Adaptation Framework

610

(iii) Context Management Layer: The context

management layer acts as a repository of context information as well as storing the various models for deriving higher layer context information such as ETX, ETT and WCETT etc. Context is generally hierarchical [25]. Context representation in MESH-CMS is inspired from the IEEE 1451.2 standard [26]. Each derived context can have its own context derivation model. The context management layer also manages the metadata for calculating higher layer context information. To make the context model extendible and lightweight, MESH-CMS only gathers and manages context information requested by the protocols currently in operation as shown in fig. 8. Future protocol designers also have the ability to add more context types.

Figure 8: Extendible Context Model of MESH-CMS

(iv) Situation Management and Reasoning Layer: This layer makes appropriate decisions based on the context information gathered [25] and stores the related metadata. In order to minimise the overhead (CPU and RAM) of the Situation Model and make it scalable on small WMN mobile devices, MESH-CMS uses IF-THEN based statements to determine the situations from the context facts.

(v) Query and Subscription Management Interface to CMS: This layer provides an interface to the protocol stack as well as external nodes to send context queries as well as context subscription requests to the MESH-CMS [24]. Queries arriving from external nodes as well as the protocol stack as shown in fig.7 are handled by this layer, i.e. interpreted and forwarded to the appropriate MESH-CMS interface or component [24].

(vi) Context Adaptation Layer: This layer stores the metadata related to the adaptation methods (for each protocol stack layer) such as routing protocol selection and TTL adaptation etc based on evaluation of situations in the network.

VI. SALIENT FEATURES OF MESH-CMS Following are the salient features of MESH-CMS:

(i) Distributed Middleware Reduces Overhead: With a centralized coordinator [9] [19] [20], the overhead of communication can become very high. A distributed architecture can reduce the overhead making the design scalable. Furthermore, with a centralized coordinator, the coordinator and the nodes in its close proximity would suffer drop in

battery and wireless network capacity for actual data communication due to consistent communication overhead involved in context information requests and replies coming to the coordinator.

(ii) Integrated Scheme Reduces Duplication: Having agents at each layer for communicating context can increase duplication [13][21]. MESH-CMS integrates these features into a single middleware, thereby reducing duplication of effort entailed in managing subscriptions, gathering, storing, communicating and managing context information.

(iii) Situation Reasoning: Most of the existing context-aware WMN protocol adaptation solutions do not provide Situation Reasoning models. MESH-CMS, proposed in this paper, uses IF-THEN rules for deducing situations from context facts. Adaptation advice is then provided to the Protocol layers. The protocols do not need to evaluate context information and reason about situations. This simplifies design and development of protocols.

(iv) Standardized Context Model: MESH-CMS uses a standardized (IEEE 1451.2) scheme [26] for representing context information. This is helpful as it is a standardized representation scheme for sensor networks and many sensors that provide context information to the MESH-CMS would also use such a representation.

(v) Lightweight and Simple: With the use of a simplified representation system such as IEEE 1451.2 [26], in comparison to using complex context models, there is less demand on memory and computational requirements for managing context in mobile devices. Furthermore, the use of IF- logical expressions THEN rules for situation reasoning (that is the use of propositional logic) also does not pose high computational complexity in comparison to more complex situation reasoning, for example variants of first order logic or description logic used for ontology based context models.

(vi) Extendable Design: The context model is extendable and lightweight in MESH-CMS. Only the context information that is required by the protocols in operation is gathered and managed (fig. 8). New context types can be added to MESH-CMS. All this can be achieved with relative ease as it is based on a standardized representation scheme. Situation reasoning rules can also be added and modified with ease as it is based on a simplified IF-THEN rule structure.

VII. CONCLUSION This paper comprehensively discusses the

requirements for Middleware for WMN context-aware protocol stack adaptation based on the constraints faced by WMN as well as the advantages of such a system.

611

The state of the art in the rapidly evolving field of Middleware design for WMN protocol stack adaptation is then evaluated. Finally, a layered context management system for pervasive WMN, named MESH-CMS is presented which uses a distributed middleware to reduce overhead, an integrated CMS for avoiding duplication of effort in managing context, situation reasoning and adaptation, a simplified and lightweight situation reasoning mechanism using IF-THEN rules, IEEE 1451.2 based standardized context model, all of which makes it lightweight, simple and easily extendible. The implementation of MESH-CMS architecture is currently underway. Future work would include the various mechanisms for gathering WMN context information, which have been hitherto ignored.

ACKNOWLEDGMENT NICTA is funded by the Australian Government as

represented by the Department of Broadband, Communications and the Digital Economy and the Australian Research Council through the ICT Centre of Excellence program; and the Queensland Government.

REFERENCES [1] I.F.Akyildiz and X.Wang, “A Survey on Wireless Mesh

Networks”, IEEE Communications Magazine 2005, pp.23-30, Vol. 43(9).

[2] B. Raman and K. Chebrolu, “Experiences in using WiFi for rural internet in India”, IEEE Communications Magazine, Vol. 45(1), Jan 2007, pp. 104–110.

[3] O. Mehani, R. Boreli and T. Ernst, “Context-adaptive vehicular network optimization”, Intl. Conf. on Intelligent Transport Systems Telecom.,(ITST), 2009, pp. 186 – 191

[4] M.A. Razzaque, S. Dobson and P. Nixon, "Context Awareness through Cross-Layer Network Architecture”, Intl. Conf. on Computer Communications and Networks, pp.1076-1081, 2007.

[5] D.F. Macedo, A.L. Santos, J.M. Nogueira and A. Pujolle, “A Knowledge Plane for Autonomic Context-Aware Wireless Mobile Ad Hoc Networks”, IFIP/IEEE Intl Conf. on Management of Multimedia and Mobile Networks and Services: Management of Converged Multimedia Networks and Services, 2008, Vol. 5274, pp. 1-13.

[6] J. Guerin, M. Portmann and A. Pirzada, “Routing metrics for multi-radio wireless mesh networks”, Australasian Telecommunications, Networks and Applications Conf. (ATNAC) 2007, pp. 343 - 348.

[7] M.A. Razzaque, S. Dobson and P. Nixon, “A cross-layer architecture for autonomic communications”, In Autonomic Networking, Vol. 4195, 2006, pp. 25–35.

[8] V. Kawadia and P. R. Kumar, “A cautionary perspective on cross-layer design," IEEE Wireless Communications Magazine, Vol. 12, no. 1, pp. 3-11, 2005.

[9] J. Mocito, L. Rosa, N. Almeida, H. Miranda, L. Rodrigues, A. Lopes, "Context adaptation of the communication stack," IEEE Intl Conf. on Distributed Computing Systems Workshops 2005, pp. 652- 655.

[10] R. Kodikara, C. Ahlund and A. Zaslavsky, “Towards Context Aware Adaptation in Wireless Networks”, Intl. Conf. on Mobile Ubiquitous Computing, Systems, Services and Technologies 2008, pp. 245-250.

[11] A. K. Dey, “Understanding and Using Context”, Personal and Ubiquitous Computing Journal, Vol. 5, 2001, pp. 4-7.

[12] R. Giaffreda, A. Karmouch, A. Jonsson, A. M. Karlsson, M. I. Smirnov, R. Glitho, A. Galis, "Context–Aware Communications in Ambient Networks", Wireless World Research Forum.

[13] R. Kodikara, A. Zaslavsky, C. Ahlund, “ConEx: Context Exchange in MANETs for Real time multimedia”, Intl. Conf. on Networking, Intl Conf on Systems and Intl Conf on Mobile Communications and Learning Technologies, 2006.

[14] S. Dobson, et al, “A survey of autonomic communications”, ACM Trans. on Autonomic and Adaptive Systems, Vol. 1, Issue 2, 2006, pp. 223–259.

[15] A. Liakopoulosa and A. Zafeiropoulosa, Increasing Context Awareness in Autonomic Networks, http://www.autonomic-communication.org/SAF/GRNET.pdf

[16] M.K. Denko, E. Shakshuki and H. Malik, “Enhanced cross-layer based middleware for mobile ad hoc networks”, Journal of Network and Computer Applications, Vol. 32, Issue 2, March 2009, pp. 490-499.

[17] C. Bettini, O. Brdiczka, K. Henricksen, J. Indulska, D. Nicklas, A. Ranganathan and D. Riboni, “A survey of context modelling and reasoning techniques”, Pervasive and Mobile Computing, Vol. 6, Issue 2, Apr. 2010, pp. 161-180.

[18] S. Hadim, J. Al-Jaroodi, N. Mohamed, “Trends in Middleware for Mobile Ad Hoc Networks”, Journal of Communications, Vol. 1(4), 2006, pp.11-21.

[19] J. Mocito, L. Rosa, N. Almeida, H. Miranda, L. Rodrigues and A. Lopes, “Context adaptation of the communication stack”, Intl. Journal of Parallel, Emergent and Distributed Systems, 2006, pp. 169 - 181.

[20] J. Mocito, L. Rosa, N. Almeida, H. Miranda, L. Rodrigues and A. Lopes, “Context Adaptation of the Communication Stack”, Technical Report, Dep. Informatics, University of Lisbon, 2005.

[21] R. Kodikara, S. Ling and A. Zaslavsky, “Evaluating Cross-layer Context Exchange in Mobile Ad-hoc Networks with Colored Petri Nets”, IEEE Intl. Conf. on Pervasive Services, 2007, pp. 173 – 176.

[22] R. Winter, J. H. Schiller, N. Nikaein and C. Bonnet, “CrossTalk: cross-layer decision support based on global knowledge", IEEE Communications Magazine, Vol.44, no.1, 2006, pp. 93- 99.

[23] R. Winter, J. Schiller, N. Nikaein and C. Bonnet, “CrossTalk: a data dissemination-based crosslayer architecture for mobile ad-hoc networks”, IEEE Workshop on Applications and Services in Wireless Networks 2005, France.

[24] K. Henricksen and J. Indulska, “Developing context-aware pervasive computing applications: Models and approach”, Journal of Pervasive and Mobile Computing, Vol. 2(1), 2006, pp. 37-64.

[25] P. Nurmi and P. Floreen, Reasoning in Context-Aware Systems. Position paper: http://www.cs.helsinki.fi/u/ptnurmi/papers/positionpaper.pdf

[26] “IEEE Standard for a Smart Transducer Interface for Sensors and Actuators - Transducer to Microprocessor Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats," IEEE Standard 1451.2-1997.

612