ZigBee UPnP

Design and implementation of ZigBee to UPnP bridge

Hang-Lin Wang Prof. Fu-Chiung Cheng

Thesis for Master of Science Computer Electronics Communication Engineering TaTung University
July 2006

ACKNOWLEDGMENT


ZigBee ZigBee ZigBee () ZigBee UPnP(Universal Plug and Play) ZigBee UPnP ZigBee UPnP Bridge ZigBee UPnP ZigBee

ABSTRACT
With the high development of the technology, many wireless network equipments are also with vigorous development, but there are less network system of low power consumptionlow data rate. Under many environments, people do not need higher transmission speed, instead of wireless installment with more lasting and saving the electricity. Therefore, ZigBee was born under such demand. ZigBee is designed in the network of sensory devices and controling other divices.. The majority ZigBee equipments are extremely sensitive to the power (attemperator, security sensor element and so on). And the life of its battery may last over one year. Because the complexity of the ZigBee network is lower, and the device of it is simple and fast, therefore many designs are all applied to the intelligent electrical appliances system. UPnP (Universal Plug and Play) is a standard which Microsoft promotes. The goal is that all devices can communicate to each other by themselves without any configuration through network. Therefore this technology is also suitable for the intelligent electrical appliances system. Even many intelligent appliances applications also selected by with this method of communication. However, the subject of intelligent appliances has already been discussed for a long time, but it is unable to be popular to everyones life. Although many solutions were already proposed, the excessively high cost, and other technical bottleneck are resulted in the slow speed for promoting intelligent appliances. If we can unify two network technology superiority of ZigBee and UPnP, ZigBee can surely promote entire intelligent appliances industry development fast. The purpose of this paper is to design and to implement ZigBee/UPnP bridge, with simple configuration in the network characteristic, and to discusses how can we define the standard of user friendly network application. We want to use the characteristics of UPnP
5

and ZigBee,to make these technologies more suitable for humanity.

Contents
ACKNOWLEDGMENT......................................................................................................2 ..............................................................................................................................4 ABSTRACT.........................................................................................................................5 Contents ...............................................................................................................................7 List of Figures ......................................................................................................................9 List of Tables......................................................................................................................10 CHAPTER 1 INTRODUCTION ....................................................................................... 11 1.1 Motivation............................................................................................................ 11 CHAPTER 2 ZIGBEE TECHNOLOGY...........................................................................13 2.1 Why is ZigBee needed .........................................................................................13 2.1.1 Comparison of wireless technologies .......................................................13 2.2 IEEE 802.15.4 and ZigBee basics........................................................................14 2.3 ZigBee Network Considerations..........................................................................16 2.4 Stack architecture.................................................................................................18 2.4.1 ZigBee device objects (ZDO) ...................................................................20 2.4.2 Application layer.......................................................................................20 2.4.3 Application Support Layer........................................................................21 2.4.4 Network Layer ..........................................................................................21 2.4.5 Network Routing.......................................................................................21 2.5 Binding, KVPs and messages ..............................................................................22 2.6 Binding and control..............................................................................................24 2.7 ZigBee device profile...........................................................................................25 CHAPTER 3 UPNP TECHNOLOGY ...............................................................................28 3.1 What is UPnP .......................................................................................................28 3.3 Addressing............................................................................................................29 3.4 Discovery .............................................................................................................30 3.5 Description...........................................................................................................31 3.6 Control .................................................................................................................35 3.7 Eventing ...............................................................................................................36 3.8 Presentation..........................................................................................................38 3.9 XML.....................................................................................................................39 3.9.1. device description ....................................................................................40 3.9.2. device service...........................................................................................41 CHAPTER 4 HOW IT WORKS.....................................................................................43 4.1 Construction and function....................................................................................43 Coordinator : ......................................................................................................44
7

Bridge :...............................................................................................................44 4.2 Operation Processes .............................................................................................44 4.2.1 ZigBee Announce: ....................................................................................45 4.2.2 Extension Control .....................................................................................46 CHAPTER 5 IMPLEMENTION OF ZIGBEE TO UPNP BRIDGE ................................48 5.1 Design Of Coordinator.........................................................................................48 5.1.1 Bridge Proxy .............................................................................................49 5.1.2 ZigBee Announce......................................................................................49 5.1.3 ZigBee Control MSG................................................................................50 5.1.4 Bridge Control MSG.................................................................................50 5.1.5 Bridge Interface ........................................................................................50 5.2 Design Of Bridge .................................................................................................51 CHAPTER 6 CONCLUSION............................................................................................53 BIBLIOGRAPHY..............................................................................................................54

List of Figures
Figure 2.1 IEEE 802.15.4 and ZigBee working model......................................15 Figure 2.2 ZigBee network topologies...............................................................17 Figure 2.3 Outline ZigBee stack architecture ....................................................19 Figure 2.4. ZigBee binding and binding table ...................................................22 Figure 2.5. Binding connects compatible ZigBee endpoints to each other........23 Figure 2.6 ZigBee Binding Request...................................................................24 Figure 2.7 ZigBee Binding Confirm..................................................................25 Figure2.8 ZigBee Control ..................................................................................25 Figure3.1. UPnP stack........................................................................................29 Figure 4.1. ZigBee/UPnP Bridge .......................................................................43 Figure 4.2. ZigBee Announce: ...........................................................................46 Figure 4.3. Extension Control............................................................................47 Figure 5.1. Design Of Coordinator ....................................................................48 Figure 5.2 Bridge Proxy.....................................................................................49 Figure 5.3 Bridge ...............................................................................................52

List of Tables
Table 2.1Comparison of wireless technologies..................................................14 Table 2.2 ZigBee Physical Device Types...........................................................17 Table 5.1 package format ...................................................................................50 Table 5.2 command codes..................................................................................51

10

CHAPTER 1 INTRODUCTION
The ZigBee technology is one kind of wireless transmission technology, conforms to the IEEE 802.15.4 standardthe operating frequency is 868MHz, 915MHz or 2.4GHz. It emphasizes the low costlow power consumptionbidirectional transmissionsensor network function and so onIts characteristic is the network extendibility greatly strengthened. By way of links forms the huge intelligent network. At present the field is unifying each kind of intelligent network element to the ZigBee biggest expectation to be able in the temperaturethe lightthe environmental monitoring aspect to play the role then develops its application domain in the daily life. In addition, although the ZigBee transmitting range is farthest only can amount to 100 meters (usually not to be able to arrive) , but it may form the mesh network between the devices , moreover may support to 64 thousand nodes, such superiority is also a goal which other wireless network installment achieved with difficulty. UPnPUniversal Plug and Playis one of the open-type agreement point-to-point technical standard which realizes in the IP network. It is one kind of Web Base communication agreement that uses TCP/IPHTTPXML and SOAPSimple Object Access Protocolat present general standard. It constructs the UPnP platform, because maintains to carry out in the communication agreement. UPnP all may support , no matter transmission medium in the physical layer. For example: Telephone line, RF, infrared, Ethernet or IEEE 1394. Also UPnP uses the existing standard communication agreement. Therefore it can easily integrate the present network.

1.1 Motivation
11

ZigBee has many superiority, lets this technology enter sufficiently into ours life in the short-term. Newest report demonstrated according to ABI the research that, built-in the Zigbee from 2005 more than 9 hundred thousand, will grow to 2006 more than 80 hundred thousand, such growth will be the wireless communication history goes forward never to see. However this technology actually not defines the standard with internet communication. But it is essential in the intelligent appliances development. After unceasing research and collection information discovered that, UPnP suits extremely holds the post of this role. As a result of UPnP network automation Plug and Play characteristic, is the same with the ZigBee simplification configuration characteristic. Therefore we start to study these two standard parallel possibility, after pass through many times experiment and the observation discovered, these two network systems characteristics are very similar. Then, we start to research into the ZigBee to UPnP Bridge.

12

CHAPTER 2 ZIGBEE TECHNOLOGY

The ZigBee Alliance is developing a very low-cost, very low power consumption, two-way, wireless communications standard. Solutions adopting the ZigBee standard will be embedded in consumer electronics, home and building automation, industrial controls, PC peripherals, medical sensor applications, toys and games.

2.1 Why is ZigBee needed

There are a multitude of standards that address mid to high data rates for voice, PC LANs, video, etc. However, up till now there hasnt been a wireless network standard that meets the unique needs of sensors and control devices. Sensors and controls dont

need high bandwidth but they do need low latency and very low energy consumption for long battery lives and for large device arrays. There are a multitude of proprietary wireless systems manufactured today to solve a multitude of problems that also dont require high data rates but do require low cost and very low current drain. These proprietary systems were designed because there were no standards that met their requirements. These legacy systems are creating significant interoperability

problems with each other and with newer technologies. 2.1.1 Comparison of wireless technologies ZigBee, Bluetooth and Wi-Fi are all relatively new wireless technologies. The key comparison points are shown in table 2.1. Essentially, ZigBee is best suited for low-cost, low data rate and battery powered applications. Point-to-point range is limited, but mesh networking provides an alternative stepping-stone approach to communicating over large distances.

13

Where a PC or cellphone is involved, there is some overlap between Bluetooth and ZigBee. For example, either technology could be used for activating your garden lights from your cellphone. ZigBee can do the job more cheaply, but Bluetooth is more likely to be compatible with the phone you have in your pocket today. Where you dont want to go with ZigBee is time-critical, high data rate applications such as audio and video links.

Table 2.1Comparison of wireless technologies

2.2 IEEE 802.15.4 and ZigBee basics

The IEEE 802.15.4 standard and ZigBee wireless network technology are ideal for the implementation of a wide range of low cost, low power and reliable control and monitoring applications within the private home and industrial environment. The working model of the IEEE 802.15.4 and ZigBee is illustrated in Figure 2.1.

14

Figure 2.1 IEEE 802.15.4 and ZigBee working model.

The IEEE 802.15.4 standard specifies the physical (PHY) and media access control (MAC) layers at the 868MHz (Europe), 915MHz (US) and 2.4GHz (worldwide) ISM bands, enabling regional or global deployment. The IEEE 802.15.4 MAC sublayer controls the access to the radio channel using the CSMA-CA(Carrier Sense Multiple Access with Collision Avoidance) method, and handles network(dis)association and MAC layer security (AES-128 encryption based). It is also responsible for flow control via acknowledgement and retransmission of data packets,frame validation, and network synchronization as well as support to upper layers for robust link operation. The ZigBee wireless technology specifies the network, security, and application layers upon the IEEE 802.15.4 PHY and MAC layers. The ZigBee Alliance also provides interoperability and conformance testing specifications.
15

2.3 ZigBee Network Considerations

In the interest of brevity, many network specific features of the IEEE 802.15.4 standard are not covered in detail in this paper. However, these are necessary for the efficient operation of ZigBee networks. These features of the PHY include receiver energy detection, link quality indication and clear channel assessment. Both contention-based and contention-free channel access methods are supported with a maximum packet size of 128 bytes, which includes a variable payload up to 104 bytes. Also employed are 64-bit IEEE and 16-bit short addressing, supporting over 65,000 nodes per network. The MAC provides network association and disassociation, has an optional superframe structure with beacons for time synchronization, and a guaranteed time slot (GTS) mechanism for high priority communications. The channel access method is carrier sense multiple access with collision avoidance (CSMA-CA). ZigBee defines the network, security, and application framework profile layers for an IEEE 802.15.4-based system. ZigBees network layer supports three networking topologies; star, mesh, and cluster tree as shown in Figure 2.3 Star networks are common and provide for very long battery life operation. Mesh, or peer-to-peer, networks enable high levels of reliability and scalability by providing more than one path through the network. Cluster-tree networks utilize a hybrid star/mesh topology that combines the benefits of both for high levels of reliability and support for battery-powered nodes.

16

Figure 2.2 ZigBee network topologies.

To provide for low cost implementation options, the ZigBee Physical Device type distinguishes the type of hardware based on the IEEE 802.15.4 definition of reduced function device (RFD) and full function device (FFD). An IEEE 802.15.4 network requires at least one FFD to act as a network coordinator. The description of each Physical Device type is found in Table 2.1

Table 2.2 ZigBee Physical Device Types An RFD is implemented with minimum RAM and ROM resources and designed to be a simple send and/or receive node in a larger network. With a reduced stack size, less memory is required, thus a less expensive IC. ZigBee RFDs are generally battery powered. RFDs can search for available networks, transfer data from its application as necessary, determine whether data is pending, request data from the network coordinator,
17

