2 Application Domain............................... ........................................................................................42.1 System Architecture..............................................................................................................42.2 ZigBee Stack.........................................................................................................................52.3 Application Profile and ZigBee Cluster Library (ZCL)...........................................................6
3 Problem Description.............................. ........................................................................................7
4 Use Cases........................................ ...............................................................................................74.1 ZigBee Device Control by locally installed OSGi applications..............................................74.2 ZigBee Device Control through USB Dongle........................................................................74.3 ZigBee Device Control through standard ZigBee Gateway Devices....................................74.4 ZigBee Gateway with IP networks........................................................................................84.5 Network Refreshment............................................................................................................8
6 Document Support................................. ........................................................................................96.1 References............................................................................................................................96.2 Author’s Address...................................................................................................................96.3 End of Document...................................................................................................................10
0.2 Terminology and Document ConventionsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in 6.1.
ZigBee is a standard wireless communication protocol designed for low-cost and low-power devices by ZigBee Alliance. One of the main target areas for ZigBee is Home Automation. In fact ZigBee is widely supported by various types of devices such as smart meters, lights and many kinds of sensors in the residential area. Some OSGi applications need to communicate with those ZigBee devices. However there is no standard way of communicating with the ZigBee devices for OSGi applications. This RFP describes needs and requirements of ZigBee API on OSGi.
2.1 System ArchitectureWhen installing a new ZigBee network into a residential network with a home gateway, there are 2 options. One is to add ZigBee communication capability to your home gateway with an additional hardware such as a USB device called "dongle". The other one is to replace the current home gateway with one which has ZigBee communication capability. In the both cases OSGi applications call the ZigBee driver API to communicate with the ZigBee devices as shown in Figure 1.
The ZigBee specification defines three types of ZigBee devices: ZigBee Coordinator (ZC), ZigBee Router (ZR) and ZigBee End Device (ZED). In the above case the ZigBee hardware works as the ZigBee Coordinator and the other ZigBee device are attached to the ZigBee network as ZigBee End Device or ZigBee Router.
– ZigBee Coordinator (ZC) is responsible for managing a ZigBee network and ZigBee devices on the network. One ZigBee Coordinator is in each ZigBee network.
– ZigBee Router (ZR) is capable of extending a ZigBee network by relaying messages from other ZigBee devices.
– ZigBee End Device (ZED) has functionality to communicate with either ZigBee
Figure 1: Communication with ZigBee devices through a ZigBee driver
RFP 142- ZigBee API Page 6 of 12
2012-07-20Coordinator or ZigBee Router.
2.2 ZigBee StackThe ZigBee stack is shown in Figure 2. The two bottom layers, the PHY layer and the MAC layer, are defined by IEEE802.15.4 standard. The ZigBee standard only defines network (NWK) layer, application (APL) layer and security layer on top of it. The NWK layer is responsible for managing the network formation and routing. The APL layer hosts application objects developed by manufactures. The security service provider is responsible for encryption and authentication.
The application layer consists of three functional blocks: application support sub-layer, ZigBee Device Object (ZDO) and application framework. The application support sub-layer provides the transmission capability of data and management messages. The ZDO provides common functionality used by all applications. The application framework is the environment where application objects are hosted to control and manage the protocol layers.
There are two interfaces available to applications: APSDE-SAP and ZDO public interface. The APSDE-SAP provides data transmission functionality between ZigBee devices. The ZDO public interface provides applications with management functionality such as device discovery, service discovery and network management.
2.3 Application Profile and ZigBee Cluster Library ( ZCL)The application profiles allow interoperability between products developed by different vendors for a specific application. For example, in a light control scenario, switches developed by a vendor can turn on and turn off lights developed by another vendor if the both vendors take the same application profile. The ZigBee Alliance has defined nine public application profiles such as Home Automation (HA) and ZigBee Smart Energy (ZSE).
An application profile defines its application domain, a list of specific devices supported in the profile and a list of clusters supported by the devices. A cluster is a relevant collection of commands and attributes which together define an interface to specific functionality. The clusters used in public application profiles are defined in the ZigBee Cluster Library (ZCL) specification. The ZCL specification defines a number of clusters and categories them into groups by their functionality.
As described in the section 2, OSGi applications which communicate with ZigBee devices are supposed to call the API of the driver provided by the vendor. The API is proprietary and different vendor by vendor since it is not standardized in the ZigBee specification. This causes the following problems:
1) Application developers need to know which vendor's ZigBee hardware is used with the target residential gateway in advance before developing their applications.
2) An application which was developed for a certain environment may not work in other environments.
Those problems make it difficult for third parties to develop portable OSGi applications communicating with ZigBee devices.
The standard ZigBee API demanded in this RFP would give developers a unified way of communicating with ZigBee devices. The developers do not need to care the proprietary API of drivers but simply use the standard one.
4 Use Cases
4.1 ZigBee Device Control by locally installed OSGi applicationsLocally installed OSGi applications interacting with ZigBee devices will ideally use the same driver. The driver initializes the available ZigBee local hosts – e.g., USB dongles, built-in chips, ZigBee Gateways – and allows to do management operations on these hosts such as network selection and device discovery. The driver also registers Device services which provide OSGi applications with an interface for communication with the discovered ZigBee devices. The user controls the ZigBee devices on the OSGi application.
4.2 ZigBee Device Control through USB DongleA user who would like to control ZigBee devices in home attaches a ZigBee USB dongle to the residential gateway. OSGi Device Manager running on the residential gateway identifies the dongle and installs a suitable driver for it. The driver enables locally installed applications to
2012-07-20control and manage ZigBee devices like in the above use case.
4.3 ZigBee Device Control through standard ZigBee Ga teway DevicesThe ACME company has to develop a ZigBee application based on the OSGi ZigBee Device Service specification. The application is developed for one hospital; it has to control a large sensor network with devices belonging to home building and healthcare profiles. The company installs a sensor network prototype for testing the application before the real deployment. Two developer teams, belonging to different departments, collaborate to this project. The prototype network is not reachable from all the ACME's buildings and not all the developers have got a USB ZigBee dongle. The company includes in the network prototype one ZigBee Gateway Device (ZGD) acting as ZigBee Router device and connected to the IP network. In this way the two teams can configure the ZigBee Base Driver to work with either a ZigBee USB Dongle or a Zigbee Gateway Device. One or more ZGDs will be deployed in the hospital network to provide remote assistance and maintenance. Every ZGD is associated to a different ZigBee network.
4.4 ZigBee Gateway with IP networksSeveral Home Automation applications are composed of an application that is deployed in the Cloud and that communicate with ZigBee devices through a gateway. This gateway acts as a simple bridge between the Home ZigBee network and an IP network protocol, e.g., Web Services, RESTful protocols, UPnP.
4.5 Network RefreshmentThe ACME developers team provides remote assistance for end user terminal equipments based on the OSGi platform. A user experiences problems with some ZigBee devices which are not recognised, or properly discovered by the terminal. For instance, a ZigBee device working on batteries dies because of running out of electricity. In such a case there is an inconsistency between the state the OSGi platform has and actual one. The remote operator connects to the terminal, by means of a software agent interfaced with the ZigBee Base Driver API, forces the re-execution of a network scan and discovery of the available devices.
5 Requirements
R1: The solution MUST provide an API for data transmission supported by APSDE-SAP.
R2: The solution MUST provide a base driver interface as an OSGi service for management operations supported by ZDO: device and service discovery, security management, network
2012-07-20management, binding management, node management and group management.
R3: The solution should enable applications to trigger a re-scan of the network to refresh the registry with actual ZigBee device services.
R4: The solution MUST provide API for switching the type of the local ZigBee device among ZC, ZR and ZED.
R5: The solution MUST provide a mechanism which notifies OSGi applications of events occurred in the ZigBee network and devices.
R6: The solution MUST provide an installation capability of cluster libraries within OSGi service-oriented architecture.
R7: The solution MUST register a Device Service object representing each found ZigBee device into Service Registry and unregister the Device Service object when the ZigBee device is unavailable.
R8: The solution MAY define the driver provisioning process in accordance with the OSGi Device Access specification.
R9: The solution MUST be independent from the interface used to control the ZigBee network. The solution MUST likewise work with network controllers based on ZigBee built-in chips, ZigBee USB dongles and high level protocols offered by ZigBee Gateway Devices compliant with the ZigBee Alliance specification.
6 Document Support
6.1 References[1]. Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, RFC2119,
March 1997.
[2]. Software Requirements & Specifications. Michael Jackson. ISBN 0-201-87712-0
[3]. ZigBee Specification 2007, ZigBee Alliance, January 2008.
[4]. ZigBee Cluster Library Specification, ZigBee Alliance, May 2008.
![ZigBee Stack Profile: Platform restrictions for compliant ...read.pudn.com/.../3...ZigBee-Feature-Set-Profile.pdf · 11 [R2] ZigBee 04140r05, ZigBee Protocol Stack Settable Values](https://static.documents.pub/doc/80x56/5f183a7d6417c0751a61665e/zigbee-stack-profile-platform-restrictions-for-compliant-readpudncom3zigbee-feature-set-.jpg)
![ZigBee RF4CE Stack User Guide - NXP Semiconductors · 094945r00ZB ZigBee RF4CE Specification [ZigBee Alliance document] 094950r00ZB ZigBee RF4CE Device Type List [ZigBee Alliance](https://static.documents.pub/doc/80x56/5f168d2f412bb13bb1076764/zigbee-rf4ce-stack-user-guide-nxp-semiconductors-094945r00zb-zigbee-rf4ce-specification.jpg)
