Web Enabled Wireless Sensor Networks for Facilities ...

Copyright Notice In order to comply with copyright obligations regarding electronic information dissemination of IEEEcopyrighted material the following copyright notice has to be prominently displayed on the initial screen of the authors and/or their companies servers displaying this material. In this case it is a specific document, that is IEEE-copyrighted, and therefore the declaration appears as the front page of the applicable document, the full-text of which continue below.

“©2008 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works musr be obtained from the IEEE.”

Document commences on next page

500

IEEE SYSTEMS JOURNAL, VOL. 2, NO. 4, DECEMBER 2008

Web Enabled Wireless Sensor Networks for Facilities Management Apostolos Malatras, Abolghasem (Hamid) Asgari, Member, IEEE, and Timothy Baugé

Abstract—The cornerstone of building and overall facilities management is accurate and up-to-date monitoring of the context of the enterprise building environment and its surroundings, usually performed by sensors dispersed throughout the premises. Currently, the majority of building management systems is tightly coupled with the sensors that they utilize, restricting their extensibility. The emergence of Wireless Sensor Networks (WSNs) has brought significant benefits as far as monitoring is concerned, since they are more cost-efficient, due to the lack of wiring installations, compared to wired sensor solutions and allow for flexible positioning of the sensors, especially when building retrofitting is concerned. In line with the established move towards integration of enterprise level services, it is beneficial to consider the WSNs within that scope. In this paper, we propose to exploit a service oriented architecture for developing an enterprise networking environment that is used for integrating facilities management applications and building management systems with other operational enterprise functions for the purpose of information sharing and monitoring, controlling, and managing the enterprise environment. The WSN is viewed as an information service provider not only to building management systems but also to wider applications in the enterprise infrastructure. We provide specification and implementation details of the proposed architecture and discuss evaluation planning. Index Terms—Building Management System (BMS), facilities management, service oriented architecture (SOA), Web services, wireless sensor network (WSN).

I. INTRODUCTION

B