and sleep for extended periods of time to reduce battery consumption. RFDs can only talk to an FFD, a device with sufficient system resources for network routing. The FFD can serve as a network coordinator, a link coordinator or as just another communications device. Any FFD can talk to other FFD and RFDs. FFDs discover other FFDs and RFDs to establish communications, and are typically line powered. The ZigBee Logical Device type distinguishes the Physical Device types (RFD or FFD) deployed in a specific ZigBee network. The Logical Device types are ZigBee Coordinators, ZigBee Routers, and ZigBee End Devices. The ZigBee Coordinator initializes a network, manages network nodes, and stores network node information. The ZigBee Router participates in the network by routing messages between paired nodes. The ZigBee End Device acts as a leaf node in the network and can be an RFD or FFD. ZigBee application device types distinguish the type of device from an end-user perspective as specified by the Application Profiles.

2.4 Stack architecture

The ZigBee stack architecture is made up of a set of blocks called layers. Each layer performs a specific set of services for the layer above: a data entity provides a data transmission service and a management entity provides all other services. Each service entity exposes an interface to the upper layer through a service access point (SAP), and each SAP supports a number of service primitives to achieve the required functionality. The ZigBee stack architecture, which is depicted in Figure 2.2, is based on the standard Open Systems Interconnection (OSI) seven-layer model but defines only those layers relevant to achieving functionality in the intended market space. The IEEE 802.15.4-2003 standard defines the lower two layers: the physical (PHY) layer and the
18

medium access control (MAC) sub-layer. The ZigBee Alliance builds on this foundation by providing the network (NWK) layer and the framework for the application layer, which includes the application support sub-layer (APS), the ZigBee device objects (ZDO) and the manufacturer-defined application objects. IEEE 802.15.4-2003 has two PHY layers that operate in two separate frequency ranges: 868/915 MHz and 2.4 GHz. The lower frequency PHY layer covers both the 868 MHz European band and the 915 MHz band that is used in countries such as the United States and Australia. The higher frequency PHY layer is used virtually worldwide.

Figure 2.3 Outline ZigBee stack architecture

The IEEE 802.15.4-2003 MAC sub-layer controls access to the radio channel using a CSMA-CA mechanism. Its responsibilities may also include transmitting beacon frames, synchronization and providing a reliable transmission mechanism. The responsibilities of the ZigBee NWK layer shall include mechanisms used to join and leave a network, to apply security to frames and to route frames to their intended
19

destinations. In addition, the discovery and maintenance of routes between devices devolve to the NWK layer. Also the discovery of one-hop neighbors and the storing of pertinent neighbor information are done at the NWK layer. The NWK layer of a ZigBee coordinator is responsible for starting a new network, when appropriate, and assigning addresses to newly associated devices 2.4.1 ZigBee device objects (ZDO) The ZigBee Device Objects are an application solution residing within the Application Layer (APL) and above the Application Support Sub-layer (APS) in the ZigBee stack architecture. The ZigBee Device Objects are responsible for the following functions: Initializing the Application Support Sublayer (APS), Network Layer (NWK), Security Service Provider (SSP) and any other ZigBee device layer other than the end applications residing over Endpoints 1-240. Assembling configuration information from the end applications to determine and implement the functions described in the following sub-clauses. 2.4.2 Application layer The ZigBee application layer consists of the APS sub-layer, the ZDO and the manufacturer-defined application objects. The responsibilities of the APS sub-layer include maintaining tables for binding, which is the ability to match two devices together based on their services and their needs, and forwarding messages between bound devices. Another responsibility of the APS sub-layer is discovery, which is the ability to determine which other devices are operating in the personal operating space of a device. The responsibilities of the ZDO include defining the role of the device within the network (e.g., ZigBee coordinator or end device), initiating and/or responding to binding requests and establishing a secure relationship
20

between

network

devices.

The

manufacturer-defined application objects implement the actual applications according to the ZigBee-defined application descriptions

2.4.3 Application Support Layer This layer provides the following services: Discovery: The ability to determine which other devices are operating in the personal operating space of a device. Binding: The ability to match two or more devices together based on their services and their needs and forwarding messages between bound devices 2.4.4 Network Layer The responsibilities of the ZigBee NWK layer include: Starting a network: The ability to successfully establish a new network. Joining and leaving a network: The ability to gain membership (join) or relinquish membership (leave) a network. Configuring a new device: The ability to sufficiently configure the stack for operation as required. Addressing: The ability of a ZigBee coordinator to assign addresses to devices joining the network. Synchronization within a network: The ability for a device to achieve synchronization with another device either through tracking beacons or by polling. Security: applying security to outgoing frames and removing security to terminating frames Routing: routing frames to their intended destinations. 2.4.5 Network Routing

21

Perhaps the most straightforward way to think of the ZigBee routing algorithm is as a hierarchical routing strategy with table-driven optimizations applied where possible. NWK uses an algorithm that allows stack implementers and application developers to balance unit cost, battery drain, and complexity in producing ZigBee solutions to meet the specific cost-performance profile of their application. Started with the well-studied public-domain algorithm AODV and Motorolas Cluster-Tree algorithm and folding in ideas from Ember Corporations GRAd.

2.5 Binding, KVPs and messages

Application objects at different end devices can initiate communication by a process known as binding which creates a logical link between application objects. More specifically, an entry is made in the binding table of the coordinator, identifying the endpoints of the application objects that requests a communication link. An application object can be bound with application objects at multiple end devices, as illustrated in Figure 2.5. Here switch 1 controls lamp 1, 2 and 3, while switch 2 only controls lamp 4. The concept of binding is similar to connecting two sockets in TCP/IP.

Figure 2.4. ZigBee binding and binding table

22

The coordinator also manages the Key Value Pair service. In ZigBee networks, data is abstracted as much as possible into Key-Value Pairs (KVPs). The coordinator has a master look-up table known as a binding table that lists which nodes are interested in a particular KVP. This not only keeps the message passing simple, it saves the end points from knowing who they need to send messages to. For example, a light switch only has to tell the coordinator it wants to modify a KVP from off to on. It is the coordinator and/or routers job to work out whether to then send an on message to the bedside light or the runway lights at Heathrow. (Figure 2.4.)

Figure 2.5. Binding connects compatible ZigBee endpoints to each other. The process of securely connecting different end points to each other is known as binding. Typically, an enduser will bind two end points with compatible KVPs by pressing a recessed button on each unit at the same time. In secure networks authentication and encryption processes will additionally be taking place under the hood, but in a well designed ZigBee network the installer would not be aware of this. Once two
23

