4.6 MANUAL DE PROCEDIMIENTOS ADMINISTRATIVOS DE LA
4.6.1 Funciones y atribuciones de la Dirección de Obras Públicas
5.1.1 Application Endpoints and Data Transfer
In ZigBee PRO standard [6] data exchange on the application layer requires use of so called application endpoints. Endpoints correspond to application objects, which are logically embraced into an application framework and serve as source and destination points for application data transfer in ZigBee networks. Each endpoint is identified with an endpoint ID, which can take values in a range from 1 to 240. Endpoint 0 is reserved for ZigBee Device Object (ZDO). A node cannot participate in application data exchange until it registers at least one endpoint. If a node wants to deliver data to a remote node, it is not sufficient to know the remote node’s network address. The source node must specify a destination endpoint, too. Figure 5-1illustrates this concept.
Figure 5-1. Data Exchange in ZigBee Applications
Figure 5-1also shows that actual data exchange on application endpoints is performed within so called clusters that specify standard communication interface (commands, attributes and behavior) for a particular functionality (for example Time, On/Off control, Temperature). The set of clusters supported by an endpoint may be regarded as the description of endpoint functionality. More information on cluster is given in Section5.1.2.
Each application endpoint is fully characterized by following parameters: endpoint ID, supported application profile (see Section 5.1.2.1), device ID (see Section 5.1.2.1), device version and lists of supported client and server clusters. This information composes a simple descriptor for the endpoint. The stack uses the simple descriptor to filter incoming frames. The indication of data reception is sent to the destination endpoint callback functions only when the message fits the profile and cluster information contained in the simple descriptor of the target endpoint. A simple descriptor is also employed in service discovery procedures, which allow a node to search for devices with particular profile and cluster configurations as described in Section 4.3.
A physical device is not restricted to use a single endpoint for all data interactions and may register several endpoints. This might be particularly useful if a physical device operates as two or more different logical devices. In this case clusters specific for logical devices may be registered on separate endpoints, while common clusters may be supported by a shared endpoint.
Detailed description and an example of endpoint registration are given in Section 5.3.
5.1.2 Clusters
A cluster is a collection of commands and attributes that together form a communication interface to specific functionality; for example, time, level control, metering etc. Commands represent certain actions performed by the cluster, and attributes are cluster parameters manipulated by the application. ZigBee Cluster Library (ZCL) specification [6] provides cluster definitions that can be used by different application profiles.
Communication within a cluster involves two sides: a client and a server. Typically, the server stores and maintains attributes, and the client sends requests to manipulate attributes on the server. Some clusters allow clients to modify attributes, while for others this is possible only for the device holding the attribute. Such attributes are called read-only. There is also a class of attributes that are stored on clients. Such attributes, which may be regarded to as local settings, are called client attributes. A device holding an attribute has full access to it and is able to write, read, and report the attribute value when needed. Reporting an attribute means sending the attribute’s value to remote devices.
Figure 5-2shows example of a cluster: a meter device serves as a client side of the Time cluster, while ESP supports the server-side Time cluster. The meter sends read attributes command (a general cluster command) to the ESP to obtain the Time attribute (holding the current time value) and receives a read attributes response command, containing the value of the Time attribute.
Figure 5-2. Interaction between ESP and Meter over the Time Cluster
How to use ZCL clusters, attributes, and commands in BitCloud application is described in Sections 5.2 to 5.6.
5.1.2.1 ZigBee Application Profiles
ZigBee application profiles describe specific application domains by defining functional blocks for all types of logical devices occurring in the domains. Public profiles released by ZigBee Alliance include Home Automation, LightLink, Smart Energy and others (see [9]).
Specification of a public ZigBee profile defines types of devices that can operate in the network. For each device type it provides the list of required clusters and the list of optional clusters, thus defining the device type. On the application level a profile is identified with its profile ID number.
Data exchange requires that communicating endpoints are assigned to the same profile. An application profile identifier is a mandatory identifier for every registered endpoint.
Figure 5-3. ZigBee Cluster Library and Public Profiles ZigBee Cluster Library
A B C D E F
Profile A Device 1B C
Device 2A D
F
Profile B Device 3 Device 4A E
C
F
B C F
Vendors should follow public profiles’ specifications in order to certify devices they manufacture and keep them interoperable with device from other vendors. However, any vendor may extend the profile with its own, manufacturer- specific clusters, attributes or commands as described in Appendix A.
5.1.3 Packet Routing
One of the main purposes of forming a network is to be able to send data to devices that cannot be reached by a signal directly. Nodes joined to the network can transmit a data frame to each other until it reaches the destination, thus allowing the message to cross large distances. Routing means the process of building an optimal path through several nodes in the network to the destination node. Without applying routing, a node would not be able to send data over more than a single hop; that is, only to devices that can directly “hear” the signal sent by the node.
In Atmel BitCloud applications, the stack is fully responsible for establishing and managing routes. These procedures are absolutely transparent to the application. Information obtained during route discovery is stored in internal structures such as the route table and route discovery table, and reused whenever possible.
The length of a route (the maximum number of hops in one direction) equals 2*CS_MAX_NETWORK_DEPTH.
5.1.4 Delivery Mode by Destination Address
After an endpoint is registered, the application can use it to send data to endpoints on remote nodes using the
corresponding ZCL API functions (see Sections 5.5 and 5.6). Depending on the destination address configuration data frames can be sent in unicast, broadcast, or multicast ways: