[IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Context management system for pervasive WMN

Download [IEEE 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PerCom Workshops) - Seattle, WA, USA (2011.03.21-2011.03.25)] 2011 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops) - Context management system for pervasive WMN

Post on 07-Apr-2017




2 download

Embed Size (px)


<ul><li><p>Context Management System for Pervasive WMN </p><p>Shivanajay Marwaha Jadwiga Indulska The University of Queensland and National ICT Australia (NICTA), Brisbane, Australia </p><p>{smarwaha, jaga}@itee.uq.edu.au </p><p>AbstractConventional 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. </p><p>Keywords-wireless mesh networks; cross-layer; context-aware. </p><p>I. INTRODUCTION AND MOTIVATION Wireless Mesh Networks (WMNs) [1] offer many </p><p>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. </p><p>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 </p><p>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]. </p><p> Figure 1: Example of a Wireless Mesh Network </p><p>Figure 2: Example of a Cross-Layer Protocol Stack </p><p>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 </p><p>View [4] of the information, which may not achieve system wide cross-layer performance improvement and network objectives. </p><p>(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]. </p><p>Seventh IEEE PerCom Workshop on Pervasive Wireless Networking</p><p>978-1-61284-937-9/11/$26.00 2011 IEEE 606</p></li><li><p>(iii) Cross-Layer mechanisms may not encompass all the protocol stack layers [3]. </p><p>(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. </p><p>(v) Cross-layer only provides local optimisations and not global optimisations [3]. Furthermore, WMN protocol stack needs to be </p><p>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 </p><p>network conditions, such as link quality, interference, traffic loads, network mobility, battery power, network size etc. </p><p>(ii) Deployments: Wide variety of deployments such as emergency and rescue operations, satellite networks, battlefields, metropolitan mesh networks. Different deployments have different network requirements. </p><p>(iii) Node characteristics: WMN nodes have varying capabilities in terms of battery power, number of antennas, CPU and RAM resources etc. </p><p>(iv) Node requirements: Different WMN nodes may have different requirements based on their role in the network. </p><p>(v) Application requirements: Different communication applications that run on WMN may require different protocol functionalities. </p><p>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]. </p><p>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. </p><p>II. BACKGROUND </p><p>A. Network Context Information As per [11], Context is any information that can be </p><p>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. </p><p>B. Context-Aware Protocol Stack Adaptation WMN protocol stack operation can be improved by </p><p>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. </p><p>WMN Context Adaptive </p><p>Framework</p><p>WMN</p><p>Context Sensing</p><p>Context Adaptation</p><p> Figure 3: Example of Context-Aware Protocol Stack Adaptation </p><p>Framework </p><p>C. Advantages of Context-Aware Protocol Stack Adaptation Context-aware WMN protocol stack adaptation </p><p>systems offer many advantages in comparison to stand-alone cross-layer adaptations, such as the following: </p><p>(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]. </p><p>(ii) Protocol simplicity: Individual protocol implementations are not required to interpret the context information collected from other layers and across the network [14] [15]. </p><p>(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]. </p><p>607</p></li><li><p>(iv) Self-management: Global view of the WMN can facilitate Autonomic network management [5] [14]. </p><p>(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. </p><p>(vi) Seamlessly blend: In order to blend with the environment, the protocols should adapt to the network context [5]. </p><p>(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]. </p><p>(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]. </p><p>(ix) Self-healing: By sensing and predicting network-wide conditions, appropriate adjustments and adaptations can be made in time [15]. </p><p>(x) Self-optimisation: Context-aware information can be used to optimise the network and node objectives [15]. </p><p>(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. </p><p>(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. </p><p>(xiii) Avoids duplication: Duplication of effort, overhead and memory required for gathering context information can be avoided with an integrated solution. </p><p>III. REQUIREMENTS FOR CONTEXT MANAGEMENT MIDDLEWARE FOR WMN PROTOCOL STACK </p><p>This section presents a comprehensive and detailed list of important requirements for developing WMN Middleware for protocol adaptation [16] [17] [18]: </p><p>(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. </p><p>(ii) Adaptive context gathering and Timeliness: This is required to strike a balance between the </p><p>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. </p><p>(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]. </p><p>(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. </p><p>(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). </p><p>(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. </p><p>(vii) Knowledge of Relationships: To ensure correct adaptation, the Context management middleware should be aware of the associations between different context types [17]. </p><p>(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]. </p><p>(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]. </p><p>IV. PREVIOUS WORK WMNs require context information for adapting and </p><p>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 </p><p>608</p></li><li><p>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 </p><p>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. </p><p>(ii) ConEx: ConEx [13] [21] uses Local Event Notification Agent...</p></li></ul>


View more >