nodes are bound, the coordinator will ensure that any KVP message generated by one unit is forwarded correctly. Nodes should be able to know how to send and receive four basic types of KVP message: Get to enquire a KVP value, Get Response to reply to a Get, Set to modify a value and Event to signal that a particular event has happened. Each type of message also has a corresponding acknowledge message, and they all have XML schemas defined to provide a seamless bridge to the internet. Some applications may not suit the KVP service, so a free-form message passing service is also provided. End points do not need to be bound in order to send messages to each other.

2.6 Binding and control

In the ZigBee network, must have [Binding] the procedure to let the part by way of match, Like the figure 2.6 shows, Dimmable switch and Dimmable light must have separately to send out Binding request to Coordinator

Figure 2.6 ZigBee Binding Request After Coordinator compared to and matches successfully to these two equipments Profile, Sends out the confirm signal to give these two equipments, Like the figure 2.7 shows

24

Figure 2.7 ZigBee Binding Confirm After completes the Binding flow, Coordinator must retransmit the dimmable switch control signal for dimmable light, Like the figure 2.8 shows

Figure2.8 ZigBee Control

2.7 ZigBee device profile

The key to communicating between devices on a ZigBee network is agreement on a
25

profile. An example of a profile would be home control lighting. This initial ZigBee profile permits a series of (initially) six device types to exchange control messages to form a wireless home automation application. These devices are architected to exchange well known messages (using the KVP service type) to effect control such as turning a lamp on or off, sending a light sensor measurement to a lighting controller or sending an alert message if an occupancy sensor detects movement. Another example of a profile is the device profile that defines common actions between ZigBee devices. To illustrate, wireless networks rely on the ability for autonomous devices to join a network and discover other devices and services on devices within the network. Device and service discovery are features supported within the device profile using the MSG service type. This ZigBee Application Layer Specification describes how general ZigBee device features such as Binding, Device Discovery and Service Discovery are implemented within ZigBee Device Objects. The ZigBee Device Profile operates like any ZigBee profile by defining Device Descriptions and Clusters. Unlike application specific profiles, the Device Descriptions and Clusters within the ZigBee Device Profile define capabilities supported in all ZigBee devices. As with any profile document, this document details the mandatory and/or optional clusters. The Device Profile supports four key inter-device communication functions within the ZigBee protocol : Device and Service Discovery End Device Bind Request Processing Bind and Unbind Command Processing Network Management
26

ZigBee defines profiles in generally three separate classes: private, published and public. The exact definition and criteria for these classes are an administrative issue within the ZigBee Alliance and outside the scope of this document. For the purposes of this technical specification, the only criterion is for profile identifiers to be unique. To that end, every profile effort must start with a request to the ZigBee Alliance for allocation of a profile identifier. Once the profile identifier is obtained, that profile identifier permits the profile designer to define the following: Device descriptions Cluster identifiers Service types (KVP or MSG)

27

CHAPTER 3 UPNP TECHNOLOGY

3.1 What is UPnP
UPnP is an architecture for pervasive peer-to-peer network connectivity of intelligent appliances, wireless devices, and PCs of all form factors. It is designed to bring easy-to-use, flexible, standards-based connectivity to ad-hoc or unmanaged networks whether in the home, in a small business, public spaces, or attached to the Internet. UPnP is a distributed, open networking architecture that leverages TCP/IP and the Web technologies to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and public spaces. UPnP is more than just a simple extension of the plug and play peripheral model. It is designed to support zero-configuration, "invisible" networking, and automatic discovery for a breadth of device categories from a wide range of vendors. This means a device can dynamically join a network, obtain an IP address, convey its capabilities, and learn about the presence and capabilities of other devices. DHCP and DNS servers are optional and are used only if available on the network. Finally, a device can leave a network smoothly and automatically without leaving any unwanted state behind. UPnP leverages Internet components, including IP, TCP, UDP, HTTP, and XML. Like the Internet, contracts are based on wire protocols that are declarative, expressed in XML, and communicated via HTTP. IP internetworking is a strong choice for UPnP because of its proven ability to span different physical media, to enable real world multiple-vendor interoperation, and to achieve synergy with the Internet and many home and office intranets. UPnP has been explicitly designed to accommodate these environments. Further, via bridging, UPnP accommodates media running non-IP

28

protocols when cost, technology, or legacy prevents the media or devices attached to it from running IP. What is "universal" about UPnP? No device drivers; common protocols are used

instead. UPnP networking is media independent. UPnP devices can be implemented using any programming language, and on any operating system. UPnP does not specify or constrain the design of an API for applications running on control points; OS vendors may create APIs that suit their customer's needs. UPnP enables vendor control over device UI and interaction using the browser as well as conventional application programmatic control.

Figure3.1. UPnP stack

3.3 Addressing
Addressing is Step 0 of UPnP networking. Through addressing, devices get a network address. Addressing enables discovery (Step 1) where control points find interesting device(s), description (Step 2) where where control points learn about device capabilities, control (Step 3) where a control point sends commands to device(s), eventing (Step 4) where control points listen to state changes in device(s), and presentation (Step 5)
29

where control points display a user interface for device(s). The foundation for UPnP networking is IP addressing. Each device must have a Dynamic Host Configuration Protocol (DHCP) client and search for a DHCP server when the device is first connected to the network. If a DHCP server is available, i.e., the network is managed, the device must use the IP addressed assigned to it. If no DHCP server is available, i.e., the network is unmanaged; the device must use automatic IP addressing (Auto-IP) to obtain an address. Auto-IP defines how a device: (a) determines if DHCP is unavailable, and (b) intelligently chooses an IP address from a set of link-local IP addresses. This method of address assignment enables a device to easily move between managed and unmanaged networks. The operations described in this section are further clarified in the reference documents listed below. Where conflicts between this document and the reference documents exist, the reference document always takes precedence.

3.4 Discovery
Discovery is the first step in UPnP networking. When a device is added to the network, the UPnP discovery protocol allows that device to advertise its services to control points on the network. Similarly, when a control point is added to the network, the UPnP discovery protocol allows that control point to search for devices of interest on the network. The fundamental exchange in both cases is a discovery message containing a few, essential specifics about the device or one of its services, e.g., its type, identifier, and a pointer to more detailed information. wants to learn more about it, the control point must use the information in the discovery message to send a description query message. The section on Description explains description messages in detail.

30

