4 de Ingles)
4 de Ingles)
A. Binding Management
This discussion describes a specific binding management scenario for this specific application. Of course,
each application will be different, but a range of binding command are available to facilitate many
different scenarios. The most significant benefit with tree routing is its simplicity and its limited use of
resources. By having a simple algorithm to determine whether an address is a child or a descendant of a
child, or elsewhere on the tree, any router can make a routing decision simply by looking at the
destination address. In these cases, a router simply decides to route a packet to one of its children or to
its parent. As a result, precious memory resources need not be used to store routing information.
Hence, very low-cost devices can be deployed without routing capability, but can still participate in any
ZigBee compliant network. Building on earlier discussions, this section describes a typical process for
developing a new application. Defining and implementing the application profile. The first step is to
define the application profile. As part of this exercise, an application profile, along with device
definitions are required to meet the specific requirements of the application. As mentioned in the
discussion on the ZigBee Cluster Library, where possible this library should be used to leverage existing
definitions and code available from the platform provider. These three binding commands, supported in
earlier releases of the ZigBee specification have been enhanced through the following additional
commands:
• Bind_Register, which allows devices to register with the binding cache and download all bindings
stored in the cache for that device.
• Replace_Device, which allow a new device (Y) to request that entries within the binding cache for an
old device (X) be replaced by the new device (Y).
• Backup_Bind_Table to backup the primary binding cache to the second binding cache, and to recover
the information from the secondary binding cache.
Starting in box (a), end devices are bound using some physical input (say, a button on each device and
the remote control). Using the End_Device_Bind command, these bindings populate the binding cache.
Is shows in Fig. 6. In box (b), the remote control then issues a Bind_Register command to download all
bindings for which it is the source device. This then allows the remote control to directly communicate
to other devices without communicating via the binding cache. Finally, in box (c), should the lighting
device fail, a replacement device would be substituted, and it would issue a Replace_Device notification
to the binding cache that the original lighting device should be replaced by the new lighting device. The
binding cache would then note that the remote control currently stores its own copy of its bindings for
source binding, and would then send a Replace_Device command to the remote control to have its local
copy of the binding replaced as well.
The industry’s most widespread solution for testing, analyzing, commissioning, and managing wireless
embedded networks such as IEEE 802.15.4 and ZigBee. Daintree’s SNA[18] extends traditional protocol
analysis with powerful visual network analysis including visualization of network topologies, routing and
application bindings, link quality and device states. In addition, the SNA provides multimode capture for
analysis of large and physically distributed networks, and measurements for analysis of system
performance. To significantly accelerate troubleshooting tasks, the SNA also provides ease-of-use
features such as filters based on visual objects, user-definable protocol stack and ZigBee profile
definitions using XML, comprehensive playback controls and breakpoints. Visualize tools is shows in Fig.
7. Visualize tools be comprehend device and network Monitor the network tools is show a in Fig. 8. Find
and examine devices using scanning and device discovery tools. Identify joined devices and the network
structure, represented using a variety of views. Automatically obtain device type and device state
information such as association permit. Discover networks, either passively without interfering with
network operation, or actively to determine the structure of live operating networks after network
formation. In Fig. 8, load an image, such as a floor plan, and then drag-and-drop devices to view the
network as it is physically laid out. Understand network behavior in a physical context, and redesign
network layout to improve performance. Most previous work on sensor placement deals with the
coverage issue by regular placement or deployment to better estimate unknown fields. Variance-based
approaches are used to estimate the field better by adopting an adaptive and incremental scheme to
find the next placement locations of high variance (or entropy). In this case, the variance is computed
based on the measurements by the currently placed sensors. Unlike previous research on sensor
placement, in our application, the user knows what the resultant light field should be like. Thus, our
system suggests sensor placement to verify if the intended light field is appropriately created. We
combine the two typical approaches: the regularity-based technique and the variance-based technique.
Following the definition of the application profile is of course, the development of the necessary code
for devices around these definitions. With standardization around the ZCP framework, development
tools will be increasingly available using standard description languages such as XML, as well as for
analysis and testing. This facilitates a single definition of the application profile that may propagate
through the entire development, test and commissioning tool chain.