UILDING Management Systems (BMSs) manage and normally control and adjust the functionality of building systems and services from the perspective of their occupants, with exemplar cases being that of heating, ventilation and air conditioning (HVAC), security, electricity systems, lighting, access control, resource monitoring, etc. In their conventional mode of operation, these systems are managed independently, leading thus to high operational costs, cumbersome overall management, and increased level of expertise required. Lately, there has been a paradigm shift towards novel architectures that allow for integrated BMSs and support building automation and control under a unifying framework. This enables the building manager to have a single point of interaction to control all these Manuscript received January 21, 2008; revised July 21, 2008. First published November 18, 2008; current version published December 31, 2008. This work was supported in part by the Commission of the European Union NMP I3CON FP6 Project, NMP 026771-2. The authors are with the Thales Research and Technology, Berkshire, RG2 0SB, U.K. (e-mail: [email protected]; [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/JSYST.2008.2007815

facilities in an integrated manner. In this respect, the notion of facilities management can be defined as an integrated process to support and improve the effectiveness of the primary activities of an organization by the management and delivery of agreed distributed support services for the appropriate environment that is needed to achieve its set objectives [1]. One of the most important parameters regarding facilities management is accurate monitoring of the building system and its surroundings, usually performed by sensors dispersed throughout the premises. Existing building systems are tightly coupled with the sensors they utilize, restricting the generic extensibility of the overall architecture. The emergence of Wireless Sensor Networks (WSNs) has brought significant benefits as far as monitoring is concerned, since they are more cost-efficient (because of the lack of wired installations) compared to their wired counterparts, while additionally they allow for flexible positioning of the sensor devices. In line with the established move towards integrated enterprise architectures, it is beneficial to consider the WSNs within that scope. The WSN architecture should subsequently be designed in such a manner, so as to allow its straightforward integration to the building enterprise infrastructure. The necessity therefore emerges to adopt a broader perspective regarding the overall architecture of BMSs that will be open and extensible, allowing for dynamic integration of novel or updated/advanced building services. Furthermore, the diversity of the offered building services needs to be addressed, as do the evident scalability issues subject to the particular building environment application domain. The overall building services architecture should also realize a long-standing lifecycle view taking into account the needs of all stakeholders, which in turn further motivates the need for design flexibility. The most prominent approach towards an enterprise-wide, open framework, which satisfies the aforementioned requirements, is that of service oriented architectures (SOAs). In the case of SOAs, all architectural elements are decoupled and considered as service providers and consumers. Service discovery and access to the services is performed in a dynamic manner, ensuring thus a generic and extensible design. WSNs can be regarded as service providers related to building information monitoring and should therefore be considered within the scope of the facilities management SOA, which promotes the concept of dynamic, coordinated, and distributed building services management. Web services constitute the most significant technological enabler of SOAs due to the interoperability that they offer and the fact that they can easily support the integration of existing systems. This paper, presents a general framework to integrate WSNs in an overall SOA regarding facilities management. A thorough

1932-8184/$25.00 © 2008 IEEE Authorized licensed use limited to: Thales Group TRT UK. Downloaded on January 6, 2009 at 04:08 from IEEE Xplore. Restrictions apply.

MALATRAS et al.: WEB ENABLED WIRELESS SENSOR NETWORKS FOR FACILITIES MANAGEMENT

requirements analysis for the particular application domain is performed and the corresponding functionality is explained and mapped on specific elements of the design architecture that we present, while we additionally provide relevant specification and implementation details. The remainder of this paper is structured as follows. After this brief introduction in Section I, Section II describes the WSN notion and related technologies. Section III reviews related work in the area of service-oriented frameworks for the web enablement of sensor networks as well as building services and facilities management in general. Section IV discusses the proposed WSN architecture, including analysis of the relevant requirements that motivate our work. The specification of the proposed architecture is given in Section V, while Section VI concludes the paper and discusses planning for evaluation and other issues for future work. II. WIRELESS SENSOR NETWORKS Technological advances in areas such as computing platform miniaturization, low power radio transceivers and network selforganization protocols have enabled the development of small, non-intrusive, and configurable sensor platforms, which can operate for significant lengths of time on low energy supplies, and automatically configure themselves to form an information reporting network on deployment, known as wireless sensor networks. WSNs [2], [3] are a major disruptive technology, revolutionizing the relationship between the digital and the physical world. The key disruption is not only in the sensor technology arena, but also in the way sensors are deployed and used. The revolution lies in the ability to rapidly deploy large numbers of sensors with anticipated minimal capital and operational expenditures overheads, and to be able to exploit them in flexible and varied ways over time. This leads to significant increases in availability and granularity of physical world sensing, in an ever-increasing field of applications, e.g., environmental, structural, physiological sensing, etc. Although unit costs are still high, they are expected to drop significantly with the large scale adoption of the technology. Given the production volumes required to meet forecasted demand in coming years, the hardware costs will reduce so far as to make the sensor nodes disposable items in many applications. Size and energy consumption are the foremost constraints that WSN platforms have to reconcile, and it this set of constraints that is driving their design and operation. A sensor node or mote is made up of five main component types/blocks, namely the processor, the sensors, the communication radio, the power, and peripherals. At the center of the sensor device is a processor, which coordinates all other functions. The processors on sensor nodes have lately increased in capability, and can currently offer satisfactory data processing functions. Given the energy constraints of the devices, and the fact that processing requires less energy than communication, it is attractive to process data locally to reduce the amount of data needing transmission. Typical examples of node level processing include averages over time, threshold based alarms, etc.

501

The sensor block is the focal block of the device. This block may contain one or more sensors, which may be identical (for redundancy and/or multiple sources for quality of information estimation) or different. The sensor block is driven by the processor, which determines when the sensors should take a reading, according to the operational requirements programmed into the device. The communication radio block is one of the distinctive components of the sensor node. Wireless communication is fundamental to the WSN concept. The communication radio is required to be duplex (i.e., able to transmit and receive), and must be supported by adequate link layer and network layer protocols to allow effective and efficient use of the physical medium and the deployment topology. Although many devices have appeared using proprietary radios and protocols, the most prominent options include the following standards: Bluetooth [4], [5] and ZigBee/IEEE 802.15.4 [6], [7] . Power is obviously essential. However, the power sources for these devices are very limited. Given the deployment constraints, the devices may not be mains powered. Additionally, given size constraints, the batteries cannot be large, and to keep operational expenditure costs down, battery replacement must be rare. This creates one of the main challenges of the WSN field, which is the scarcity of energy and should be considered when developing any solution targeted for WSNs. We discuss power management issues in Section IV, where we also describe the design of our proposed architecture. The block regarding peripherals includes a variety of additional functions, which may be desirable on a sensor node, although not essential. Examples include storage capacity (clearly the processor requires some storage for its operation, but this refers to additional data storage) and external clocks for device synchronization and event time stamping. There are many potential additional functions, which could be added to the peripheral block, but their benefits have to be weighed against the impact in size and energy consumption. Wirelessly networking sensor nodes together is one of their key capabilities, which supports the increase in sensing granularity and the low deployment costs. Traditionally, sensor platforms have either needed to be queried locally or connected to a central monitoring station, with constraints concerning the distance between the control station and each sensor, and limits on the number of sensors a control station is designed to support. Moving from this model to a shared medium, packet-based communication network is a major step, which increases the complexity of the communication model (requirement for networking protocols), but dramatically increases the flexibility and potential capabilities. A WSN is made up of two types of devices: wireless sensor nodes and gateways. The wireless sensor node has already been described and is the core of the sensor network. A gateway device is however also necessary in order to connect the wireless sensor network to some external system, such as a wider network and to support the scalability of management operations, as well as the overall WSN reliability and survivability (see Fig. 1).

Authorized licensed use limited to: Thales Group TRT UK. Downloaded on January 6, 2009 at 04:08 from IEEE Xplore. Restrictions apply.

502


Fig. 1. WSN exemplary deployment architecture.

III. RELATED WORK Automating the facilities management domain by enabling the employment of intelligent operations and of unsupervised management and control has attracted significant research interest over the past years [8]. Successful examples of individual automated building services and systems exist, e.g., HVAC controls, security systems, fire alarms, etc. Their integration and the adoption of a building-wide degree of automation have nonetheless not been reviewed thoroughly. There is an evident lack of holistic, integrated building management solutions, since current relevant approaches are not addressing the problem at a satisfactory level [9]. The approaches that have been most profoundly established, i.e., cross-protocol gateways and standard communication protocols have not satisfied the desired expectations and have had a narrow applicability field. The need for building services and systems integration is subsequently evident due to the numerous benefits it can bring to both the occupants of the building as well as the facilities operators/managers [10]. More recent approaches are exploiting and developing middleware technologies to support building automation systems and building services at a higher layer [11]–[13], as a response to the firm necessity for integration. Such novel approaches for integration do not intend to substitute proprietary, low-level building automation systems. The focus is on providing smooth integration of diverse systems and services by using the notion of middleware abstraction, i.e., the individual building systems continue to operate as originally configured by their manufacturers, yet middleware wrapper applications are used to facilitate interaction and interoperability. Among the available middleware technologies, the ones that have been utilised in building automation environments include open connectivity (OPC using COM/DCOM as the communication interface technologies) [11], [13], CORBA [14], and JAVA/RMI [15]. Most of the aforementioned middleware-based solutions bear inherent problems, which are predominantly focused on the fact that the proposed solutions are based on proprietary, closed technologies such as COM/DCOM that hinder interoperability. Furthermore, they have been designed with a specific application in mind; hence, their potential for extensibility is limited. One

should also consider the importance of incorporating BMSs and automation systems in the overall enterprise-networking environment, an aspect that has been neglected in most middlewarebased solutions. There has been a wider spectrum paradigm shift towards the adoption of enterprise-wide architectures, which take into account cross-layer interactions and business objectives alongside system requirements. It becomes therefore evident that it would be beneficial to exploit such enterprise architectures, driven by the SOA paradigm, in the building management realm [16], [17] . Under this prism, IT and building management convergence is logically promoted, while allowing for open, flexible, and scalable enterprise-wide architectures to be built. Furthermore, following this stream will enable the much desirable accessibility of overall facilities management over the Internet. Such a research direction has also been implied by recent work in [11], where there are nevertheless problems as previously indicated. The main drivers behind the convergence of IT and existing building systems are to reduce operating cost, to reduce complexity of the system, hence training/experience required of staff, to reduce capital costs (wiring, equipment, etc.), and to provide value-added services. The synergy created by combining building infrastructure and data communications reduces operational costs and creates new service opportunities [18]. The main implication of this synergy, which is enabled by enterprise-wide architectures, regarding facilities management automation is that it provides BMSs and building automation and control systems with access to additional information that will enable the building to be used more effectively [19]. This information as far as the automated building control semantic domain is concerned can be collected from a variety of sources, ranging from physically sensed data (structural, environmental, physiological, etc.) to electronic records (building maintenance records and schedules, personnel profiles and calendars, business processes and policies, etc.). WSNs as information sources are alternatives to wired sensor solutions that additionally facilitate sensor deployment and reduce costs, mostly through the absence of wiring maintenance [20]. The apparent benefits that can be achieved by utilizing WSN technology in building automation have led to a number of related research efforts [18]–[28]. Initial work on the area consisted of cost-benefit analyses for the use of WSNs in building operations, compared to employing their wired counterparts. These analyses were complemented with reviews of relevant technological advances that highlighted the penetration and advantages of WSN approaches in the building management domain [18], [21]. Limited resources of WSN nodes were studied in [20] in order to examine the feasibility of implementing standard concepts of building automation systems, e.g., BACnet [31], in sensor platforms. This was deemed as possible, with limitations nonetheless in their portability and ease-of-development. The first effort towards understanding the need for exposing the rich number of sensors and their corresponding readings, i.e., data measurements, in a wider scope across the Internet was presented in [22]. The IrisNet architecture described in [22] was based on agent technology in order to collect sensor data and organize them into a distributed database that could be accessed



in a distributed manner over the Internet. The use of agents is considered restricting and furthermore this sort of architecture did not envisage an enterprise-wide scope, so as to cooperate with other applications; the work in [22] rather concentrates on the sensor network aspects, yet nevertheless forms a motivating and noteworthy effort. A similar approach is followed in [28], where building automation case studies are examined. Wireless technologies are used for monitoring and the exposed information is made available through web pages, adopting as before a narrow scope regarding extensibility. Research work in the area of WSNs has moved from the traditional view of sensor networks as static resources, from which data can be obtained, to the more innovative view of systems engineering in general, where everything is considered in a service-oriented perspective [23]–[27], [33]. This allows WSNs to be regarded as service providers, i.e., information services, and consequently more advanced, dynamic, reusable, and extensible applications and operations to be provided. Enterprise application integration is therefore additionally facilitated, particularly with BMSs for facilities management. The benefits of exposing sensor nodes and sensor networks as service providers in a generalized SOA motivated the emergence of the Sensor Web Enablement (SWE) activity [33] by the Open Geospatial Consortium (OGC) [32]. It is essentially a set of standards that allow for exposing sensor networks as Web services making them accessible via the Web. The SWE initiative is focused on standards that enable the discovery, exchange and processing of sensor observations, as well as the tasking of sensor nodes. The application area of SWE was planned to be generic and hence some aspects of it appear too complex in their strive to incorporate all possible features; it has nevertheless so far focused on factors such as geolocation, remote positioning, and scientific applications. While this work is a valuable starting point, it is too generic to be directly applicable, and requires tailoring to be adapted to the facilities management domain despite its benefits. Among these benefits one can identify that the underlying WSN complexity is hidden from higher-layer applications, common operation reusability is ensured, scalability, extensibility, and interoperability are promoted, etc. The SWE initiative has attracted significant research interest and ongoing work within the OGC will eventually lead to development tools being made openly available and its standardization [32]. In addition to that, other efforts build on SWE principles to propose architectures for exposing WSNs as service providers in an SOA, such as [25] and [27], the latter indicating existing limitations in SWE. Our work takes advantage of certain principles set out by SWE, such as abstraction, separation of operations in reusable objects and applies them to the facilities management realm, also taking into account the particular domain’s inherent characteristics, e.g., space categorization and coexistence with existing BMSs and building services. In [26], a set of Web services is introduced for collecting and managing sensor data for environmental and spatial monitoring. This work has a confined scope regarding the use of sensors, while it sidesteps integration issues with enterprise-wide applications, which is the most important benefit of the SOA paradigm. Service oriented architectures at a different level, concerning the core WSN activities such as sensing, processing,

503

etc., is studied at [24]. While this work is useful, our efforts focus on exposing the WSN as a service to the overall enterprise facilities management system. On the contrary, the Atlas platform [23] relates more closely to the approach we plan to undertake regarding the overall framework for the web enablement of WSNs. We distinguish ourselves from this work however, since we do not utilize specific hardware platforms as Atlas does and hence allow for different and diverse sensor platforms to be used. In the following, we present our approach for the web enablement of WSNs for facilities management, while in parallel, we describe the requirements that drive our design. IV. PROPOSED WSN ARCHITECTURE This paper provides a detailed architectural framework for WSNs to be integrated seamlessly with enterprise applications over an SOA infrastructure, within the scope of facilities management. An overall WSN architecture serves a multitude of facets such as follows: • optimizes the information flow and accessibility, allowing all authorized systems and applications, which require a given source of information to have shared access to that information stream; • increases the coverage, resolution, and accuracy of the information awareness made available to human and automated decision makers, by developing an information web, which all systems and applications can access and exploit through standard interfaces; • develops a new design approach to high-level facilities management applications, by allowing composition of data, information and operational services into added value monitoring and decision making support tools. One fundamental concept to building management systems that is inherently bound to WSNs is that of context awareness. We define as context of a system the set of information of every nature that describes the system, influences system aspects and that is being affected by the system’s operation, the ownership of which is not necessarily solely held by the system. WSNs are the sources from where context information can be retrieved. The collection of information from disparate sources throughout the building by appropriately configured sensors is extremely beneficial to the building management system and necessary for its proper operation. This information nevertheless has to be managed effectively. The collected data from the sensors have to be translated into high-level contextual information using context models. Context models are key to interpreting raw data into high-level information that is useful to the application layer; hence, context modeling is the foundation of any attempt at providing context awareness in a system. A. Node-Level Functional Layered Architecture The functionality of the WSN architecture can be decomposed in the following two complementing aspects: • WSN services exposed to the enterprise architecture by means of the enterprise middleware; • WSN tasking to monitor context information by means of the tasking middleware.


504


Fig. 2. WSN functional layered architecture.

The WSN architecture needs to be incorporated in the overall facilities management SOA that we envisage. It assumes the role of service provider as far as data collection and information management—in the sense of context awareness—is concerned. This justifies the need for a WSN service interface to be defined and exposed to the SOA infrastructure, in order to hide the complexity and heterogeneity of the underlying WSNs. The architecture that we propose for this purpose has to additionally cater for the monitoring and data management aspects. These functional requirements are addressed by a tasking middleware that is responsible for translating the high-level requests for information as received from clients of the facilities management SOA into low-level, WSN-specific data queries. The clients need not be aware of the WSN internal operations, hence, the importance of the tasking middleware. A typical use case scenario of the proposed WSN architecture involves the following. When a facilities management service wishes to obtain specific WSN monitored information, it accesses the respective WSN service interface requesting so. The WSN service is discovered by accessing the Service Registry, which provides details on available service interfaces that satisfy certain selection criteria. Upon receiving a client request, the WSN service assigns this request to the tasking middleware that directly operates on top of the sensor nodes and performs the actual data collection and possibly processing. The outcome of this operation, i.e., the corresponding sensed data, is then forwarded to the WSN service that posts the processed information back to the original requester. The WSN architecture is implemented over two sensor platforms, i.e., the sensor node and the gateway, as explained in Fig. 1, while at a higher layer of abstraction the Virtual Gateway entity is responsible for managing the WSN as a whole. The high level, layered architecture of the WSN nodes is shown in Fig. 2 for both the sensor node and the gateway. We elaborate on the Virtual Gateway at a later stage. The functionality for both the sensor nodes and the gateways is almost identical apart from the fact that the gateway has an additional feature, i.e., gateway coordination and the sensor nodes have the tasking middleware employed. A gateway essentially is a network-bridging device, which connects the WSN to the enterprise network. In that sense, it does not participate in the tasking of sensors; it rather relays

Fig. 3. WSN node and network services.

data from the WSN to the enterprise network and vice versa. To ensure scalability and reliability of the WSN we consider that there might be the need to have more than one gateway for a single WSN (as shown in Fig. 1 for example), since for example the number of nodes could rise significantly or the main gateway could potentially fail. Another reason to allow for multiple gateways is the survivability of the WSN, since there would be a more power efficient distribution of resources consumption. The reason for this is the fact that not all nodes should use the same path to route their data towards the gateway, which would drain the resources of particular nodes rapidly and hence lead to node failures. Nevertheless, conceptually the WSN should be viewed from external entities as having a single point of access to ensure consistency and have manageable administration. For every WSN therefore one of the gateways assumes the role of the Master Gateway (MGW) and the remaining gateways, if any, are deemed as Secondary Gateways (SGW). Both the MGW and SGWs manage their respective assigned sensor nodes, but the MGW is moreover responsible for coordinating all gateway activities within a zone through an appropriately defined gateway coordination protocol and serving as the single point of access to the WSN for communication with external entities. The gateway coordination protocol is responsible for informing the Virtual Gateway, which will be introduced in Section IV-B, of any changes in the WSN, e.g., MGW and SGW status. The tasking middleware, hosted on the sensor nodes, will be described in detail later. In short, it is the core of the proposed WSN architecture as it allows for sensor data collection and reporting. Furthermore, the security issues in WSNs [34] have to be given explicit consideration, as this remains to date an open issue. Reprogramming [35] is also an essential but challenging task in WSN management due to limitations in available resources and constraints in communication capabilities. These two aspects, seen as functional blocks of sensor nodes and gateways in Fig. 2, are however outside the scope of our current work.



One important facet of the functional layered architecture of the sensor nodes and the gateways as presented in Fig. 2 is that of node and network services. Fig. 3 illustrates the functional decomposition of the WSN node and network services for both the gateway and the sensor nodes. The network service layer deals with the communication aspect of the sensor network. As far as the WSN side is concerned, it relies mainly on the radio/enterprise network interface components of the node services, and provides the protocol stack functions above them. The node services are the functions, which are local to the devices. Both sensor node and gateway contain the same basic computing functions, namely processing, and storage. Moreover, being both part of the wireless network, they contain a radio function. Although these functional blocks exist in both sensor node and gateway, they are likely to have diverse levels of capability in the two platforms. Gateways are not constrained in energy, as they can be mains powered, have less size constraints and therefore can have significantly higher computational and storage capacity than sensor devices. The gateway additionally has an external network interface, to connect to the wider network, so that the corresponding WSN can be accessed remotely and also to allow for the inter-gateway communication (MGW to SGWs). Sensor nodes contain a number of additional node services, not present in the gateway, such as a sensing, a power management, and a positioning function. Power management is an essential function within the WSN nodes. In order to achieve a meaningful life expectancy for deployment of sensor nodes, energy must be preserved by enforcing strategies to switch off parts of the device when such actions will lead to energy savings (the energy costs of powering down and powering up must be offset, etc.). Many functions/services on the platforms are candidates for duty cycling, but the benefits and impact on the node’s overall performance will be different for each one. In particular, the duty cycling of the radio has a significant power benefit, as many radio designs require comparable power draws whether the device is transmitting, receiving data, or just listening to the channel. However, duty cycling the radio also has a crucial impact on the fabric of the network, as neighboring devices can only communicate if their radios are on at the same time. Solutions to this prominent issue can be divided into two classes: either transmitting preambles before any data message that are longer than the maximum time a node can be asleep [36]. This ensures that a neighbor node will always hear some part of the preamble and can remain awake to hear the subsequent message; or employing some synchronization strategy to ensure neighboring nodes are awake at the same time [37]. A combined approach is often applied [38], whereby a level of synchronization allows the use of a shorter preamble. The length of the required preamble is therefore inversely related to the synchronization precision. Building management application requirements must be considered in order to set the tradeoffs between power saving and node availability. For periodic reporting services, the WSN can be permanently asleep between reports (apart from occasional network and node management activities) and therefore run very efficiently. The implication of adopting this tradeoff is however that retasking the network will be a slow process, as control

505

messages can only be disseminated during the awake periods. If rapid retasking is required (for example, the ability to deliver high granularity information in time and space when an incident occurs, within seconds of the request being issued), then the network duty cycles must be short enough to propagate the task throughout the networks within the time constraints. The power requirement of operating with this tradeoff is much higher, as the devices must be awake more frequently to listen for transmission. The standard approach is to determine the optimal tradeoff for the particular application requirements and to deploy the WSN operating service accordingly. A much more flexible alternative can be envisaged, whereby the tradeoff is set dynamically in a context aware fashion, as described in [39]. By implementing basic context processing and decision making into the WSN nodes, the duty cycling regime can be changed proactively, in all or part of the network, if an incident is detected. This advanced level of power management allows significant power savings while supporting rapid retasking. B. Network Level Functional Architecture An important issue in designing the WSN architecture is that of scalability and robustness, because of the potentially large number of sensors in a building and their limited radio transmission ranges. We assume that a building consists of multiple zones/spaces each one having a WSN dedicated for its monitoring needs, as shown in Fig. 4. The MGW entities are utilized to connect each of these WSNs to the enterprise network and SGWs might be used as well, as discussed previously. These gateways manage the nodes that are under their zone of responsibility. Other applications nevertheless are unaware of the potentially numerous zones and hence gateways in a building. The enterprise applications that access the WSN service need a certain degree of abstraction from the underlying complexity and the specifics of the zone/space assignments, and require a single point of contact to WSN-related activity in the building as a whole. This is the reason for introducing the notion of a prime Virtual Gateway (VGW). The Virtual Gateway is aware of the various WSNs available in a building and their respective MGWs and SGWs by accessing a Building Information Model (BIM) [40], which is a service of the overall building information system architecture that serves as a central point for all building related information, and translating the textual description to actual building location information. When enterprise services require interaction with the WSN architecture as a whole, this occurs through the relevant WSN service interface that interacts with the Virtual Gateway (see Fig. 4). The Virtual Gateway is equipped with an enterprise middleware layer, which is responsible for communicating with the WSN service interface of the SOA. It has to be clarified that the Virtual Gateway itself is not part of the WSN, but is used to access and interact with the WSN. The Virtual Gateway resides outside the WSN and communicates with the MGWs, in order to expose data gathered by the WSN to high-level applications. The Virtual Gateway has nevertheless the functionality for the tasking middleware, in order to be able to instruct the sensor nodes (that also have this functionality) on data collection and reporting as per the


506


Fig. 4. Proposed WSN networking architecture and its scalability support.

client requests. A back-up Virtual Gateway has also been considered for stability and reliability reasons (so as for the Virtual Gateway not to constitute a single point of failure). The backup VGW monitors the operation of the prime VGW and receives all relevant communications to the VGW and records the necessary tasks and data, but only assumes its operation if the prime VGW fails for any reason. In the following, for reasons of simplicity and without loss of generality, we will consider that every WSN has only one MGW, which will be referred to plainly as gateway. No SGWs and backup VGW are considered. V. SPECIFICATION OF THE ARCHITECTURE The WSN service interface is exposed in an overall SOA for facilities management. There exist various service models, such as JINI, grid services, CORBA, Web services (WS) etc. We opt in favor of Web services [29], the main reason being their wide-acceptance and the fact that they enable easy and straightforward deployment of applications over enterprise networks and the Internet in general, as required by our architecture. WS are among the major technological enablers of SOAs and have attracted significant research interest, due mainly to the fact that they are supported by well-established standards. WS constitute a means for various software platforms to interoperate, without any prerequisite regarding platforms and frameworks homogeneity being necessary. The WSN environment is essentially a collection of resources (i.e., sensors) that continuously monitor their environment (i.e., get measurements). We have therefore defined a representational state transfer (REST)-based style SOA to enable integration of the WSN with enterprise services. REST-based WS [41] lack the complexity of SOAP-based WS [42] and form an open and flexible framework, allowing scalable and dynamic resource monitoring [43], [44]. The WSN Web services are rooted at the following base URI: http://{hostname}/REST/{version}/. The {hostname}

Fig. 5. WSN WS URI hierarchy.

parameter must be replaced with the name of the server hosting the WS, and the {version} parameter must be replaced with the version number of the service. When a client wishes to interact with the WSN architecture over the SOA, the client issues the appropriate HTTP method, namely GET (to query an existing resource), POST (to create a new resource), DELETE (to remove an existing resource), PUT (to update an existing resource). The WS URI hierarchy for the proposed WSN architecture is illustrated in Fig. 5. For example when a client wishes to retrieve the results from a particular DomainTask resource, then he/she issues an HTTP GET request to the URI http://{hostname}/REST/{version}/DomaintaskResult/id, where id is the unique identifier of that result and the corresponding data is returned using an XML representation. It has to be clarified that the WS interfaces reside on a web server and will be registered to a service registry to enable their discovery by clients. The actual functionality behind the WS interface is implemented by the Virtual Gateway entity, which was discussed previously. It is at the Virtual Gateway where the required processing takes place, prior to the tasking of the WSN to collect data. The MGW and SGW entities serve as network bridging devices between the WSN and the Virtual Gateway. Clients have access only to the DomainTask resource exposed through the WSN WS interface and the other resources are used internally by the WSN architecture, namely the Virtual Gateway. The DomainTask represents a high level tasking of



the WSN that is described in terms that are more familiar to the building management domain than the WSN domain. It is the job of the Virtual Gateway of the WSN architecture to take a DomainTask as input and translate this into one or more SensorTasks that can deliver the data required to fulfill a DomainTask. The SensorTask resource is a lower level tasking of the WSN that is specified in terms that are familiar to this domain. SensorTasks can cause one or more Sensors to be configured to deliver data. The SensorTask may perform processing and aggregation of data received from Sensors before data delivery. The base SensorTask type is abstract, with specializations existing to describe periodic data collection tasks and conditional, or alarm-based, data collection tasks. Each SensorTask is assigned to a sensor node of the WSN architecture. The sensor nodes report data back to the Virtual Gateway via their respective gateway. The Sensor resource represents a sensing component of the WSN. It provides a mechanism for getting information about the capabilities of the sensors that comprise the WSN, including sensor type, position, and power status. The Space resource represents a textual description of a space, i.e., a zone, of the building environment, e.g., a room, a block, etc. It provides a mechanism for communicating with the BIM. The format of the resource representations used by the WSN architecture has been formally described [30]. Resource representations are used both by clients when sending a request to a server, and by servers when returning a response to a client. The data model is formally specified using an appropriate XML Schema Definition; further details can be found in [30]. The tasking middleware is the architectural entity that implements the functionality exposed by the WSN service interface. It is actually a client-server architecture with the client side residing on sensor nodes and the server side existing on the Virtual Gateway. The tasking middleware receives as input high-level service requests (known as WSN queries) from enterprise entities via the enterprise networking architecture, i.e., WSN WS interface, determines at the Virtual Gateway what data and processing are required to provide the service, tasks the relevant sensor nodes to perform sensing and processing (known as sensor tasks), collects the resulting data at the sensor node, sends the data back to the Virtual Gateway where it is contextually processed and stored it in a database (DB) for record keeping reasons and finally responds to the original service request. Fig. 6 shows the WSN deployment architecture and presents the highlevel view of the WSN architecture within the overall enterprise level scope. Before proceeding in presenting a concrete specification of the tasking middleware architecture, it is important to comprehend its functionality. An overview of the tasking middleware’s functional entities is shown in Fig. 7. There is a differentiation on the capabilities of the sensor node and those of the Virtual Gateway, which is mapped on the functionality of there two entities. The tasking middleware mainly involves the following three operations.

507

Fig. 6. WSNs deployment architecture within an enterprise environment.

Fig. 7. Tasking middleware functional entities in sensor nodes and VGW.

A. Service and Location Registration/Discovery It involves sensor nodes advertising their capabilities (i.e., status, processing, battery life, location, etc.) to the Virtual Gateway that will use them to determine task allocation at a later stage. Discovery of services and locations is discussed in an upcoming section. As the WSN is not a static entity this operation is crucial to register available services and node locations and to remove the ones that have become unavailable. B. Data Service Processing This operation is designed to decouple the high level WSN data queries, i.e., DomainTasks of Fig. 5, from the low-level data collection and processing tasks, i.e., SensorTasks, so that low-level task outputs can be reused to serve multiple high level requests if appropriate. This involves context processing and is fundamental to the scalability of the middleware in handling a large number of high-level tasks. Both processing of requests from clients over the WSN WS interface, i.e., decomposing them into SensorTasks, and processing of responses, based on data reported by sensor nodes and other request parameters are being handled by this operation located at the VGW. C. Node and Network Tasking These operations are responsible for the actual tasking of the sensor nodes. On the Virtual Gateway, the network tasking operation involves determining which sensor nodes can perform the required tasks (as identified by the data service processing operation), assigning the tasks to the appropriate nodes and handling their responses. On the nodes, the node tasking operation


508


Fig. 9. Typical data flow for node tasking location/service registration and discovery. Fig. 8. Specification of service/location registration and discovery.

schedules and executes the sensor tasks and manages task activation and reporting. The functional architecture of the tasking middleware defines operations for service/location registration of the sensor nodes to the Virtual Gateway and particularly its service/location discovery blocks. Service and location discovery and registration involve a series of actions and participating modules. Fig. 8 depicts the functional architecture specification for the tasking middleware as far as service/location registration and discovery is concerned. On the sensor node, the only architectural module is an Advertisement Manager that upon bootstrap and sensor initialization advertises node configuration information and handles relevant periodic updates. On the Virtual Gateway, the corresponding Advertisement Manager receives node configuration advertisements, stores this in the Node Database (DB) and monitors its validity (it is possible for the Node DB manager to interact with the BIM, through the enterprise middleware as seen in Fig. 6, to acquire further sensor-related information). A Query Manager receives service queries from clients and reports with appropriate node information by accessing the Node DB. A typical data flow for the service/location registration and discovery operation of the tasking middleware is presented in Fig. 9, where a node first advertises its capabilities to the Virtual Gateway, so that the latter can respond to external queries regarding node capabilities. Fig. 10 depicts the tasking middleware architecture for data queries/responses and illustrates the modules that provide the aforementioned functionality (shown in Fig. 7) as far as the Virtual Gateway is concerned. The Query Manager is the main middleware module on the Virtual Gateway and is responsible for listening to client queries regarding data collection through the Enterprise Network Handler. The client queries are expressed as HTTP POST requests to the DomainTask resource (see Fig. 5) with an XML document describing the desired parameters attached, which is then forwarded from the WSN WS interface to the Enterprise Network Handler of the Virtual Gateway. Upon receiving a new client request through the Enterprise Network Handler, the Query Manager contacts the Query Decomposer to generate tasks from the client’s data query. This

Fig. 10. Specification of data query-response architecture (Virtual Gateway).

operation in the Query Decomposer involves mapping from the high-level queries set by clients to the low-level WSN specific sensing tasks (the mapping from high-level space semantics to WSN specifics occurs by the Query Manager contacting the Node DB and the BIM for node and building related information respectively and passing these to the Query Decomposer together with the query’s details). The Data Queries and the corresponding list of task requests are stored in the Data Query DB and the Sensor Task DB, respectively, while the task requests are also dispatched from the Query Manager to the Sensor Task Manager (the sensor tasks and the assignment to sensors are also stored in the DB shown in Fig. 6 by the Query Manager contacting the corresponding WSN



WS interface, i.e., SensorTask and Sensor resource, through the Enterprise Network Handler). The Sensor Task Manager filters redundant tasks with the use of the Task Filter module and consequently sends the tasks to the appropriate sensor nodes through the ZigBee interface Network Handler module (we are using ZigBee as the underlying WSN network technology) that is responsible for communicating with the sensor nodes via their MGW or SGWs. The ZigBee Network Handler resides on the Virtual Gateway and its operation involves formatting the messages from the Virtual Gateway in such a manner so as they can be transmitted to the WSN (the ZigBee message formed here, is wrapped with an IP header and is sent to the MGW or SGWs over IP, whereupon the header is removed and the message is forwarded to the appropriate sensor nodes as a standalone ZigBee message). The Virtual Gateway tasking middleware architecture that is illustrated in Fig. 10, receives input from the sensor nodes through the Response Manager entity. Sensor node messages are sent to the ZigBee Network Handler, which forwards them to the Response Manager that updates the Data Query DB in order to flag the corresponding query as completed. The data is then sent back to the Enterprise Network Handler that returns it to the client for handling according to its requirements. In our proposed architecture, the data are stored in a DB for keeping track of historic trends and records. In this case, the Enterprise Network Handler sends this data together with the data query details to the DomainTaskResult resource of the WSN WS interface that contacts the DB and stores the data. If there is data missing or some other error reported to the Response Manager, then this error is propagated back to the client via the Enterprise Network Handle, in order to be handled. The reason for this is that the nature of WSNs does not allow for recovery from failure, i.e., if data is missing then the particular data cannot be retrieved since they correspond to real-time monitoring. Therefore, some other means of recovery should be considered, according to the client’s requirements and this is the reason behind our design choice of not addressing data errors in the Virtual Gateway. On the sensor side of the architecture (see Fig. 11), there is a ZigBee Network Handler to allow for communication with the corresponding module of the Virtual Gateway. It is this module’s responsibility to send and receive ZigBee messages. When sending a ZigBee message it is first received by the MGW or SGWs of the particular zone, whereupon an IP header is attached to it and then it is routed to the Virtual Gateway’s ZigBee Network Handler over IP. When a message is received then it is forwarded to the Task Processor, which processes sensor tasks and stores them in the Task DB, while additionally it handles task cancellations. Upon receipt of a new task request, the Task Processor stores it into the Task DB and then forwards it to the Task Scheduler in order to plan its execution, since many tasks may be concurrently submitted to the same node. The Task Scheduler dictates execution by sending the task request to the Task Data Manager that performs the action specified in the task by allocating the necessary resources and sampling the appropriate hardware sensors. Upon successful completion, the Task DB is informed and updated with the relevant task verification/execution data and the Data DB is

509

Fig. 11. Specification of data query-response architecture (sensor node).

Fig. 12. Typical data and control flow for node tasking query-response (Virtual Gateway).

updated with the derived sensor data if the resources at the sensor node allow such an operation. A notification message (with data or an alarm report depending on the sensor task) is sent back to the ZigBee Network Handler, to be forwarded to the Virtual Gateway as previously described. The Virtual Gateway is thus informed of successful task completion. A typical data and control flow for the data querying and responding operations of the tasking middleware is presented in Fig. 12 for the Virtual Gateway and in Fig. 13 for the sensor nodes, respectively, also serving as an algorithmic description of the sequence of occurring operations. We have also specified the functionality required for query cancellations. Cancellation of an active data query involves the


510


Fig. 13. Typical data and control flow for node tasking query-response (sensor).

same entities as the ones found in the introduction of a new data query. The client requests a query cancellation by issuing an HTTP DELETE request to the DomainTask resource of the WSN WS interface (shown in Fig. 5) with the query identifier as the sole parameter. The client request for cancellation is propagated to the Virtual Gateway via its Enterprise Network handler entity and subsequently to the sensors that the original query was intended for and all relevant references along the path are removed. Fig. 14 depicts a typical data and control flow regarding the cancellation of an active data query. Only the modules that are actually used for the query cancellation are depicted in Fig. 14, e.g., the Node DB that is not influenced by this operation is concealed. By using the specified architecture implementation, sensor information is made available to BMSs and other information consumers via the enterprise-based networking infrastructure. VI. CONCLUSION We have discussed in this paper an architectural framework that enables the integration of wireless sensor networks in an overall facilities management enterprise architecture. The benefits that can be reached by utilizing service-oriented enterprise architectures are numerous, hence the need to move towards such approaches. Reductions in cost, flexibility and agility to respond to dynamic conditions are among the most prominent advantages that can be observed. We have discussed related issues and based on an extensive requirements analysis we have provided a functional architecture and a corresponding specification for the proposed WSN architecture. Scalability, extensibility, and reliability that are extremely important in the wireless domain have been taken into account, while in parallel security should also be supported. We elaborated on a service-oriented architecture to expose WSN-related information to the overall enterprise architecture and detailed on the tasking middleware aspects that are actually responsible for data collection and processing.

Fig. 14. Typical data and control flow for tasking middleware data query cancellation.

Our future work focuses on system level evaluation of the proposed architecture in our experimental WSN testbed in order to validate the development efforts and furthermore to examine areas of potential deployment of such an approach. The final evaluation is planned to be performed by setting up the entire system in real buildings and assessing its overall impact and performance. The purpose of the system level evaluation is to determine whether the overall objectives of the proposed architecture have been realized. The overall aim for the SOA-based architecture has been to create an appropriate building services environment that can maximize benefits, reduce the costs, be reliable and provide continuous availability, be scalable, stable, and usable. One other aspect that we plan on evaluating is the use of this architecture in order to implement a building assessment tool as far as energy efficiency is concerned. This is a highly significant and emerging issue regarding buildings and is going to be our main area of research. REFERENCES [1] European Committee for Standardization (CEN), Brussels, Belgium, “Facility management—Terms and definitions,” prEN 15221:2005, 2005. [2] I. F. Akyildiz, S. Weilian, Y. Sankarasubramaniam, and E. Cayirci, “A survey on sensor networks,” IEEE Commun. Mag., vol. 40, no. 8, pp. 102–114, Aug. 2002. [3] C.-Y. Chong and S. P. Kumar, “Sensor networks: Evolution, opportunities and challenges,” Proc. IEEE, vol. 91, no. 8, pp. 1247–1256, Aug. 2003. [4] C. Bisdikian, “An overview of the Bluetooth wireless technology,” IEEE Commun. Mag., vol. 39, no. 12, pp. 86–94, Dec. 2001. [5] Bluetooth Special Interest Group (SIG), Trade association, “Get technical,” 2008 [Online]. Available: http://www.bluetooth.com/ [6] IEEE Standard for Information Technology—Telecommunications and Information Exchange Between Systems—Local and Metropolitan Area Networks—Specific Requirements—Part 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (WPANs), IEEE Std. 802.15.4-2003, 2003.



[7] ZigBee Alliance, Association of Companies, “ZigBee Specification 1.0,” 2005 [Online]. Available: http://www.ZigBee.org/ [8] D. Snoonian, “Smart buildings,” IEEE Spectrum, vol. 40, no. 1, pp. 143–159, Jan. 2005. [9] J. E. Braun, “Intelligent building systems—Past, present, future,” in Proc. Amer. Control Conf., Jul. 2007, pp. 4374–4381. [10] S. W. Wang and J. L. Xie, “Integrating building management system and facility management on internet,” Automation in Construction, vol. 11, no. 6, pp. 707–715, 2002. [11] S. Wang, Z. Xu, J. Cao, and J. Zhang, “A middleware for Web serviceenabled integration and interoperation of intelligent building systems,” Automation in Construction, vol. 16, pp. 112–121, 2007. [12] S. Wang, Z. Xu, H. Li, J. Hong, and W.-Z. Shi, “Investigation on intelligent building standard communication protocols and application of it technologies,” Automation in Construction, vol. 13, pp. 607–619, 2004. [13] Z. Ming, C. Li-Ding, and X. Bu-Gong, “A middleware framework for integrating intelligent building systems based on the sub-system peer mode,” in Proc. IEEE IMACS Multiconf. Comput. Eng. Syst. Appl. (CESA), Oct. 2006, pp. 1766–1770. [14] Y. Wang and Z. Y. , “Design and implementation of intelligent building management system (IBMS) based on CORBA,” Comput. Digit. Eng., vol. 29, no. 2, pp. 16–22, 2001. [15] P. Davidsson and M. Boman, “Distributed monitoring and control of office buildings by embedded agents,” Inf. Sci.—Inf. Comput. Sci.: Int. J., vol. 171, no. 4, pp. 293–307, 2005. [16] E. Craton and D. Robin, “Information model: The key to integration,” 2002 [Online]. Available: http://www.automatedbuildings.com/ [17] P. Ehrlich, “Guideline for XML/Web services for building control,” in Proc. BuilConn, Dallas, TX, Apr. 2003. [Online]. Available: http:// www.builconn.com/ [18] M. R. Brambley, M. Kintner-Meyer, S. Katipamula, and P. J. O’Neill, “Wireless sensor applications for building operation and management,” in Web Based Energy Information and Control Systems: Case Studies and Applications, B. Capehart and L. Capehart, Eds. Boca Raton, FL: The Fairmont Press/CRC Press, 2005, pp. 341–367. [19] A. Wheeler, “Commercial applications of wireless sensor networks using ZigBee,” IEEE Commun. Mag., vol. 45, no. 4, pp. 70–77, Apr. 2007. [20] F. Österlind, E. Pramsten, D. Roberthson, J. Eriksson, N. Finne, and T. Voigt, “Integrating building automation systems and wireless sensor networks,” in Proc. 12th IEEE Conf. Emerging Technol. Factory Autom. (ETFA), Sep. 2007, pp. 1376–1379. [21] M. Kintner-Meyer and R. Conant, “Opportunities of wireless sensors and controls for building operation,” Eng. J., vol. 102, no. 5, pp. 27–48, 2005. [22] P. Gibbons, B. Karp, Y. Ke, S. Nath, and S. Seshan, “Irisnet: An architecture for a worldwide sensor web,” in IEEE Pervasive Comput.. Piscataway, NJ: IEEE Press, 2003, pp. 22–33. [23] J. King, R. Bose, H. Yang, S. Pickles, and A. Helal, “Atlas: A service-oriented sensor platform, hardware and middleware to enable programmable pervasive services,” in Proc. 31st IEEE Conf. Local Comput. Netw. (LCN), Nov. 2006, pp. 630–638. [24] M. Kushwaha, I. Amundson, X. Koutsoukos, S. Neema, and J. Sztipanovits, “Oasis: A programming framework for service-oriented sensor networks,” in Proc. 2nd IEEE Int. Conf. Commun. Syst. Softw. Middleware (COMSWARE), Jan. 2007, pp. 7–12. [25] X. Chu, T. Kobialka, B. Durnota, and R. Buyya, “Open sensor web architecture: Core services,” in Proc. 4th Int. Conf. Intell. Sens. Inf. Process. (ICISIP), Dec. 2006, pp. 98–103. [26] T. Ta, N. Y. Othman, R. H. Glitho, and F. Khendek, “Using Web services for bridging end-user applications and wireless sensor networks,” in Proc. 11th IEEE Symp. Comput. Commun. (ISCC), Jun. 2006, pp. 347–352. [27] D. Moodley and I. Simonis, “A new architecture for the sensor web: The SWAP framework,” in Proc. 5th Int. Semantic Web Conf. (ISWC), Nov. 2006, vol. LNCS 4273. [28] M. Kintner-Meyer and M. R. Brambley, “Are wireless sensors and controls ready for the building automation industry?,” presented at the Sel. Case Studies Technol. Development Activities, World Energy Eng. Congr. (WEEC), Atlanta, GA, 2006.

511

[29] W3C Consortium, “W3C group web services activity,” 2007 [Online]. Available: http://www.w3.org/2002/ws/ [30] European Commission Project—I3CON, “Reference model and specification of the sensor networking architecture in the BS architecture,” I3CON Project Deliverable D3.4-1F, 2007.. [31] ASHRE Standards Committee, “BACnet—A data communication protocol for building automation and control networks,” 2004. [Online]. Available: http://www.bacnet.org/ [32] Open Geospatial Consortium, Inc., Standards Organization, “Official Homepage,” 2007. [Online]. Available: http://www.opengeospatial.org/, [33] M. Botts, A. Robin, J. Davidson, and I. Simonis, “OpenGIS ® sensor web enablement architecture,” Open Geospatial Consortium, Inc., 2006. [34] D. Liu and N. Peng, Security for Wireless Sensor Networks, ser. Adv. Inf. Security. New York: Springer, 2007, vol. 28. [35] O. Wang, Y. Zhu, and L. Cheng, “Reprogramming wireless sensor networks: Challenges and approaches,” IEEE Netw., vol. 20, no. 3, pp. 48–55, May-Jun. 2006. [36] J. Polastre, J. Hill, and D. Culler, “Versatile low power media access for wireless sensor networks,” in Proc. 2nd ACM SenSys Conf., Baltimore, MD, Nov. 2004, pp. 95–107. [37] W. Ye, J. Heidemann, and D. Estrin, “Medium access control with coordinated, adaptive sleeping for wireless sensor networks,” IEEE/ACM Trans. Netw., vol. 12, no. 6, pp. 493–506, Jun. 2004. [38] T. van Dam and K. Langendoen, “An adaptive energy-efficient mac protocol for wireless sensor networks,” in Proc. 1st ACM SenSys Conf., Los Angeles, CA, Nov. 2003, pp. 171–180. [39] B. Murray, T. Baugé, R. Egan, C. Tan, and C. Yong, “Dynamic duty cycle control with path and zone management in wireless sensor networks,” presented at the IEEE Int. Wirel. Commun. Mobile Comput. Conf., Crete, Greece, Aug. 2008. [40] National Building Information Model Standard, , Sep. 2007. [Online]. Available: http://www.facilityinformationcouncil.org/bim/ [41] T. R. T. Fielding, “Architectural styles and the design of networkbased software architectures,” Representational State Transfer (REST), 2007. [Online]. Available: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm [42] W3C Consortium, “W3C SOAP 1.2 specification,” 2007. [Online]. Available: http://www.w3.org/TR/soap12-part1/ [43] C. Pautasso, O. Zimmermann, and F. Leymann, “Restful Web services vs. “Big” Web services: Making the right architectural decision,” in Proc. ACM 17th Int. Conf. World Wide Web (WWW), Beijing, China, Apr. 2008. [44] W. Landre and H. Wesenberg, “REST versus SOAP as architectural style for web services,” presented at the ACM SIGPLAN Int. Conf. Object-Oriented Program., Syst., Lang. Appl., Montreal, QC, Canada, Oct. 2007.

Apostolos Malatras received the Diploma in computer science from the University of Piraeus, Piraeus, Greece, the M.Sc. degree in information systems from the Athens University of Economics and Business, Athens, Greece, and the Ph.D. degree in networking from the University of Surrey, Surrey, U.K. He is a Senior Research Engineer with Thales Research and Technology, Berkshire, U.K., where he works on service-oriented architectures and wireless sensor networks. Prior to this position, he was a PostDoctoral Researcher with the Centre for Communication Systems Research, Department of Electronic Engineering, University of Surrey, where he was an active member of the Networks Research Group. He is the author and coauthor of more than 20 research papers. His research interests focus on context awareness, network management, mobile ad hoc networks, service oriented architectures wireless sensor networks, and communications middleware.


512


Abolghasem (Hamid) Asgari (M’06) received the B.Sc. degree from Dr. Beheshti University, Tehran, Iran, the M.Sc. (Hons) degree from the University of Auckland, Auckland, New Zealand, both in computer science, and the Ph.D. degree in electronic engineering (ATM networks) from University of Wales, Swansea, Wales, in 1997. He was with Iran Telecomunications Research Center (ITRC) from 1986 to 1990. He joined Thales (formerly Racal) Research and Technology, Berkshire, U.K., in 1996, where he is with Security and Communication Systems Division as a Chief Engineer specializing in the data communication systems/networks. He has been involved in design and analysis of integrated services and network architectures. He has actively participated in a number of EC projects including IST- TEQUILA, MESCAL, ENTHRONE, VISNET, and NMP- I3CON projects. His main research interests include network QoS management and monitoring, network performance evaluation, traffic engineering, service management, and wireless sensor networking. He has published more than 40 papers in these areas.

Timothy Baugé received the Diplôme d’Ingénieur from Ecole Nationale Supérieure de Physique de Marseille (now Centrale Marseille), Marseille, France, in 1997. He joined Thales Research and Technology, Berkshire, U.K., in 1998, and is now an Assistant Chief Engineer with the Networks and Security Group. His current research focuses on wireless sensor networks, with specific interest in their security, management, and integration into the Future Internet. He has been involved in a number of European Commission projects including e-sense, Sensei, and I3CON. Mr. Baugé is a member of FEANI, CNISF, and the IET.