When a device is removed from the network, it should multicast a number of discovery messages revoking it's earlier announcements, effectively declaring that it's embedded devices and services will not be available. To limit network congestion, the time-to-live (TTL) of each IP packet for each multicast message must default to 4 and should be configurable. Discovery plays an important role in the interoperability of devices and control points using different versions of UPnP networking. The UPnP Device Architecture (defined herein) is versioned with both a major and a minor version, usually written as major.minor, where both major and minor are integers. Advances in minor versions must be a compatible superset of earlier minor versions of the same major version. Advances in major version are not required to be supersets of earlier versions and are not guaranteed to be backward compatible. Version information is communicated in discovery and description messages. In the former, each discovery message includes the version of UPnP networking that the device supports. As a backup, the latter also includes the same information. This section explains the format of version information in discovery messages and specific requirements on discovery messages to maintain compatibility with advances in minor versions. The standard multicast address, as well as the mechanisms for advertising, searching, and revoking, are defined by the Simple Service Discovery Protocol (SSDP). The remainder of this section explains SSDP in detail, enumerating how devices advertise and revoke their advertisements as well as how control points search and devices respond.

3.5 Description
After a control point has discovered a device, the control point still knows very little about the device -- only the information that was in the discovery message, i.e., the device's (or service's) UPnP type, the device's universally-unique identifier, and a URL to

31

the device's UPnP description. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve a description of the device and its capabilities from the URL provided by the device in the discovery message. The UPnP description for a device is partitioned into two, logical parts: a device description describing the physical and logical containers, and one or more service descriptions describing the capabilities exposed by the device. A UPnP device description includes vendor-specific, manufacturer information like the model name and number, serial number, manufacturer name, URLs to vendor-specific Web sites, etc. (details below). For each service included in the device, the device description lists the service type, name, a URL for a service description, a URL for control, and a URL for eventing. A device description also includes a description of all embedded devices and a URL for presentation of the aggregate. This section explains UPnP device descriptions, and the sections on Control, Eventing, and Presentation explain how URLs for control, eventing, and presentation are used, respectively. Note that a single physical device may include multiple logical devices. Multiple logical devices can be modeled as a single root device with embedded devices (and services) or as multiple root devices (perhaps with no embedded devices). In the former case, there is one UPnP device description for the root device, and that device description contains a description for all embedded devices. In the latter case, there are multiple UPnP device descriptions, one for each root device. A UPnP device description is written by a UPnP vendor. The description is in XML syntax and is usually based on a standard UPnP Device Template. A UPnP Device Template is produced by a UPnP Forum working committee; they derive the template from the UPnP Template Language, which was derived from standard constructions in

32

XML. This section explains the format for a UPnP device description, UPnP Device Templates, and the part of the UPnP Template Language that covers devices. A UPnP service description includes a list of commands, or actions, the service responds to, and parameters, or arguments, for each action. A service description also includes a list of variables. These variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics. This section explains the description of actions, arguments, state variables, and the properties of those variables. The section on Eventing explains event characteristics. Like a UPnP device description, a UPnP service description is written by a UPnP vendor. The description is in XML syntax and is usually based on a standard UPnP Service Template. A UPnP Service Template is produced by a UPnP Forum working committee; they derived the template from the UPnP Template Language, augmenting it with human language where necessary. The UPnP Template Language is derived from standard constructions in XML. This section explains the format for a UPnP service description, UPnP Service Templates, typical augmentations in human language, and the part of the UPnP Template Language that covers services. UPnP vendors can differentiate their devices by extending services, including additional UPnP services, or embedding additional devices. When a control point retrieves a particular device's description, these added features are exposed to the control point for control and eventing. The device and service descriptions authoritatively document the implementation of the device. Retrieving a UPnP device description is simple: the control point issues an HTTP GET request on the URL in the discovery message, and the device returns the device description. Retrieving a UPnP service description is a similar process that uses a URL within the device description. The protocol stack, method, headers, and body for the

33

response and request are explained in detail below. As long as the discovery advertisements from a device have not expired, a control point may assume that the device and its services are available. The device and service descriptions may be retrieved at any point since the device and service descriptions are static as long as the device and its services are available. If a device cancels its advertisements, a control point must assume the device and its services are no longer available. If a device needs to change one of these descriptions, it must cancel its outstanding advertisements and re-advertise. Consequently, control points should not assume that device and service descriptions are unchanged if a device re-appears on the network. Like discovery, description plays an important role in the interoperability of devices and control points using different versions of UPnP networking. As explained in the section on Discovery, The UPnP Device Architecture (defined herein) is versioned with both a major and a minor version. Advances in minor versions must be a compatible superset of earlier minor versions of the same major version. Advances in major version are not required to be supersets of earlier versions and are not guaranteed to be backward compatible. Version information is communicated in description messages as a backup to the information communicated in discovery messages. This section explains the format of version information in description messages. The remainder of this section first explains how devices are described, explaining details of vendor-specific information, embedded devices, and URLs for control, eventing, and presentation. Second, it explains UPnP Device Templates. Third, it explains how services are described, explaining details of actions, arguments, state variables, and properties of those variables. Then it explains UPnP Service Templates, and the UPnP Template Language. Finally, this section explains in detail how a control point retrieves

34

device and service descriptions from a device.

3.6 Control
Control is the third step in UPnP networking. Given knowledge of a device and its services, a control point can ask those services to invoke actions and the control point can poll those services for the values of their state variables. Invoking actions is a kind of remote procedure call; a control point sends the action to the device's service, and when the action has completed (or failed), the service returns any results or errors. Polling for the value of state variables is a special case of this scenario where the action and its results are predefined. To control a device, a control point invokes an action on the device's service. To do this, a control point sends a suitable control message to the control URL for the service (provided in the controlURL sub element of service element of device description). In response, the service returns any results or errors from the action. The effects of the action, if any, may also be modeled by changes in the variables that describe the run-time state of the service. When these state variables change, events are published to all interested control points. This section explains the protocol stack for, and format of, control messages. The section on Eventing explains event publication. To determine the current value of a state variable, a control point may poll the service. Similar to invoking an action, a control point sends a suitable query message to the control URL for the service. In response, the service provides the value of the variable; each service is responsible for keeping its state table consistent so control points can poll and receive meaningful values. This section also explains the format of these query messages. The section on eventing explains automatic notification of variable values. As long as the discovery advertisements from a device have not expired, a control

35

