GAL: a Gateway Abstraction Layer for fast application development in ZigBee Networks
Abstract This paper describes an abstraction layer (Gateway Abstraction Layer or GAL) for a ZigBee Gateway that enables fast development of different applications (e.g. elderly monitoring, energy management) by means of a simplified API. The main idea is to reduce the complexity during the application development phase, while maintaining flexibility. The GAL architecture is presented in the paper and the functional units of the system are described. A quantification of the benefit of using the GAL is also performed. Keywords: GAL, ZigBee, WSN, ZigBee Networks, gateway, software abstractions
1. Introduction A relevant role for the upcoming ZigBee services [1] is getting covered by the gateways, units able to interconnect the Wireless Sensor Network (WSN) world to IP based backend systems in order to manage and control the end-user applications. The importance of the gateway devices has been highlighted and described in papers like [2] and different products are approaching to the market (see [3]and [4]). The object of the paper is to present an abstraction layer for a ZigBee Gateway (Gateway Abstraction Layer or GAL) that enables fast development of different applications (e.g. elderly monitoring, energy management) using a simple API. The GAL architecture is presented in the paper and the functional units of the system are described as Discovery agent, Service Agent, Management Agent and TrustCenter Agent. The Agents have been introduced in order to simplify the development of an application by managing complex procedures related to the processing of ZigBee frames defined for network, device and service discovery. By using the GAL an application relying on a gateway could effectively run a discovery of the nodes in the networks, retrieve the list of available services and set up the communication with a specific device. In particular, the main idea behind the GAL is to enable the development of both local applications, installed
Claudio Pastrone Istituto Sup. M. Boella Via P.C. Boggio 61 Turin 10138– Italy Phone: + 39 011 2276612
[email protected]
on-board mobile or fixed terminals, and remote applications running on different hosts. The resulting middleware allows flexible and simultaneous access of multiple (local and remote) applications to the ZigBee Gateway: in this scenario, network management could be performed by a remote platform, while a local application could run directly on the terminal itself. In this paper, a comparison between direct access to ZigBee primitives and the use of GAL for running generic applications has been discussed: the comparison shows how the usage of an abstraction can reduce the number of application APIs, while maintaining the flexibility in the application development phase. In section 2 System Architecture is described, in section 3 GAL core functions are presented in details; while in section 4 the current implemented RPC interface is shown. In section 5 a performance analysis is carried out. Finally, section 6 presents the conclusions of the paper.
2. System Architecture The reference architecture for the development of the GAL is described in Figure 1. Remote application (running over a WSN platform) Stub REST
Local Application Local Application n 1 Stub REST Stub REST
REST RPC GAL GAL core i/f
Gateway
Claudio Borean Telecom Italia Lab Via Reiss Romoli 274 Turin 10148-Italy Phone: +39 011 2285570 claudio.borean@telecomitali a.it
ZigBee Network
Figure 1- System architecture
The nodes participating in a ZigBee mesh network, as widely known by people developing applications with wireless sensor network technologies, work in an ad-hoc configuration independently from a centralized point that can be connected to a distribution network (e.g. IP network). The introduction of a proper gateway, able to connect to the ZigBee network and capable of configuring the devices in order to get and set the proper frame into the network and run the required tasks, becomes then a key element for the overall architecture and an effective deployment of the application. Another key element for the gateway device is the independency from the specific application running in the ZigBee network itself: a general purpose gateway exposing a generic interface such as the one described by this paper, enables the usage of a predefined layer for the interconnection towards local and remote applications. The resulting abstraction layer does not need to be changed according to the application itself. Moreover, a relevant requirement for an application using the GAL is the possibility to be resident on the gateway itself or remote on a server, that is beyond the distribution network of a Telco operator. Nevertheless, the Telco operator could build the application itself on the top of a WSN management platform. The local application could be very effective whenever a Gateway with sufficient resources is used, because it can provide the final user with a simple GUI and immediate feedbacks about the application. As described in Figure 1, the system comprises the following building blocks: o ZigBee network: it is composed by WSN nodes that run specific tasks for a cooperative application; o Low-layer interface: provides an adapter to the network processor used to enable the gateway to ZigBee; o GAL core: it provides the gateway state machine; o GAL: it exports to the application the functionalities implemented by the GAL core; o RPC Layer: it represents the layer exposed to the applications (local and remote) and operated, in current the implementation, through the use of REST web service; however, generic RPC mechanism could be used; o Local applications: use the GAL for running the application and delegate the WSN platform the burden of the WSN management; o Remote applications: the remote applications are typically built on the top of a WSN
platform in order to leverage on the functionalities managed by this unit (e.g. the management of the ZigBee network, the WSN topology monitoring, etc.). In the reference architecture, both local applications and the WSN platform access the functionalities exposed by the GAL by using a REST stub which acts as a library and enables the usage of the features implemented by the GAL core.
3. GAL core functions In this section, the proposed abstraction layer and its core functions are presented in details. In addition, some implementation aspects are briefly introduced. The logical architecture of the GAL considered in this paper is described in Figure 2 and is basically made of four main building blocks. o Low-layer interface. In fact, it provides the low level interface between the ZigBee Gateway and the so-called ZigBee Network processor i.e. a device that integrates an IEEE 802.15.4 compliant radio transceiver and has built-in ZigBee networking capabilities (i.e. the protocol stack); o GAL Core. This component logically groups together different APS-level ZigBee commands to define high level macro-functions and exposes them to the RPC layer by means of the GAL interface. In particular, GAL core is organized into four agents i.e. TrustCenter Agent, Discovery Agent, Management Agent and Service Agent: these are software modules implementing separate logical functions and actually providing the Gateway state machine; o GAL. It represents the real abstraction layer and defines the programming interface used to expose GAL core functionalities to higher software layers; o RPC layer. The objective of this component is to allow local or remote applications to invoke the macro-functions exposed by the GAL interface. To this aim, different technologies can be used, e.g. REST, SOAP... In the present paper, REST is considered. Focusing on the GAL core component, four main agents have been defined: TrustCenter Agent, Discovery Agent, Management Agent and Service Agent. The TrustCenter Agent provides the capability for an external authorized management application (e.g. the WSN platform) to control ZigBee Trust Center operations. In particular, it is possible to define access control policies to manage the joining of new devices to the ZigBee network, dynamically exclude a certain node from the network and provide key
management capabilities (e.g. key setup and renewal). It is worth notice that in the current implementation the TrustCenter Agent can be enabled only in case the ZigBee Gateway is colocated with the network coordinator; otherwise, the TrustCenter Agent is disabled. The Discovery Agent provides the functionality to discover devices in the ZigBee network and gather some basic relevant information, i.e. node descriptor and power descriptor. The main idea is to simplify the discovery process for local or remote applications by avoiding the burden of managing multiple requests and responses needed to accomplish discovery task. The Management Agent provides management functionalities, focusing on the management of the binding table, the ability to ping a specific node in the network and ZigBee Network Management Client Services (see [5]). The Service Agent basically deals with the services that actually run the WSN application. Firstly, it provides the ability to discover the services offered in the ZigBee PAN. Secondly, it enables local or remote applications to dynamically create endpoints on the ZigBee Gateway, also associating the desired simple descriptor, and use them to send/receive application messages. Based on the logical architecture presented in this section, a first implementation of the ZigBee Gateway has been developed on an ARM-based video telephone using C++ technology. In particular, the observer design pattern has been used to allow an asynchronous interaction between the different modules of the GAL core. For example, the agents are able to register themselves to receive a notification from the low-layer interface in case a specific kind of ZigBee message is received. In the following sections, further details will be provided on Discovery Agent and Service Agent. SHTTPD
libcurl HTTPClient
RPC
HTTPServer
REST Server
REST Client
REST Broker
Generic RPC layer interface
Core
Gateway Abstraction Layer
DiscoveryAgent
i/f
registerListener
ServiceAgent
TrustCenterAgent
AgentErrorMessages
MngmtAgent
callback
Interface ZigBee Network Processor
Figure 2- GAL Core building blocks
Discovery Agent Discovery Agent basically provides the capability to perform a device discovery for the ZigBee network of interest and retrieve some basic information from each discovered node. In particular, the agent allows to get the following details for each node: o Node address (short and extended); o Topology-related information i.e. it should be possible to recursively identify the fathersons links; o Node descriptor; o Power descriptor. As far as device discovery is concerned, two main modes are exposed: inquiry-mode and announcements-mode. The inquiry-mode uses unicast addressed IEEE_addr_req commands to discover the devices in the network and obtain topology-related information. On receipt of an IEEE_addr_req message (with the field RequestType set to extended response), awake ZigBee End Devices respond only with its address, while a ZigBee Coordinator or a Router replies by transmitting its own address and the addresses of each associated child devices. Leveraging on this function, in the inquiry-mode, a first request is sent to the Coordinator and then recursively to the associated child devices till all nodes are discovered. It is worth observing that the inquiry process duration is not known a priori and depends on several factors: the number of nodes in the network, the availability in the network of Primary Discovery Cache devices for sleeping ZigBee End Devices, etc. Moreover, node failures could prevent the completion of the procedure. To overcome this issue, the Discovery Agent exposes the capability to stop the discovery process whenever desired. In the announcement-mode, the Discovery Agent is able to intercept incoming Device_annce messages to infer that new devices have joined or re-joined the network and obtain their short and extended address. By this way, once a first inquiry-mode device discovery has been performed, the announcementsmode can be used to constantly monitor the actual network status. Moreover, the Discovery Agent can send Node_Desc_req and Power_Desc_req commands in order to retrieve the Node Descriptor and the Power Descriptor of a remote device respectively. The Discovery Agent also supports a synchronous discovery called “SuperDiscovery” that, in fact, performs an inquiry mode device discovery and uses Node_Desc_req and Power_Desc_req commands to retrieve relevant information from each single discovered node. In this case, the simplification introduced by the agent is evident.
Since neither the receipt of Node_Desc_rsp or Power_Desc_rsp messages in response to relevant inquiries, nor the successful completion of the SuperDiscovery procedure are certain, the Discovery Agent uses timeout mechanisms. Finally, it is worth highlighting that the results of the Discovery Agent requests are continuously buffered and made available for the RPC layer to be accessed by means of the GAL interface. Service Agent The Service Agent focuses on services. In particular, two main classes of functionalities have been taken into account: o service discovery; o service management and data communication. Discovery functionalities basically refer to the ability of discovering the services offered in the ZigBee PAN: o retrieve the list of active endpoints with associated simple descriptors from a remote ZigBee device. In order to perform this task, unicast Active_EP_req commands are sent to the device of interest; o retrieve the simple descriptor related to a specific endpoint defined in a remote ZigBee device: Simple_Desc_req commands are used; o discover remote devices supporting a specific simple descriptor. Match_Desc_req commands are broadcasted to the ZigBee network. The devices containing at least one simple descriptor matching the criterion included in the request will generate Match_Desc_rsp messages. Some shortcut methods have been defined in order to reduce the number of messages directly managed by the upper layers (e.g. retrieve all the simple descriptors relating a specific node, etc). Moreover, the Service Agent allows to dynamically allocate new endpoints and relevant simple descriptors on the node acting as ZigBee Gateway: all data stored in a local service table. This capability is then exposed by the RPC layer to local or remote applications. Thanks to this feature, applications are able to require the allocation of a new endpoint on the Gateway by specifying the relevant simple descriptor, and then use such an endpoint to communicate with other nodes of the network. In more details, it is possible to transmit messages that are intended to be already formatted (by the application) as ZigBee standard application message, using the ZigBee Cluster library. In fact, this data communication feature provides support for
advanced management applications including the remote device configuration (e.g. configuring startup parameters in case of ZigBee commissioning cluster). It is worth noting that the messages can be sent to the node of interest by simply specifying the relevant IEEE address: the Service Agent will be in charge of translating the IEEE address into a short address (in order to enable energy efficiency by transmitting short packets in the network) or setting the addressing mode APSDE-DATA.request parameter to the value that enables the use of 64-bit extended address. Data from the network, directed to an existing endpoint allocated in the Gateway, is processed by the Service Agent and eventually forwarded, by means of the RPC layer, to the application that created the endpoint. In addition, Service Agent provides support for incoming Match_Desc_req. When that type of message is received, the agent applies the match criteria to each simple descriptor contained in the local service table. If one or more matches are produced, proper Match_Desc_rsp will be automatically generated.
4. RPC Interface: REST implementation The RPC layer allows multiple applications to exploit the GAL core macro-functions exposed by the GAL interface, also enabling an inter-process communication. This layer, in fact, decouples application logic from low level ZigBee network details enabling faster and simpler development of ZigBee-based services. Different systems can be used to define this exposure layer, including web services. To select the most appropriate technology, functional and non-functional requirements have been deeply investigated. Therefore, we propose to use web services as the most suitable solution in terms of interoperability, transparency and flexibility. Web services allow the definition of web APIs that can be made available over a generic communication network. Moreover, the distributed nature of this class of function call interfaces avoids defining technology constraints for local / remote applications. While several dialects of web services can be considered, e.g. SOAP, REST, XML-RPC, etc., REST has been chosen for the actual implementation. REST basically refers to an architectural style for defining simple and light interfaces in which system functionalities are exposed as resources. In addition, specific methods for accessing and manipulating the state of those resources are provided. In our case, HTTP protocol is used along with XML messages for flexible data exchange. In order to operate
resource manipulation, CRUD methods, i.e. Create, Read, Update and Delete are considered and associated to HTTP methods POST, GET, PUT and DELETE. In more details, ZigBee network devices, relevant services and communication capabilities have been mapped to resources being defined by two sets of information: o URI to unambiguously locate the resource of interest; o A description concerning the way the resource can be manipulated and retrieved. The association between the action on specific resources and the relevant GAL core functionalities (i.e. agents’ methods) has been used to make more explicit the meaning of the resulting API. In particular, for each resource the following data have to be specified: o HTTP methods used; o query strings that are used to pass parameters and characterize the action carried out on a specific resource; o the relevant GAL core methods invoked; o the XML message used for the specific interaction (an XML schema has been used to define the format of exchanged messages). An example is provided below (refer to Table 1). URI [rootURI] /wsnnodes
HTTP method
GET
Query string
Action
XML message
?mode= nquiry-on
Start an inquirymode device discovery (refer to Discovery Agent)
Refer to element Info defined in the XML schema
Table 1 – REST resource description (example)
It is worth noting that Gateway related REST resources are created and exposed only when actually available. For example, each node in the ZigBee network is identified as a REST resource and can be inquired in order to obtain relevant information; however, this resource is dynamically published only when the ZigBee device has been actually discovered (as a result of a device discovery process). All the above description basically refers to REST server functionalities. However, the RPC layer can be also used by the Gateway as a REST client notifying events to registered local/remote applications. The considered REST- RPC layer is made of the following components: o REST Server. It implements the server capabilities and deals with the dynamic allocation of REST resources; o REST client. It is used for asynchronous notification to registered applications;
REST broker. It manages the interaction between REST Server and Client and the GAL core component, by means of the GAL interface. The actual implementation has been developed using open source web server SHTTPD [6] and libcurl [7] free HTTP client library. It is important to highlight that multiple applications (e.g. WSN platform and a local application) can simultaneously access the gateway and control it through the exposed RPC layer. o
5. Fast application development using GAL features The main objective of the proposed GAL unit is to simplify the development of the applications (local or remote) by using the gateway. In order to better understand the reduction of functions to be managed by the application to effectively run the service, a comparison of the calls to be operated without using the GAL has been performed. In Table 2, a list of commands and functionalities supported by the GAL or directly by the application is described. Two sets of commands are reported: one related to the discovery functionalities (methods to find nodes or WSN applications the nodes need to communicate with) and the other set related to the application that is actually running on the gateway or in the WSN network. Besides the commands operated to find the devices to talk to, it is important to consider also the responses the ZigBee Gateway device shall provide to other inquiring nodes in the ZigBee network (e.g. responses to service discovery operated by devices that need to find complementary functionalities supported by other nodes in the network). # of Commands # of commands Behaviour not using GAL using GAL Macro Discovery (Inquiry of IEEE addresses) Discovery of all descriptors GET Node Descriptor GET Power Descriptor Discovery GET Service Descriptor functions Active EP Discovery for all nodes Simple Descriptor request for all nodes Device Announcement management TOT Match Descriptor Reponse Application functions
Simple Descriptor response MessageRX/TX TOT
N
3*N N N N N N*EP
N
1 Discover all node addresses
1
Discover addresses, node descriptor, power descriptor
N Get node descriptor N Get power descriptor N Get simple descriptor Active endpoint request for 1 all nodes Simple desc request for 1 each endpoint of all nodes Manage device 0 announcements (prevent addresses changes issues)
9N+N*EP
3N+4
N
1
In case of GAL, one additional subscription of the Simple Descriptor supported by the gateway is required
M*EP
1
In case of GAL, one additional subscription of the Simple Descriptor supported by the gateway is required
1 N+M+EP+1
1 Message send/receive 3
Table 2 – comparison of primitives using vs not using the GAL
N+M+EP+1 (1) While using the GAL the number dramatically is reduced to 3. This is due to the automatic replies that the GAL operates after a subscription of specific ZigBee simple descriptors which in case of no-GAL scenario needs to be managed directly by the application itself. The reduction of commands to be managed by an application using the GAL is shown in Figure 3, where it is highlighted how the benefit of the GAL grows with the number of nodes in the ZigBee network as expected, even if it becomes of interest with tens of nodes already. Application primitives using GAL 300
Number of primitives
250
Application w/o GAL Application with GAL
200
150
100
50
0 5
10
20
40
80
Number of nodes
Figure 3 -Application Primitives using GAL
If we consider the number of commands used for discovery purposes (e.g. discover all the nodes in the network with their respective extended and short addresses) the number of commands in case of noGAL solution is the one reported in (2): 9N+N*EP (2) While using the GAL, it reduces to the (3): 3N+4 (3) This gain is primarily due to the implementation inside the GAL of macro discovery functionalities: the GAL directly manages the ZigBee multiple requests and responses needed to fulfil global discovery functions. The reduction of the number of
commands required for discovery purposes using the GAL is reported in Figure 4.
Discovery primitives using GAL 1000 900
Number of primitives
Considering N the number of devices in the ZigBee network, EP the average number of endpoints supported by the nodes and M the effective number of nodes that could support the requested services (M is equal to Perc*N where Perc is the percentage of nodes supporting the requested services in the network, i.e. replying to a service inquiry), the number of application commands to be managed by an application not using the GAL will be equal to (1):
800
Discovery w/o GAL
700
Discovery with GAL
600 500 400 300 200 100 0 5
10
20
40
80
Number of nodes
Figure 4 - Discovery Primitives using GAL
6. CONCLUSIONS This paper has described an abstraction layer (ZigBee Gateway Abstraction Layer or GAL) defined in order to enable a simplified development of applications using a ZigBee Gateway. It has been discussed how both local (developed on board of the Gateway itself) and remote applications (developed on a remote server or on top of a WSN management platform) could take advantage of using the GAL architecture. The GAL enables fast development of different applications (e.g. elderly monitoring, energy management) using a set of APIs that reduces the complexity of the application development by managing directly several commands required for device discovery, service discovery and the actual application. Moreover the GAL architecture has been presented and the functional units of the system have been described with particular reference to the core functionalities. Data describing the reduction of complexity from an application developer standpoint, when using the GAL, have been also presented and discussed.
4. REFERENCES [1]. ZigBee Alliance official web http://www.ZigBee.org/en/index.asp
5. AUTHORS site:
[2]. Kawamoto, R. Emori, T. Sakata, S. Furuhata, K. Yuasa, K. Hara, S. Alpha Systems Inc., Tokyo, DLNA-ZigBee Gateway Architecture and Energy Efficient Sensor Control for Home Networks, Mobile and Wireless Communications Summit, 2007. 16th IST [3]. Exegin, http://www.exegin.com [4]. Alektrona, http://www.alektrona.com/ [5]. ZigBee Specification, 2007 [6]. SHTTPD website, http://shttpd.sourceforge.net/. [7]. cURL and libcurl website, http://curl.haxx.se/.
Claudio Borean has worked as a Network Researcher for "Access Network and Terminal" division of Telecom Italia Lab, the Telecom Italia research center. He received an Electronic Engineering Master Degree from Politecnico di Torino in 2000, and a "Master in Telecomunication" as IP Network Architect from ISGRR institute. He worked in several research projects about Next Generation Wireless LAN, RFID technology and services evolution and Wireless Microdevices networks. He is currently involved in ZigBee networks studies for new service implementation. He is the Chairman of Telecom Applications group in ZigBee. Claudio Pastrone graduated from the Politecnico di Torino in Telecommunications Engineering in September 2002. In 2003, he won an annual research grant from CNIT to study communication networks (mobility and security issues in wireless networks, authentication protocols). In autumn 2004, he joined the Electronics Department of Politecnico di Torino, where he pursued his previous activity. Since February 2005 he has been working as a researcher with the Istituto Superiore Mario Boella on wireless sensor networks for security, e-health and ITS applications such as traffic monitoring.