point may assume that the device and its services are available. If a device cancels its advertisements, a control point must assume the device and its services are no longer available. While UPnP does define a means to invoke actions and poll for values, UPnP does not specify or constrain the design of an API for applications running on control points; OS vendors may create APIs that suit their customer's needs. The remainder of this section explains in detail how control and query messages are formatted and sent to devices.

3.7 Eventing
After a control point has (1) discovered a device and (2) retrieved a description of the device and its services, the control point has the essentials for eventing. As the section on Description explains, a UPnP service description includes a list of actions the service responds to and a list of variables that model the state of the service at run time. If one or more of these state variables are evented, then the service publishes updates when these variables change, and a control point may subscribe to receive this information. Throughout this section, publisher refers to the source of the events (typically a device's service), and subscriber refers to the destination of events (typically a control point). To subscribe to eventing, a subscriber sends a subscription message. If the subscription is accepted, the publisher responds with a duration for the subscription. To keep the subscription active, a subscriber must renew its subscription before the subscription expires. When a subscriber no longer needs eventing from a publisher, the subscriber should cancel its subscription. This section explains subscription, renewal, and cancellation messages in detail below. The publisher notes changes to state variables by sending event messages. Event

36

messages contain the names of one of more state variables and the current value of those variables, expressed in XML. A special initial event message is sent when a subscriber first subscribes; this event message contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the service. To support scenarios with multiple control points, eventing is designed to keep all subscribers equally informed about the effects of any action. Therefore, all subscribers are sent all event messages, subscribers receive event messages for all evented variables (not just some), and event messages are sent no matter why the state variable changed (either in response to a requested action or because the state the service is modeling changed). This section explains the format of event messages in detail below. Some state variables may change value too rapidly for eventing to be useful. One alternative is to filter, or moderate, the number of event messages sent due to changes in a variable's value. Some state variables may contain values too large for eventing to be useful; for this, or other reasons, a service may designate one or more state variables as non evented and never send event messages to subscribers. To determine the current value for such non-evented variables, control points must poll the service explicitly. This section explains how variable eventing is described within a service description. The section on Control explains how to poll a service for a variable value. To send and receive subscription and event messages, control points and services use the following subset of the overall UPnP protocol stack. At the highest layer, subscription and event messages contain vendor-specific information like URLs for subscription and duration of subscriptions or specific variable values. Moving down the stack, vendor content is supplemented by information from a UPnP Forum working committee, like service identifiers or variable names. Messages from the layers above are hosted in UPnP-specific protocols, defined in this document. In

37

turn, the above messages are delivered via HTTP that has been extended using General Event Notification Architecture (GENA) methods and headers. The HTTP messages are delivered via TCP over IP. For reference, colors in [square brackets] above indicate which protocol defines specific header elements in the subscription messages listed below. The remainder of this section first explains subscription, including details of subscription messages, renewal messages, and cancellation messages. Second, it explains in detail how event messages are formatted and sent to control points, and the initial event message. Finally, it explains the UPnP Template Language as it pertains to eventing.

3.8 Presentation
After a control point has (1) discovered a device and (2) retrieved a description of the device, the control point is ready to begin presentation. If a device has a URL for presentation, then the control point can retrieve a page from this URL, load the page into a browser, and depending on the capabilities of the page, allow a user to control the device and/or view device status. The degree to which each of these can be accomplished depends on the specific capabilities of the presentation page and device. The URL for presentation is contained within the presentationURL element in the device description. The device description is delivered via a description message. The section on Description explains the device description and description messages in detail. Retrieving a presentation page is a simple HTTP-based process and uses the following subset of the overall UPnP protocol stack. (The overall UPnP protocol stack is listed at the beginning of this document.) At the highest layer, the presentation page is specified by a UPnP vendor. Moving down the stack, the UPnP Device Architecture specifies that this page be written in HTML. The page is delivered via HTTP over TCP over IP. For reference, colors in

38

[square brackets] are included for consistency with other sections in this document. To retrieve a presentation page, the control point issues an HTTP GET request to the presentation URL, and the device returns a presentation page. Unlike the UPnP Device and Service Templates, and standard device and service types, the capabilities of the presentation page are completely specified by the UPnP vendor. The presentation page is not under the auspices of a UPnP Forum working committee. The page must be an HTML page; it should be version HTML 3.0 or later. However, other design aspects are left to the vendor to specify. This includes, but is not limited to, all capabilities of the control point's browser, scripting language or browser plug-ins used, and means of interacting with the device. To implement a presentation page, a UPnP vendor may wish to use UPnP mechanisms for control and/or eventing, leveraging the device's existing capabilities but is not constrained to do so. Presentation pages should use mechanisms provided by HTML for localization (e.g., META tag with charset attribute). Control points should use the ACCEPT- / CONTENT-LANGUAGE feature of HTTP to try to retrieve a localized presentation page. Specifically, a control point may include a HTTP ACCEPT-LANGUAGE header in the request for a presentation page; if an ACCEPT-LANGUAGE header is present in the request, the response must include a CONTENT-LANGUAGE header to identify the page's language.

3.9 XML
The UPnP description for a device contains several pieces of vendor-specific information, definitions of all embedded devices, URL for presentation of the device, and listings for all services, including URLs for control and eventing. In addition to defining non-standard devices, UPnP vendors may add embedded devices and services to standard devices. To illustrate these, below is a listing with placeholders for actual elements and

39

values. Some of these placeholders would be specified by a UPnP Forum working committee or by a UPnP vendor. For a non-standard device, all of these placeholders would be specified by a UPnP vendor. Immediately following the listing is a detailed explanation of the elements, attributes, and values.

3.9.1. device description <?xml version="1.0" ?> - <root xmlns="urn:schemas-upnp-org:device-1-0"> - <specVersion> <major>1</major> <minor>0</minor> </specVersion> - <device> <deviceType>urn:schemas-upnp-org:device:binarylight:1</deviceType> <friendlyName>Siemens Test Device</friendlyName> <manufacturer>Siemens AG</manufacturer> <manufacturerURL>/manufacturer.html</manufacturerURL> <modelDescription>A Test Device for the UPnP Stack Implementation</modelDescription> <modelName>Cardamom</modelName> <modelNumber>1.0</modelNumber> <modelURL>/model.html</modelURL> <serialNumber>1234567890</serialNumber> <UDN>uuid:siemensTestDevice</UDN> <UPC>123456789012</UPC> - <iconList> - <icon> <mimetype>image/gif</mimetype> <width>30</width> <height>30</height> <depth>8</depth> <url>/icon.gif</url> </icon> </iconList> - <serviceList> - <service>
40

<serviceType>urn:schemas-upnp-org:service:SwitchPower:1</serviceType> <serviceId>urn:upnp-org:serviceId:SwitchPower:1</serviceId> <SCPDURL>/siemensTestDevice/urn_upnp-org_serviceId_SwitchPower_1/description. xml</SCPDURL> <controlURL>/siemensTestDevice/urn_upnp-org_serviceId_SwitchPower_1/control</c ontrolURL> <eventSubURL>/siemensTestDevice/urn_upnp-org_serviceId_SwitchPower_1/eventSu b</eventSubURL> </service> </serviceList> <presentationURL>/siemensTestDevice/presentation.html</presentationURL> </device> </root> 3.9.2. device service <?xml version="1.0" ?> - <scpd xmlns="urn:schemas-upnp-org:service-1-0"> - <specVersion> <major>1</major> <minor>0</minor> </specVersion> - <actionList> - <action> <name>SetTarget</name> - <argumentList> - <argument> <name>newTargetValue</name> <relatedStateVariable>Target</relatedStateVariable> <direction>in</direction> </argument> </argumentList> </action> - <action> <name>GetStatus</name> - <argumentList> - <argument> <name>ResultStatus</name> <relatedStateVariable>Status</relatedStateVariable>
41

<direction>out</direction> <retval /> </argument> </argumentList> </action> </actionList> - <serviceStateTable>

- <stateVariable sendEvents="no">

<name>Target</name> <dataType>boolean</dataType> <defaultValue>0</defaultValue> </stateVariable> - <stateVariable sendEvents="yes"> <name>Status</name> <dataType>boolean</dataType> <defaultValue>0</defaultValue> </stateVariable> </serviceStateTable> </scpd>

42

CHAPTER 4 HOW IT WORKS

The basic function and movement flow of UPnP and ZigBe were introduced in the previous chapters. Next, we will focus on the conformity and analysis in view of these function and movements.

4.1 Construction and function

After research and observation, has sketched the following chart, Bridge construction, and will confirm the feasibility of this construction in the following chapter.

Figure 4.1. ZigBee/UPnP Bridge The construction is composed by three parts: ZigBee network, UPnP network, and PC base Bridge, which connects the former two networks. In ZigBee network, all the information transmit through coordinator; therefore, the outside transmission news work is also responsible by coordinator. To facilitate information packing and the transmission, designed a Bridge proxy device inside the Coordinator to complete these actions.
43

In addition, PC base Bridge is the PC software which composed by java, the prime task is being responsible for ZigBee network and between the UPnP network information transmission, and to make these information suitable for transformation processing. Coordinator and the Bridge detailed work content is as follows: Coordinator : (a) Transmit Device description and Profile ZigBee in network device to Bridge, this movement is defined Register. (b) After completing Register, starts transmits between ZigBee network and the Bridge messages Bridge : (a) Register : Stores up the ZigBee network device information to the XML document in, and based on this XML document, UPnP device which create corresponds (b) Binding : Bridge must analyze and judge each equipment the function, and links the function correspondence the device, for example, binary switch corresponds binary light (c) Control : After pairing successfully, causes UPnP network and between ZigBee network control signal control message,command,data, transforms mutually into the form which corresponds, enables these information to be possible the correct transmission opposite party network.

4.2 Operation Processes

Here introduced ZigBee device and UPnP device pairing and the communication flow, which we divide into two parts. The first part is called [ZigBee Announce], mainly contains the announcement and the pairing; the second part we called [Extension Control], which contains transmits the material or the control signal in this part prime task between the installment which completes in the pair.

44

4.2.1 ZigBee Announce: In order to enable ZigBee device being controlled by Bridge, first must inform Bridge all ZigBee device the information, this part, the following chart shows, divides into four steps: Step 1 ZigBee device and Bridge proxy separately sends out Binding request to Coordinator. Step 2 Bridge proxy sends out ZigBee to coordinator the announce request to cause zigBee device information to transmit for Bridge. Step 3Creates UPnP service or UPnP control by ZigBee Proxy based on the ZigBee device characteristic. Step 4On behalf of ZigBee UPnP device and UPnP network part connection, if Control the point attribute connects UPnP service, if otherwise the service attribute connects UPnP control point.

45

Connect to UPnP Service

4 1 3 3 2

ZigBee network

Coordinator ZigBee device Bridge proxy

PC base Bridge UPnP network

ZigBee proxy UPnP Service UPnP Control Point

Figure 4.2. ZigBee Announce: 4.2.2 Extension Control This part is the transmitting process about controlling signal between ZigBee and UPnP. Here sends out power on by the ZigBee device to the UPnP device the example to explain, the following chart shows, divides into four steps Step 1Sends out a Power on signal to Bridge proxy by ZigBee device. Step 2Transmits this Power on by Bridge proxy to ZigBee proxy the signal. Step 3By ZigBee Proxy this control signal transformation is the UPnP control signal, and transmits for acts ZigBee device UPnP Control Point. Step 4 By agential ZigBee UPnP Control Point to control signal transmission for UPnP in the network service device.

46

Figure 4.3. Extension Control

47

CHAPTER 5 IMPLEMENTION OF ZIGBEE TO UPNP BRIDGE

This chapter shows the introduction of actual design. The firmware formula of the coordinator part is composed with the C language, and the Bridge part is composed with JAVA. I use JAVA to compose Bridge mainly because the Object-Oriented and the cross platform characteristic.suit for this part. In the future we might also coordinate it and the software named SOCAD developed by our laboratory to transform JAVA into VHDL. And we can change Bridge from sofeware to hardware.

5.1 Design Of Coordinator

This chapter will show how to make the element. Like the following chart shows, the firmware construction of ZigBee manages every layer as a task through an operation system. In this system, every Task is independent from each other, but passing message by OS can we combine each Task closely. And the Bridge Proxy element designed by us is Bridge_Task.

Bridge_Task

ZDAPP_Task

OS

APS_Task

nwk_Task

OnBoard_Task

Figure 5.1. Design Of Coordinator In this software construction, each task corresponds to a layer of ZigBees Sack. ZDAPP_Task corresponds with ZigBee Device Object(ZDO) layer, And APS_Task,

48

NWK Task, OnBoard Task correspond with Application Support Sublayer(APS)layer, Network(NWK) layer, and Medium Access Control(MAC) layer. The most principal part in this formula is Bridge_Task, which corresponds with Application Framework . In the preceding section we mentioned Application Framework may have 240 Application Object most, and the Bridge Proxy element is made of one of the Application Object.

5.1.1 Bridge Proxy According to the following chart, Bridge Proxy is the key element of Coordinator.It has been divided into four sub-areas, and these four sub-areas are as follows: ZigBee Announce: That transmits the element information from ZigBee Network to the Interface unit. ZigBee Control MSG: That transmits control signal to from ZigBeethe Interface unit in the network Bridge Control MSG: Control signal transmit to the ZigBee device comes from the Bridge. Bridge Interface: Coordinator and Bridge communication pipeline.

Figure 5.2 Bridge Proxy 5.1.2 ZigBee Announce

49

This unit primary cognizance collects and transmits on ZigBee network device description and profile, these movement flow are as follows (1)Firstly, must let Bridge Proxy and ZigBee Device Binding (2)secondly, ZigBee device can spread this equipment information Coordinator (3)Finally, Picks up these informations and transmits this information for Bridge the Interface unit 5.1.3 ZigBee Control MSG After ZigBee device and UPnP device pair completely, transmits the control signal from ZigBee device to Bridge through the Bridge Interface.

5.1.4 Bridge Control MSG After ZigBee device and UPnP the device pair completely, transmits the control signal from UPnP device to the corresponding ZigBee device . 5.1.5 Bridge Interface This unit is responsible to process the messages between Bridge Proxy and the Bridge, these messages are through RS232 to transmit, in order to processes these materials easily, we define a simple package form, the following table shows. Byte 0
0x25

Byte 1
0xDA

Byte 2
Length

Byte 3
Code (see below)

Bytes 4-n
data

Byte n+1
Chksum

Table 5.1 package format The checksum is an XOR checksum of each byte 0-n

The possible command codes are defined as follows. Name Reserved Code Dir Purpose For future use.
50

0x00-0x20 N/A

NetworkConnect DeviceConnect

0x21 0x22

Output The ZigBee network informs. Output A new device is connecting to the network. Also sent if a device is reconnecting to the network after a reset. Output A device is disconnecting from the network. Output KVP or MSG message Output Sets the name of the device, to be stored in flash. Also sets position. Output Cluster Id , Endpoint, shortaddr. Input Control message from UPnP

DeviceDisconnect Message type DeviceName Device Description UPnP message

0x23 0x24 0x25 0x26 0x27

Table 5.2 command codes

5.2 Design Of Bridge

Bridge mainly constitutes (the following chart by three parts to show), respectively is UPnP Control Point, UPnP Service and ZigBee Proxy; ZigBee Proxy is the Bridge key element, this part prime task into transforms and transmits UPnP and between the ZigBee network information, other part specify are as follows 1. UPnP Control Point : Is the standard UPnP element which used to send out the control signal from the UPnP network, when ZigBee device want to transmit control signal for UPnP in network that would create UPnP Control Point and then send out the control signal by UPnP Control Point. 2. UPnP Service: Is the standard UPnP element which used to receive control signal from the UPnP network, when UPnP element want to transmit messages for ZigBee device in network that would create UPnP service element from Bridge and then UPnP service element receives the control signal or the transmission message. 3. Control Point Interface : Is UPnP Control Point to ZigBee Proxy interface which main of purposes was to
51

send out the UPnP Control Point. 4. Service Interface : Is UPnP Service to ZigBee Proxy interface which main of purpose was to receive the control signal from UPnP Service. 5. ZigBee Interface : ZigBee Proxy is used the RS232 interface to communicate of Coordinator that the package format same with [Bridge Interface] 6. Create Control Point & Create Service : After ZigBee announce, Bridge Proxy can obtains the information of ZigBee device and analyzes this the equipment information and then creates correspondence device, if the ZigBee device belongs to Output element and then Creates Control Point, if the ZigBee device belongs to Input element and then Creates Service. 7. Convert MSG : transforms the control signal between the UPnP network and ZigBee network if the signal comes from ZigBee network, then the signal would transmit to the UPnP element by Control Point. Otherwise, Bridge receives control signal by UPnP Service, then transforms ZigBee control signal.
Control Point Interface
Create Service Create Control Point Convert MSG

UPnP Control Point

ZigBee Interface

UPnP Service Service Interface

Figure 5.3 Bridge

52

CHAPTER 6 CONCLUSION
In this paper, we discuss and thoroughly research ZigBee and the UPnP network system and make the progressive discussion in view of this technical future expansibility. We will design ZigBee to UPnP Bridge by the intelligent appliances conception, and prove such design would work correctly. In the proposed construction of this paper can extend the ZigBee network characteristic to other network standard. Although this paper not yet possess the UPnP network function to correspond in the ZigBee network, but has already defined the explicit construction and the standard, the future work would be easy. Perhaps in the near future ZigBee will completely be able to enter human's life, it will become the necessary tool for everyone.

53

BIBLIOGRAPHY
[1] ZigBee Alliance,ZigBee Specification.Version 1.0 ZigBee Document 053474r06, December 14th, 2004. [2]P. Kinney, ZigBee Technology: Wireless Control that Simply Works, White Paper dated 2 October 2003. [3]802.15.4, Part 15.4: Wireless Medium Access Control(MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks (LRWPANs). [4]Sheng-Fu Su, The Design and Implementation of the ZigBee Protocol Driver in Linux, White Paper dated 26 july 2005 [5]Jacob Munk-Stander,Implementing a ZigBee Protocol Stack and Light Sensor in TinyOS,White Paper dated October 2005 [6]Contributing Members of the UPnP Forum,UPnP Device Architecture ,08 Jun 2000 [7]Siemens,Siemens UPnP Technology Stack Programming Guide,2000 [8] Freescale Semiconductor,ZigBee Implementers Guide ;Document Number: F8W-2004-0007,May 23, 2005 [9]Figure 8 Wireless,Z-Stack OS Abstraction Application Programming Interface Document Number: F8W-2003-0002,April 8, 2005 [10]Figure 8 Wireless,Z-Stack Application Framework (AF) Application Programming Interface,May 9, 2005 [11]Figure 8 Wireless,Z-Stack Application Support Sub-Layer (APS) Application Programming Interface Document Number: F8W-2003-0025 ,June 21 2005 [12]Figure 8 Wireless,Z-Stack Device Object (ZDO) Application Programming Interface Document Number: F8W-2003-0025,April 8, 2005

54