Design & Implementation of Routing Protocol for WSN
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Design & Implementation of Routing Protocol for WSN

on

  • 402 views

A wireless sensor network is an active research area with numerous workshops and conferences arranged each year. A Wireless Sensor Networks (WSN) is a set of hundreds or thousands of micro sensor ...

A wireless sensor network is an active research area with numerous workshops and conferences arranged each year. A Wireless Sensor Networks (WSN) is a set of hundreds or thousands of micro sensor nodes that have capabilities of sensing, establishing wireless communication between each other and doing computational and processing operations. Sensor networks have a wide variety of applications and systems with vastly varying requirements and characteristics. The sensor networks can be used in Military environment, Disaster management, Habitat monitoring, Medical and health care, Industrial fields, Home networks, detecting chemical, Biological, radiological, nuclear, and explosive material etc. Deployment of a sensor network in these applications can be in random fashion ZigBee is a specification for a suite of high-level communication protocols. Zigbee is a typical wireless communication technology. ZigBee uses low rate, low-power digital radios based on an IEEE 802 standard for personal area networks. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs (Wireless personal area network), such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate, long battery life, and secure networking. ZigBee has a defined rate of 250 kbps best suited for periodic or intermittent data or a single signal transmission from a sensor or input device. It is Open standard protocol with no or negligible licensing fees, chipsets available from multiple sources, remotely upgraded firmware, fully wireless and low power, mesh networking to operate on batteries, low maintenance and larger network size with standard based high security.
In this project a ZigBee based routing protocol, Z Stack and application is developed on 8051 based development boards. A wireless sensor network (WSN) is established using a coordinator and two end devices. The coordinator reads the data from input device and the sensors for computation and operation.

Statistics

Views

Total Views
402
Views on SlideShare
402
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Design & Implementation of Routing Protocol for WSN Document Transcript

  • 1. i A Project Report On Design & Implementation of routing protocol for WSN SUBMITTED IN PARTIAL FULFILLMENT FOR THE AWARD OF DIPLOMA IN EMBEDDED SYSTEMS DESIGN From C-DAC, ACTS (Bangalore) Guided by:- Mr. Tulsi Dwarakanath V Presented by V Hari Krishna PRN: 140250130073 Manish Kumar PRN: 140250130037 Muhammad Saad Khan PRN: 140250130040 CENTER FOR DEVELOPMENT OF ADVANCE COMPUTING ACTS-BANGALORE
  • 2. ii CERTIFICATE OF APPROVAL OF PROJECT WORK This is to certify that the project report entitled “Design & Implementation of Routing protocol for WSN” is a bonafide work carried out by V Hari Krishna (73), Manish Kumar (37) and Muhammad Saad Khan (40) in fulfillment for the award of “Diploma in Embedded Systems Design” Place: CDAC-ACTS, Bangalore, Feb-2014 Batch. Signature Signature (Mr. Tulsi Dwarakanath V) (Ms. Savitri Murali) Project Guide Course Coordinator
  • 3. iii ACKNOWLEDGEMENT It gives us great pride to represent the project report for our project entitled “DESIGN & IMPLEMENTATION OF ROUTING PROTOCOL FOR WSN”. It gives us great pleasure in conveying our sincere thanks to all those who have helped us in the successful completion of this project. We would like to thank our project guide Mr. Tulsi Dwarakanath for his constant encouragement and support and the valuable feedback he provided us with throughout the project. We would also like to thank Ms. Savitri Murali (Course Coordinator, DESD) for providing all the help required in this project completion. V HARI KRISHNA (DESD – 73) MANISH KUMAR (DESD – 37) MUHAMMED SAAD KHAN (DESD – 40)
  • 4. iv ABSTRACT A wireless sensor network is an active research area with numerous workshops and conferences arranged each year. A Wireless Sensor Networks (WSN) is a set of hundreds or thousands of micro sensor nodes that have capabilities of sensing, establishing wireless communication between each other and doing computational and processing operations. Sensor networks have a wide variety of applications and systems with vastly varying requirements and characteristics. The sensor networks can be used in Military environment, Disaster management, Habitat monitoring, Medical and health care, Industrial fields, Home networks, detecting chemical, Biological, radiological, nuclear, and explosive material etc. Deployment of a sensor network in these applications can be in random fashion ZigBee is a specification for a suite of high-level communication protocols. Zigbee is a typical wireless communication technology. ZigBee uses low rate, low-power digital radios based on an IEEE 802 standard for personal area networks. The technology defined by the ZigBee specification is intended to be simpler and less expensive than other WPANs (Wireless personal area network), such as Bluetooth. ZigBee is targeted at radio-frequency (RF) applications that require a low data rate, long battery life, and secure networking. ZigBee has a defined rate of 250 kbps best suited for periodic or intermittent data or a single signal transmission from a sensor or input device. It is Open standard protocol with no or negligible licensing fees, chipsets available from multiple sources, remotely upgraded firmware, fully wireless and low power, mesh networking to operate on batteries, low maintenance and larger network size with standard based high security. In this project a ZigBee based routing protocol, Z Stack and application is developed on 8051 based development boards. A wireless sensor network (WSN) is established using a coordinator and two end devices. The coordinator reads the data from input device and the sensors for computation and operation.
  • 5. Contents Contents .....................................................................................................................................v List of figures......................................................................................................................... viii 1 Software & Hardware requirements...................................................................................1 2 Introduction ........................................................................................................................2 2.1 ZigBee stack Architecture...........................................................................................3 3 Application Layer...............................................................................................................5 3.1 Application Support Sub-Layer ..................................................................................5 3.1.1 Application Support Sub-Layer Data Entity (APSDE) .......................................6 3.1.2 Application Support Sub-Layer Management Entity (APSME) .........................7 3.2 Application Framework...............................................................................................8 3.3 Application Profiles.....................................................................................................8 3.3.1 Creating a ZigBee Profile ....................................................................................8 3.3.2 ZigBee Profiles ....................................................................................................9 3.3.3 ZigBee Profiles in Progress .................................................................................9 3.4 Clusters........................................................................................................................9 3.5 Getting a Profile Identifier from the ZigBee Alliance ................................................9 3.6 The ZigBee Device Profile........................................................................................10 3.6.1 Scope..................................................................................................................10 3.6.2 Device and Service Discovery Overview ..........................................................11 3.6.3 End Device Bind Overview ...............................................................................11 3.6.4 Bind and Unbind Overview ...............................................................................11 3.6.5 Binding Table Management Overview..............................................................11 3.7 ZigBee Device Objects..............................................................................................12 3.7.1 Scope..................................................................................................................12 3.7.2 Device Object Descriptions ...............................................................................13 3.8 Advantages of ZigBee...............................................................................................13 3.9 Disadvantages............................................................................................................13 3.10 Application of ZigBee...............................................................................................13 4 Network (NWK) Layer.....................................................................................................14 4.1 Services provided by NLDE: ....................................................................................14
  • 6. vi 4.1.1 Service specifications: .......................................................................................15 4.2 Service provided by NLME: .....................................................................................15 4.2.1 Service specifications: .......................................................................................16 4.3 NWK Information Base (NIB)..................................................................................19 5 Routing Protocol for WSN ...............................................................................................20 5.1 Ad hoc On-Demand Distance Vector Routing..........................................................20 5.1.1 Working .............................................................................................................20 5.1.2 Advantages and disadvantages ..........................................................................21 6 ZigBee and IEEE 802.15.4...............................................................................................22 6.1 Introduction:..............................................................................................................22 6.2 General Characteristics .............................................................................................24 6.3 LR-WPAN Device Architecture ...............................................................................25 6.4 IEEE 802.15.4 PHY Layer........................................................................................26 6.5 IEEE 802.15.4 MAC Layer.......................................................................................27 6.6 Network Topology ....................................................................................................29 7 Z-stack component APIs ..................................................................................................30 7.1 Zigbee Device Object (ZDO):...................................................................................30 7.1.1 Device Network Startup APIs:...........................................................................30 7.1.2 Device and Service Discovery APIs:.................................................................31 7.1.3 End device Bind, Bind and Unbind Service APIs: ............................................31 7.1.4 Network Management Service APIs:.................................................................32 7.2 Application Framework (AF)....................................................................................34 7.2.1 Endpoint Management APIs:.............................................................................34 7.3 Application Support Sub layer (APS).......................................................................35 7.3.1 Binding Table Management APIs:.....................................................................35 7.3.2 Group Table Management APIs ........................................................................36 7.3.3 Quick Address Lookup APIs: ............................................................................36 7.4 Network Layer(NWK) ..............................................................................................37 7.4.1 Network Management APIs...............................................................................37 7.4.2 Network Variables and Utility APIs..................................................................38 8 Compiling options for Zigbee stack .................................................................................40 8.1 Selecting logical device type:....................................................................................40 8.2 Compile options for a specific project are located in two places..............................40
  • 7. vii 8.2.1 Compile Options In IAR Project Files:..............................................................40 8.3 Using compiling options: ..........................................................................................41 8.3.1 General compile options and definitions: ..........................................................41 8.3.2 The compile options in the following table cannot be changed or used:...........42 8.3.3 Zigbee Device Object (ZDO) Compile Options:...............................................43 9 Conclusion........................................................................................................................44 10 Future Scope .................................................................................................................44 11 References.....................................................................................................................45
  • 8. viii List of figures: Figure 2-1 Wireless Sensor Network (WSN) ............................................................................2 Figure 2-2 Zigbee Stack............................................................................................................3 Figure 3-1 Outline of the ZigBee Stack Architecture................................................................5 Figure 3-2 The APS Sub-Layer Reference Model.....................................................................6 Figure 4-1 Network layer.........................................................................................................14 Figure 4-2 NWK Discovery Sequence ....................................................................................16 Figure 4-3 NWK Formation Sequence ....................................................................................17 Figure 5-1 AODV Messaging Protocol ...................................................................................21 Figure 6-1 ZigBee module.......................................................................................................22 Figure 6-2 Data rate Vs Range.................................................................................................23 Figure 6-3 ZigBee 802.15.4 Specifications .............................................................................23 Figure 6-4 Wireless Standard Comparisons ............................................................................24 Figure 6-5 ZigBee device construction....................................................................................25 Figure 6-6 LR-WPAN device architecture ..............................................................................25 Figure 6-7 Frequency bands and data rates..............................................................................26 Figure 6-8 IEEE 802.15.4 channel structure............................................................................27 Figure 6-9 IEEE 802.15.4 PHY layer ......................................................................................27 Figure 6-10 IEEE 82.15.4 ZigBee protocol architecture .........................................................28 Figure 6-11 IEEE 802.15.4 operational modes........................................................................29 Figure 8-1 Compiling options..................................................................................................41
  • 9. 1 1 Software & Hardware requirements IAR Embedded Workbench CC debugger CC2430 based SOC boards (Ubimotes)
  • 10. 2 2 Introduction A wireless sensor network (WSN) of spatially distributed autonomous sensors to monitor physical or environmental conditions, such as temperature, sound, pressure, etc. and to cooperatively pass their data through the network to a main location. The more modern networks are bi-directional, also enabling control of sensor activity. The development of wireless sensor networks was motivated by military applications such as battlefield surveillance; today such networks are used in many industrial and consumer applications, such as industrial process monitoring and control, machine health monitoring, and so on. The WSN is built of "nodes" – from a few to several hundreds or even thousands, where each node is connected to one (or sometimes several) sensors. Each such sensor network node has typically several parts: a radio transceiver with an internal antenna or connection to an external antenna, a microcontroller, an electronic circuit for interfacing with the sensors and an energy source, usually a battery or an embedded form of energy harvesting. A sensor node might vary in size from that of a shoebox down to the size of a grain of dust, although functioning "motes" of genuine microscopic dimensions have yet to be created. The cost of sensor nodes is similarly variable, ranging from a few to hundreds of dollars, depending on the complexity of the individual sensor nodes. Size and cost constraints on sensor nodes result in corresponding constraints on resources such as energy, memory, computational speed and communications bandwidth. The topology of the WSNs can vary from a simple star network to an advanced multi-hop wireless mesh network. Figure 2-1 Wireless Sensor Network (WSN)
  • 11. 3 2.1 ZigBee stack Architecture Figure 2-2 Zigbee Stack 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 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 IEEE 802.15.4-2003 standard defines the two lower layers: the physical (PHY) layer and the 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. The application layer framework consists of the application support sub-layer (APS) and the ZigBee device objects (ZDO). Manufacturer-defined application objects use the framework and share APS and security services with the ZDO. 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, used in countries such as the United States and Australia. The higher frequency PHY layer is used virtually worldwide.
  • 12. 4 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.
  • 13. 5 3 Application Layer As shown in Figure 3-1, The ZigBee Application layer consists of the APS sub layer, the ZDO (containing the ZDO management plane), and the manufacturer defined application objects. Figure 3-1 Outline of the ZigBee Stack Architecture 3.1 Application Support Sub-Layer The application support sub-layer (APS) provides an interface between the network layer (NWK) and the application layer (APL) through a general set of services that are used by both the ZDO and the manufacturer-defined application objects. The services are provided by two entities:  The APS data entity (APSDE) through the APSDE service access point (APSDE- SAP).  The APS management entity (APSME) through the APSME service access point (APSME-SAP).  APSDE provides the data transmission service for the transport of application PDUs between two or more devices located on the same network  APSDE supports fragmentation and reassembly of packets and provides reliable data transport
  • 14. 6  APSME provides security services, binding of devices, establishment and removal of group addresses and also maintains a database of managed objects Figure 3-2 The APS Sub-Layer Reference Model The application support sub-layer provides the interface between the network layer and the application layer through a general set of services for use by both the ZigBee device object (ZDO) and the manufacturer-defined application objects. These services are offered via two entities: the data service and the management service. The APS data entity (APSDE) provides the data transmission service via its associated SAP, the APSDE-SAP. The APS management entity (APSME) provides the management service via its associated SAP, the APSME-SAP, and maintains a database of managed objects known as the APS information base (AIB). 3.1.1 Application Support Sub-Layer Data Entity (APSDE) The APSDE shall provide a data service to the network layer and both ZDO and application objects to enable the transport of application PDUs between two or more devices. The devices themselves must be located on the same network. The APSDE will provide the following services:  Generation of the application level PDU (APDU): the APSDE shall take an application PDU and generate an APS PDU by adding the appropriate protocol overhead.  Binding: once two devices are bound, the APSDE shall be able to transfer a message from one bound device to the second device.
  • 15. 7  Group address filtering: this provides the ability to filter group-addressed messages based on endpoint group membership.  Reliable transport: this increases the reliability of transactions above that available from the NWK layer alone by employing end-to-end retries.  Duplicate rejection: messages offered for transmission will not be received more than once.  Fragmentation: this enables segmentation and reassembly of messages longer than the payload of a single NWK layer frame. 3.1.2 Application Support Sub-Layer Management Entity (APSME) The APSME shall provide a management service to allow an application to interact with the stack. The APSME shall provide the ability to match two devices together based on their services and their needs. This service is called the binding service, and the APSME shall be able to construct and maintain a table to store this information. In addition, the APSME will provide the following services:  Binding management: this is the ability to match two devices together based on their services and their needs.  AIB management: the ability to get and set attributes in the device’s AIB.  Security: the ability to set up authentic relationships with other devices through the use of secure keys.  Group management: this provides the ability to declare a single address shared by multiple devices, to add devices to the group, and to remove devices from the group. 3.1.2.1 Service Specification The APS sub-layer provides an interface between a next higher layer entity (NHLE) and the NWK layer. The APS sub-layer conceptually includes a management entity called the APS sub-layer management entity (APSME). This entity provides the service interfaces through which sub-layer management functions may be invoked. The APSME is also responsible for maintaining a database of managed objects pertaining to the APS sub-layer. This database is referred to as the APS sub-layer information base (AIB). Figure 1.2 depicts the components and interfaces of the APS sub-layer.
  • 16. 8 The APS sub-layer provides two services, accessed through two service access points (SAPs). These are the APS data service, accessed through the APS sub-layer data entity SAP (APSDE-SAP), and the APS management service, accessed though the APS sub-layer management entity SAP (APSME-SAP). These two services provide the interface between the NHLE and the NWK layer, via the NLDE-SAP and, to a limited extent, NLME-SAP interfaces. The NLME-SAP interface between the NWK layer and the APS sub-layer supports only the NLME-GET and NLME-SET primitives; all other NLME-SAP primitives are available only via the ZDO. In addition to these external interfaces, there is also an implicit interface between the APSME and the APSDE that allows the APSME to use the APS data service. 3.2 Application Framework The application framework in ZigBee is the environment in which application objects are hosted on ZigBee devices. Up to 240 distinct application objects can be defined, each identified by an endpoint address from 1 to 240. Two additional endpoints are defined for APSDESAP usage: endpoint 0 is reserved for the data interface to the ZDO, and endpoint 255 is reserved for the data interface function to broadcast data to all application objects. Endpoints 241-254 are reserved for future use. 3.3 Application Profiles Application profiles are agreements for messages, message formats, and processing actions that enable developers to create an interoperable, distributed application employing application entities that reside on separate devices. These application profiles enable applications to send commands, request data, and process commands and requests. 3.3.1 Creating a ZigBee Profile The key to communicating between devices on a ZigBee network is agreement on a profile. An example of a profile would be home automation. This ZigBee profile permits a series of device types to exchange control messages to form a wireless home automation application. These devices are designed to exchange well-known messages 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.
  • 17. 9 An example of another type of 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. 3.3.2 ZigBee Profiles  Home Automation  Industrial plant monitoring  Commercial building automation  Automatic meter reading 3.3.3 ZigBee Profiles in Progress  Advanced metering infrastructure  Personal, Home and Hospital Care  Telecom Applications 3.4 Clusters Clusters are identified by a cluster identifier, which is associated with data flowing out of, or into, the device. Cluster identifiers are unique within the scope of a particular application profile. 3.5 Getting a Profile Identifier from the ZigBee Alliance The profile identifier is the main enumeration feature within the ZigBee protocol. Each unique profile identifier defines an associated enumeration of device descriptions and cluster identifiers. For example, for profile identifier .1. There exists a pool of device descriptions described by a 16-bit value (meaning there are 65,536 possible device descriptions within each profile) and a pool of cluster identifiers described by a 16-bit value (meaning there are 65,536 possible cluster identifiers within each profile). Each cluster identifier also supports a pool of attributes described by a 16-bit value. As such, each profile identifier has up to 65,536 cluster identifiers and each of those cluster identifiers contains up to 65,536 attributes. It is the responsibility of the profile developer to define and allocate device descriptions, cluster identifiers, and attributes within their allocated profile identifier. Note that the definition of device descriptions, cluster identifiers, and attribute identifiers must be
  • 18. 10 undertaken with care to ensure efficient creation of simple descriptors and simplified processing when exchanging messages. For public profile identifiers defined within the ZigBee Alliance, a cluster library has been created which provides a common definition and enumeration of clusters and their attributes. The cluster library is designed to sponsor re-use of cluster and attribute definitions across application profiles. By convention, when public profiles employ the cluster library, they will share a common enumeration and definition of cluster and attribute identifiers. Device descriptions and cluster identifiers must be accompanied by knowledge of the profile identifier to be processed. Prior to any messages being directed to a device, it is assumed by the ZigBee protocol that service discovery has been employed to determine profile support on devices and endpoints. Likewise, the binding process assumes similar service discovery and profile matching has occurred, since the resulting match is distilled to source address, source endpoint, cluster identifier, destination address, and destination endpoint. 3.6 The ZigBee Device Profile 3.6.1 Scope 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 clusters. Unlike application specific profiles, the 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 Overview  End Device Bind and Unbind  Binding Table Management  Network Management
  • 19. 11 3.6.2 Device and Service Discovery Overview Device and Service Discovery are distributed operations where individual devices or designated discovery cache devices respond to discovery requests. The device address of interest field enables responses from either the device itself or a discovery cache device. In selected cases where both the discovery cache device and the device address of interest device respond, the response from the device address of interest shall be used.  Device Discovery: Provides the ability for a device to determine the identity of other devices on the PAN. Device Discovery is supported for both the 64-bit IEEE address and the 16-bit Network address. 3.6.3 End Device Bind Overview The following capabilities exist for end device bind:  End Device Bind: Provides the ability for an application to support a simplified method of binding where user intervention is employed to identify command/control device pairs. Typical usage would be where a user is asked to push buttons on two devices for installation purposes. Using this mechanism a second time allows the user to remove the binding table entry. 3.6.4 Bind and Unbind Overview The following capabilities exist for directly configuring binding table entries:  Bind: provides the ability for creation of a Binding Table entry that maps control messages to their intended destination.  Unbind: provides the ability to remove Binding Table entries. 3.6.5 Binding Table Management Overview The following capabilities exist for management of binding tables:  Registering devices that implement source binding: Provides the ability for a source device to instruct its primary binding table cache to hold its own binding table.  Replacing a device with another wherever it occurs in the binding table: Provides the ability to replace one device for another, by replacing all instances of its address in the binding table.
  • 20. 12  Backing up a binding table entry: Provides the ability for a primary binding table cache to send details of a newly created entry to the backup binding table cache (after receiving a bind request).  Removing a backup binding table entry 3.7 ZigBee Device Objects The ZigBee device objects (ZDO), represent a base class of functionality that provides an interface between the application objects, the device profile, and the APS. The ZDO is located between the application framework and the application support sub-layer. It satisfies common requirements of all applications operating in a ZigBee protocol stack. The ZDO is responsible for the following:  Initializing the application support sub-layer (APS), the network layer (NWK), and the Security Service Provider.  Assembling configuration information from the end applications to determine and implement discovery, security management, network management, and binding management. The ZDO presents public interfaces to the application objects in the application framework layer for control of device and network functions by the application 3.7.1 Scope This section describes the concepts, structures, and primitives needed to implement a ZigBee Device Objects application on top of a ZigBee Application Support Sub-layer and ZigBee Network Layer. ZigBee Device Objects are applications which employ network and application support layer primitives to implement ZigBee End Devices, ZigBee Routers, and ZigBee Coordinators. The ZigBee Device Object Profile employs Clusters to describe its primitives. The ZigBee Device Profile Clusters do not employ attributes and are analogous to messages in a message transfer protocol. Cluster identifiers are employed within the ZigBee Device Profile to enumerate the messages employed within ZigBee Device Objects. ZigBee Device Objects also employ configuration attributes. The configuration attributes within ZigBee Device Objects are configuration parameters set by the application or stack profile. The configuration attributes are also not related to the ZigBee Device Profile,
  • 21. 13 though both the configuration attributes and the ZigBee Device Profile are employed with ZigBee Device Objects. 3.7.2 Device Object Descriptions 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 as illustrated in Figure 1.1. The ZigBee Device Objects are responsible for the following functions:  Initializing the Application Support Sub layer (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. 3.8 Advantages of ZigBee  Low power consumption  Low cost  Supports large network orders (<= 65k nodes)  Low to no QoS guarantees  Flexible protocol design suitable for many applications 3.9 Disadvantages  low data rate  short range communications 3.10 Application of ZigBee This technology includes application segments in home control: wireless home security, remote thermostats, remote lighting, drape controller, automated meter reading, personal healthcare and advanced tagging, call button for elderly and disabled, universal remote controller to TV and radio, lighting, wireless keyboard, mouse and game pads, wireless smoke, CO detectors, etc.
  • 22. 14 4 Network (NWK) Layer Network layer provides functionalities required for the correct operation of application layer. Application layer and network layer are connected with the help of service entities provided by network layer. Services entities provided by the network layer to interface with application layer are Network layer data entity (NLDE): provides data services, Network layer management entity (NLME): provides management services. Data and management entities provide services through their service access points (SAP) NLDE-SAP & NLME-SAP respectively. These two services provide the interface between the application and the MAC sub- layer, via the MCPS-SAP and MLME-SAP interfaces. In addition to these external interfaces, there is also an implicit interface between the NLME and the NLDE that allows the NLME to use the NWK data service. Similar to Application Information Base (AIB) NWK layer also maintains an information base called Network Information Base (NIB). NIB comprises of attributes required to manage NWK layer. Figure 4-1 Network layer Network layer data entity (NLDE): NLDE provides data services to applications to send application protocol data units (APDU) to other devices present in the same network. 4.1 Services provided by NLDE: 1) Generation of network level PDU (NPDU): Adds appropriate header for APDU 2) Topology specific routing: Transmits a NPDU to other device using attributes of NIB.
  • 23. 15 3) Security: Provides network keys for the encryption for data that is being transmitted. 4.1.1 Service specifications: NLDE-SAP Primitives are the specification for services provided by NLDE. NLDE-DATA.request primitive: this primitive is used for requesting transfer of NPDU for local APS sub layer entity to single or multiple application entities residing on different devices of same network. It is generated by local APS sub layer entity whenever a data PDU (NSDU) is to be transferred to a peer APS sub layer entity. NLDE-DATA.confirm Primitives: this primitive is used as a response on the reception of NLDE-DATA.request primitive. This primitive consists of status of NLDE-DATA.request primitive, and it indicates the reason for failure of not providing data that NLDE- DATA.request primitive requesting. NLDE-DATA.indication primitive: this primitive is generated by NLDE issued by APS sub layer for sending data to peer APS sub layer entity up on reception for appropriately addressed data frame from the local MAC sub layer entity. Network layer management entity (NLME): The NWK layer management entity SAP (NLME-SAP) allows the transport of management commands between the next higher layer and the NLME. 4.2 Service provided by NLME: 1) Configuring the new device: beginning an operation as Zigbee coordinator or end device. 2) Start a network: establishing a network. 3) Joining, rejoining and leaving a network. 4) Addressing: assigns 16-bit network address to the devices which join in the network. These addresses are unique in the network only. Zigbee coordinator or router has the capability to assign network address. 5) Neighbour discovery: discovers, records and reports information about one hope neighbours of the device for routing purpose. 6) Route discovery: discovers and records path through which a packet can be routed efficiently. 7) Reception control: controlling the receiver and enabling MAC sub layer synchronization.
  • 24. 16 8) Routing: routing mechanism for uncasing, broadcasting and multicasting efficiently. 4.2.1 Service specifications: NLME-SAP Primitives are the specifications for the services provided by NLME. NLME-NETWORK-DISCOVERY.request & confirm primitives: Request primitive allows the next higher layer to request that the NWK layer discover networks currently operating within the range. NLME-NETWORK-DISCOVERY.confirm primitive is used as a response to the NLME-NETWORK DISCOVERY.request primitive. Figure 4-2 NWK Discovery Sequence NLME-NETWORK-FORMATION.request & confirm: Request primitive allows the next higher layer to request that the device start a new Zigbee network with itself as the coordinator and subsequently make changes to its superframe structure. Confirm primitive reports the results of the request to initialize a Zigbee coordinator in a network. Confirm primitive returns a status value of INVALID_REQUEST, STARTUP_FAILURE or any status value returned from the MLME-START.confirm primitive.
  • 25. 17 Figure 4-3 NWK Formation Sequence NLME-PERMIT-JOINING.request & confirm primitive: Request primitive is used by Zigbee coordinator or router to set its MAC sub-layer association permit flag for a fixed period when it may accept devices onto its network. Confirm primitive is transmitted as acknowledgement for the NLME-PERMIT-JOINING.request primitive. NLME-START-ROUTER.request & confirm primitives: request primitive is used by Zigbee router for routing data frames, route discovery and accepting network joining request joining from other devices. Confirm primitive is used as response for the NLME-START- ROUTER.request primitive. NLME-ED-SCAN.request & confirm primitive: request primitive is used for doing energy scan to evaluate the channels available to it. Confirm primitive is for the response NLME- ED-SCAN.request primitive.
  • 26. 18 NLME-JOIN.request, indication & confirm primitives: request primitive is for rejoining the network or to change the operating channel for the device while within an operating network. This primitive can also be orphan notification. Indication primitive is for informing that rejoin into the network was done successfully. Confirm primitive is for notifying the higher layer about result of NLME-JOIN.request primitive. NLME-DIRECT-JOIN.request & confirm primitive: request primitive for joining to devices directly so that they can communicate directly with out the intervention of coordinator or router. Confirm primitive for acknowledging the device which requested the direct join with other device. NLME-LEAVE.request, indication & confirm primitives: request primitive is for notifying the other device that it or some other device is about to leave the network. Indication primitive is for notifying higher layer of Zigbee devices that it or neighbor Zigbee device had left the network. Confirm primitive is for notifying higher layer of initiating device about itself or neighbor device leaving the network request. NLME-RESET.request & confirm primitive: request primitive is to perform reset operation or resume operation according to its current NIB values prior to this primitive being issued. Confirm primitive is to notify the result of NLME-RESET.request primitive. NLME-GET & SET primitives: these primitives for used for getting and setting attributes of NIB. NLME-NWK-STATUS.indication primitive: this is generated when a device failed to discover or route to destination, failed to deliver data frame to destination. NLME-ROUTE-DISCOVERY.request & confirm primitive: request primitive is for initiating the route discovery. This primitive is generated by Zigbee coordinator or router only. Confirm primitive is for notifying results of an attempt to initiate route discovery.
  • 27. 19 There are basically 2 types of frames generated by network layer. They are 1) Data frames 2) NWK command frames Data frames are nothing but NLDE primitives and NWK command frames are NLME primitives. 4.3 NWK Information Base (NIB) The NWK information base (NIB) comprises the attributes required to manage the NWK layer of a device. Each of these attributes can be read or written using the NLME- GET.request and NLME-SET.request primitives, respectively, except for attributes for which the Read Only column contains a value of Yes. In that case, the attributes value may be read using the NLME GET.request primitive but may not be set using the NLME-SET.request primitive. Generally, these read only attribute are set using some other mechanism.
  • 28. 20 5 Routing Protocol for WSN The applications of wireless sensor networks comprise a wide variety of scenarios. In most of them, the network is composed of a significant number of nodes deployed in an extensive area in which not all nodes are directly connected. Then, the data exchange is supported by multi hop communications. Routing protocols are in charge of discovering and maintaining the routes in the network. However, the appropriateness of a particular routing protocol mainly depends on the capabilities of the nodes and on the application requirements. Wireless Sensor Networks (WSN) is intended for monitoring an environment. The main task of a wireless sensor node is to sense and collect data from a certain domain, process them and transmit it to the sink where the application lies. However, ensuring the direct communication between a sensor and the sink may force nodes to emit their messages with such a high power that their resources could be quickly depleted. Therefore, the collaboration of nodes to ensure that distant nodes communicate with the sink is a requirement. In this way, messages are propagated by intermediate nodes so that a route with multiple links or hops to the sink is established. Taking into account the reduced capabilities of sensors, the communication with the sink could be initially conceived without a routing protocol. With this premise, the flooding algorithm stands out as the simplest solution. In this algorithm, the transmitter broadcasts the data which are consecutively retransmitted in order to make them arrive at the intended destination. However, its simplicity brings about significant drawbacks. Firstly, an implosion is detected because nodes redundantly receive multiple copies of the same data message. Then, as the event may be detected by several nodes in the affected area, multiple data messages containing similar information are introduced into the network. Moreover, the nodes do not take into account their resources to limit their functionalities. 5.1 Ad hoc On-Demand Distance Vector Routing Ad hoc On-Demand Distance Vector (AODV) Routing is a routing protocol for mobile ad hoc networks (MANETs), Wireless Sensor Networks (WSN) and other wireless ad hoc networks. 5.1.1 Working In AODV, the network is silent until a connection is needed. At that point the network node that needs a connection broadcasts a request for connection. Other AODV nodes forward this message, and record the node that they heard it from, creating an explosion of temporary routes back to the needy node. When a node receives such a message and already has a route to the desired node, it sends a message backwards through a temporary route to the requesting node. The needy node then begins using the route that has the least number of hops through other nodes. Unused entries in the
  • 29. 21 routing tables are recycled after a time. When a link fails, a routing error is passed back to a transmitting node, and the process repeats. Much of the complexity of the protocol is to lower the number of messages to conserve the capacity of the network. For example, each request for a route has a sequence number. Nodes use this sequence number so that they do not repeat route requests that they have already passed on. Another such feature is that the route requests have a "time to live" number that limits how many times they can be retransmitted. Another such feature is that if a route request fails, another route request may not be sent until twice as much time has passed as the timeout of the previous route request. The advantage of AODV is that it creates no extra traffic for communication along existing links. Also, distance vector routing is simple, and doesn't require much memory or calculation. However AODV requires more time to establish a connection, and the initial communication to establish a route is heavier than some other approaches. Figure 5-1 AODV Messaging Protocol 5.1.2 Advantages and disadvantages The main advantage of this protocol is having routes established on demand and that destination sequence numbers are applied to find the latest route to the destination. The connection setup delay is lower. One disadvantage of this protocol is that intermediate nodes can lead to inconsistent routes if the source sequence number is very old and the intermediate nodes have a higher but not the latest destination sequence number, thereby having stale entries. Also, multiple RouteReply packets in response to a single RouteRequest packet can lead to heavy control overhead. Another disadvantage of AODV is unnecessary bandwidth consumption due to periodic beaconing.
  • 30. 22 6 ZigBee and IEEE 802.15.4 6.1 Introduction: Wireless sensor networking is one of the most exciting technology markets today. Over the next five to ten years, wireless sensors will have a significant impact on almost all major industries as well as our home lives. Figure 6-1 ZigBee module ZigBee has been introduced by IEEE with IEEE 802.15.4 standard and the ZigBee Alliance to provide the first general standard for these applications. The ZigBee alliance includes such companies as Invensys, Honeywell, Mitsubishi Electric, Motorola, and Philips. ZigBee is built on the robust radio (PHY) and medium attachment control (MAC) communication layers defined by the IEEE 802.15.4 standard. Above this ZigBee defines mesh, star and cluster tree network topologies with data security features and interoperable application profiles.
  • 31. 23 Figure 6-2 Data rate Vs Range ZigBee looks rather like Bluetooth but is simpler, has a lower data rate and spends most of its time snoozing. It is now widely recognized that standards such as Bluetooth and WLAN are not suited for low power applications, which is due to these standards high node costs as well as complex and power demanding RF-ICs and protocols. Figure 6-3 ZigBee 802.15.4 Specifications With Zigbee, the case is different, it is the only standard that specifically addresses the needs of wireless control and monitoring applications.
  • 32. 24 Figure 6-4 Wireless Standard Comparisons 6.2 General Characteristics IEEE 802.15.4-2003 standard defines the protocol and interconnection of devices via radio communication in a personal area network (PAN). IEEE 802.15.4 standard defines the characteristics of the physical and MAC layers for LRWPANs. Zigbee builds upon the IEEE 802.15.4 standard and defines the network layer specifications and provides a framework for application programming in the application layer.
  • 33. 25 Figure 6-5 ZigBee device construction 6.3 LR-WPAN Device Architecture Figure 6-6 Figure 2-1shows an LR-WPAN device. The device comprises a PHY, which contains the radio frequency (RF) transceiver along with its low-level control mechanism, and a MAC sub layer that provides access to the physical channel for all types of transfer. The upper layers consists of a network layer, which provides network configuration, manipulation, and message routing, and application layer, which provides the intended function of a device. An IEEE 802.2 logical link control (LLC) can access the MAC sub layer through the service specific convergence sub layer (SSCS). Figure 6-6 LR-WPAN device architecture
  • 34. 26 6.4 IEEE 802.15.4 PHY Layer The PHY provides two services: the PHY data service and PHY management service interfacing to the physical layer management entity (PLME). The PHY data service enables the transmission and reception of PHY protocol data units (PPDU) across the physical radio channel. The features of the PHY are activation and deactivation of the radio transceiver, energy detection (ED), link quality indication (LQI), channel selection, clear channel assessment (CCA) and transmitting as well as receiving packets across the physical medium. The standard offers two PHY options based on the frequency band. Both are based on direct sequence spread spectrum (DSSS). The data rate is 250kbps at 2.4GHz, 40kbps at 915MHz and 20kbps at 868MHz. The higher data rate at 2.4GHz is attributed to a higher-order modulation scheme. Lower frequency provides longer range due to lower propagation losses. Low rate can be translated into better sensitivity and larger coverage area. Higher rate means higher throughput, lower latency or lower duty cycle. Figure 6-7 Frequency bands and data rates There is a single channel between 868 and 868.6MHz, 10 channels between 902.0 and 928.0MHz, and 16 channels between 2.4 and 2.4835GHz. Several channels in different frequency bands enable the ability to relocate within spectrum. The standard also allows dynamic channel selection, a scan function that steps through a list of supported channels in search of beacon, receiver energy detection, link quality indication, channel switching.
  • 35. 27 Figure 6-8 IEEE 802.15.4 channel structure Figure 6-9 IEEE 802.15.4 PHY layer 6.5 IEEE 802.15.4 MAC Layer The MAC sub layer provides two services: the MAC data service and the MAC management service interfacing to the MAC sub layer management entity (MLME) service access point (SAP) (MLMESAP). The MAC data service enables the transmission and reception of MAC protocol data units (MPDU) across the PHY data service. The features of MAC sub layer are beacon management, channel access, GTS management, frame validation, acknowledged frame delivery, association and disassociation.
  • 36. 28 Figure 6-10 IEEE 82.15.4 ZigBee protocol architecture The MAC layer, defined in IEEE 802.15.4, provides an interface between the physical layer and the higher layer protocols. It handles all access to the physical radio channel and is responsible for the following tasks:  Generating network beacons if the device is a coordinator  Synchronizing to the beacons  Supporting PAN association and disassociation  Supporting device security  Employing the CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) mechanism for channel access  Handling and maintaining the GTS mechanism  Providing a reliable link between two peer MAC entities The MAC protocol supports two operational modes that may be selected by the coordinator: Beacon-enabled and Non Beacon-enabled mode, see the below Figure 6-11.
  • 37. 29 Figure 6-11 IEEE 802.15.4 operational modes 6.6 Network Topology The ZigBee network layer (NWK) supports star, tree, and mesh topologies. In a star topology, the network is controlled by one single device called the ZigBee coordinator. The ZigBee coordinator is responsible for initiating and maintaining the devices on the network. All other devices, known as end devices, directly communicate with the ZigBee coordinator. In mesh and tree topologies, the ZigBee coordinator is responsible for starting the network and for choosing certain key network parameters, but the network may be extended through the use of ZigBee routers. In tree networks, routers move data and control messages through the network using a hierarchical routing strategy. Tree networks may employ beacon-oriented communication as described in the IEEE 802.15.4-2003 specification. Mesh networks allow full peer-to-peer communication. ZigBee routers in mesh networks do not currently emit regular IEEE 802.15.4-2003 beacons. This specification describes only intra-PAN networks, that is, networks in which communications begin and terminate within the same network.
  • 38. 30 7 Z-stack component APIs Components of Z-stack whose APIs will be explained in this document are 1. Zigbee Device Object(ZDO) 2. Application Framework(AF) 3. Application support sub layer(APS) 4. Network Layer(NWK) 7.1 Zigbee Device Object (ZDO): The Zigbee Device Objects (ZDO) layer provides functionality for managing a Zigbee device. The ZDO API provides the interface for application endpoints to manage functionality for Zigbee Coordinators, Routers, or End Devices. ZDP provides the following functionality to the ZDO and applications: 1. Device Network Startup 2. Device and Service Discovery 3. End Device Bind, Bind and Unbind Service 4. Network Management Service 7.1.1 Device Network Startup APIs: By default ZDApp_Init() [in ZDApp.c] starts the device’s startup in a Zigbee network, but an application can override this default behavior. For the application to take control of the device network start it must include HOLD_AUTO_START as a compile option and it is recommended that it also include the NV_RESTORE compile option (to save the Zigbee Network State in NV). If the device includes these compile flags it will need to call ZDOInitDevice() to start the device in the network. ZDOInitDevice(): Start the device in the network. This function will read ZCD_NV_STARTUP_OPTION (NV item) to determine whether or not to restore the network state of the device. To call this function the device MUST have the compile flag HOLD_AUTO_START compiled in. ZDO_RegisterForZDOMsg(): Call this function to request an over-the-air message. A copy of the message will be sent to a task in an OSAL message. The task receiving the message can either parse the message themselves or call a ZDO Parser function to parse the message. Only response messages have a ZDO Parser function. ZDO_RemoveRegisteredCB(): Call this function to remove a request for an over-the-air message.
  • 39. 31 7.1.2 Device and Service Discovery APIs: ZDP_NwkAddrReq():Calling this function will generate a message to ask for the 16 bit address of the Remote Device based on its known IEEE address. This message is sent as a broadcast message to all devices in the network. ZDP_NWKAddrRsp():This is actually a macro that calls ZDP_AddrRsp(). This call will build and send a Network Address Response. ZDP_IEEEAddrReq():Calling this function will generate a message to ask for the 64 bit address of the Remote Device based on its known 16 bit network address. ZDP_IEEEAddrRsp():This is actually a macro that calls ZDP_AddrRsp(). This call will build and send a IEEE Address Response. ZDP_NodeDescReq():This is actually a macro that calls ZDP_NWKAddrOfInterestReq(). This call will build and send a Node Descriptor Request to the Remote Device specified in t he destination address field. ZDP_MatchDescReq(): This call will build and send a Match Descripton Request. Use this function to search for devices/applications that match something in the input/output cluster list of an application. ZDP_MatchDescRsp(): This is a macro that calls ZDP_EPIFRsp(). Call this function to respond to the Match Description Request. ZDP_ServerDiscReq(): The function builds and sends a System_Server_Discovery_req request message which contains a 16 bit server mask. The purpose o f this request is to discover the locations of a particular system server or servers as indicated by the server mask. The message is broadcast to all devices with RxOnWhenIdle. Remote devices will send responses back only if a match bit is found when comparing the received server mask with the mask stored in the local node descriptor, using unicast transmission. ZDP_ServerDiscRsp(): The function builds and sends back System_Server_Discovery_rsp response. It will be called when a System_Server_Discovery_req is received and a match is found for the server bit mask. 7.1.3 End device Bind, Bind and Unbind Service APIs: ZDP_EndDeviceBindReq():This call will build and send an End Device Bind Request (“Hand Binding”). Send this message to attempt a hand bind for this device. After hand binding your can send indirect (no address) message to the coordinator and the coordinator will send the message to the device that this message is bound to, or you will receive messages from your new bound device.
  • 40. 32 ZDP_EndDeviceBindRsp():This is a macro that calls ZDP_SendData () directly. Call this function to respond to the End Device Bind Request. ZDP_BindReq():This is actually a macro that calls ZDP_BindUnbindReq (). This call will build and send a Bind Request. Use this function to request the Zigbee Coordinator to bind application based on clusterID. ZDP_BindRsp():This is a macro that calls ZDP_SendData () directly. Call this function to respond to the Bind Request. ZDP_UnbindReq ():This is actually a macro that calls ZDP_BindUnbindReq (). This call will build and send a Unbind Request. Use this function to request the Zigbee Coordinator’s removal of a binding. ZDP_UnbindRsp():This is a macro that calls ZDP_SendData () directly. Call this function to respond to the Unbind Request. 7.1.4 Network Management Service APIs: The ZDO Management API builds and sends ZDO Management requests and responses. These messages are used to get device status and update tables. The table below lists the Management API supported by the stack and their corresponding command name in ZigBee Specification. ZDP_MgmtNwkDiscReq():If the device supports this command (optional), calling this function will generate the request for the destination device to perform a network scan. The calling application can only call this function if the ZDO_MGMT_NWKDISC_REQUEST compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtNwkDiscRsp():If the device supports this command (optional), calling this function will generate the response. The ZDO will generate this message automatically when a “Management Network Discovery Request” message is received if the ZDO_MGMT_NWKDISC_RESPONSE compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtLqiReq(): If the device supports this command (optional), calling this function will generate the request for the destination device to return its neighbor list. The calling application can only call this function if the ZDO_MGMT_LQI_REQUEST compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtLqiRsp(): If the device supports this command (optional), calling this function will generate the response. The ZDO will generate this message automatically when a “Management LQI Request” message is received if the ZDO_MGMT_LQI_RESPONSE compile flag is set either in ZDConfig.h or as a normal compile flag.
  • 41. 33 ZDP_MgmtBindReq (): If the device supports this command (optional), calling this function will generate the request for the destination device to return its Binding Table. The calling application can only call this function if the ZDO_MGMT_BIND_REQUEST compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtBindRsp(): If the device supports this command (optional), calling this function will generate the response. The ZDO will generate this message automatically when a “Management Binding Request” message is received if the ZDO_MGMT_BIND_RESPONSE compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtLeaveReq (): If the device supports this command (optional), calling this function will generate the request for the destination device to leave the network or request another device to leave. The calling application can only call this function if the ZDO_MGMT_LEAVE_REQUEST compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtLeaveRsp(): If the device supports this command (optional), calling this function will generate the response. The ZDO will generate this message automatically when a “Management Leave Request” message is received if the ZDO_MGMT_LEAVE_RESPONSE compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtDirectJoinReq (): If the device supports this command (optional), calling this function will generate the request for the destination device to direct join another device. The calling application can only call this function if the ZDO_MGMT_JOINDIRECT_REQUEST compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtDirectJoinRsp(): If the device supports this command (optional), calling this function will generate the response. The ZDO will generate this message automatically when a “Management Direct Join Request” message is received if the ZDO_MGMT_JOINDIRECT_RESPONSE compile flag is set either in ZDConfig.h or as a normal compile flag. ZDP_MgmtPermitJoinReq(): This is a macro that calls ZDP_SendData () directly. The function builds and sends Mgmt_Permit_Joining_req to request a remote device to allow or disallow association. The request is normally generated by a commissioning tool or network management device. Additionally, if field TC_Significance is set to 0x01 and the remote device is the trust center, the trust center authentication policy will be affected. ZDP_MgmtPermitJoinRsp(): This is a macro that calls ZDP_SendData () directly. If the device supports this command (optional), calling this function will generate the response for Mgmt_Permit_Joining_req request. The ZDO will generate this message automatically when an
  • 42. 34 Mgmt_Permit_Joining_req message is received if the ZDO_MGMT_PERMIT_JOIN_RESPONSE compile flag is set either in ZDConfig.h or as a normal compile flag. 7.2 Application Framework (AF) The Application Framework layer is the application’s over-the-air data interface to the APS layer. It contains the functions an application uses to send data out over the air (through the APS and NWK) layers. This layer is also the endpoint multiplexer for incoming data messages. The AF provides the following functionality to applications: 1. Endpoint Management 2. Sending and Receiving Data 7.2.1 Endpoint Management APIs: Each device is a node in the Zigbee. Each node has a long and short address, the short address of the node is used by other nodes to send it data. Each node has 241 endpoint (0 reserved, 1 240 application assigned). Each endpoint is separately addressable; when a device sends data it must specify the destination node’s short address and the endpoint that will receive that data. An application must register one or more endpoints to send and receive data in a Zigbee network. afRegister():This function serves the same function as afRegister() [to register an endpoint], but this function specifies a callback function to be called when the endpoint’s simple descriptor is queried. This will allow an application to dynamically change the simple descriptor and not use the RAM/ROM needed to store the descriptor. afFindEndPointDesc():Use this function to find an endpoint descriptor from an endpoint. afFindSimpleDesc():Use this function to find an endpoint descriptor from an endpoint. afGetMatch():By default, the device will respond to the ZDO Match Descriptor Request. You can use this function to get the setting for the ZDO Match Descriptor Response. afSetMatch():By default, the device will respond to the ZDO Match Descriptor. You can use this function to change this behavior. For example, if the endpoint parameter is 1 and action is false, the ZDO will not respond to a ZDO Match Descriptor Request for endpoint 1. afNumEndPoints():Use this function to lookup the number of endpoints registered. afEndPoints ():This function will return an array of endpoints registered. It fills in the parsein buffer (epBuf) with the endpoint (numbers). Use afNumEndPoints() to find out how big a buffer to supply in
  • 43. 35 epBuf. For example, if your application registered 2 endpoints (endpoint 10 and endpoint 15) and skipZDO is true, the array (epBuf) will contain 2 bytes (10 & 15). AF_DataRequest():Call this function to send data. afDataReqMTU():Use this function to find the maximum number of data bytes that can be sent based on the input parameters. 7.3 Application Support Sub layer (APS) The APS provides the following management functionality accessible to the higher layers: 1. Binding Table Management 2. Group Table Management 3. Quick Address Lookup 7.3.1 Binding Table Management APIs: bindAddEntry():Use this function to add an entry into the binding table. Since each table entry can have multiple cluster IDs, this function may just add a cluster ID(s) to an existing binding table record. bindRemoveEntry():Remove a binding entry from the binding table. bindRemoveClusterIdFromList():This function removes a cluster ID from the cluster ID list of an existing binding table entry. This function assumes that the passed in entry is valid. bindAddClusterIdToList():This function will add a cluster ID to the cluster ID list of an existing binding table entry. This function assumes that the passed in entry is valid. bindRemoveDev():Use this function to remove all binding table entries with the passed in address. If the address matches either source or destination address in the binding record the entry will be removed. bindRemoveSrcDev():Use this function to remove all binding table entries with the passed in source address and endpoint. bindUpdateAddr ():Use this function to count exchange short addresses in the binding table. All entries with the oldAddr will be replaced with newAddr. bindFindExisting ():Find an existing binding table entry. Using a source address, endpoint, destination address and endpoint to search the binding table.
  • 44. 36 bindIsClusterIDinList():Checks for a cluster ID in the cluster ID list of a binding table entry. This function assumes that the passed in entry is valid. BindWriteNV():This function will write the binding table to non-volatile memory, to be called if the user application changes anything in the binding table (add, remove or change). If the binding table is updated normally through ZDO messages, the function will be called by ZDO and doesn’t need to be called by the user application. 7.3.2 Group Table Management APIs aps_AddGroup():Call this function to add a group into the group table. Define an aps_Group_t item, fill it in, then call this function. If NV_RESTORE is enabled, this function will save the update in non-volatile memory. aps_ RemoveGroup():Call this function to remove a group from the group table. If NV_RESTORE is enabled, this function will save the update in non-volatile memory. aps_ RemoveAllGroup (): Call this function to remove all groups for a given endpoint from the group table. If NV_RESTORE is enabled, this function will save the update in non-volatile memory. aps_ FindGroup (): Call this function to find a group in the group table for an endpoint and group ID. aps_ FindAllGroupsForEndpoint(): Call this function to get a list of all endpoints belong to a group. The caller must provide the space to copy the groups into. aps_ CountGroups(): Call this function to get a count of the number of groups that a given endpoint belongs. aps_ CountAllGroups (): Call this function to get the number of entries in the group table. aps_GroupsWriteNV(): This function will write the group table to non-volatile memory, and is to be called if the user application changes anything in a group table entry (other than add, remove or remove all). If the group table is updated normally through group add, remove or remove all functions, there is no need to call this function. 7.3.3 Quick Address Lookup APIs: The APS provides a couple of functions to provide quick address conversion (lookup). These functions allow you to convert from short to IEEE address (or IEEE to short) if the lookup has already been done and stored in the address manager (ref. network layer) or if it’s your own address. APSME_LookupExtAddr(): This function will look up the extended (IEEE) address based on a network (short) address if the address is already in the Address Manager. It does NOT start a network (over-the-air) IEEE lookup.
  • 45. 37 APSME_ LookupNwkAddr (): This function will look up the network (short) address based on a extended (IEEE) address if the address is already in the Address Manager. It does NOT start a network (over-the-air) short address lookup. 7.4 Network Layer(NWK) The NWK provides the following functionality accessible to the higher layers: 1. Network Management 2. Address Management 3. Network Variables and Utility Functions 7.4.1 Network Management APIs NLME_NetworkDiscoveryRequest(): This function requests the network layer to discover neighboring routers. This function should be called before joining to perform a network scan. The scan confirm (results) will be returned in ZDO_NetworkDiscoveryConfirmCB() callback. NLME_NwkDiscReq2(): This function requests the network layer to discover neighboring routers. Use this function to perform a network scan but you are NOT expecting to join. The scan confirm (results) will be returned in ZDO_NetworkDiscoveryConfirmCB() callback. After the callback (results), call NLME_NwkDiscTerm() to clean up this action. NLME_NwkDiscTerm(): This function will clean up the NLME_NwkDiscReq2() action. NLME_NetworkFormationRequest(): This function allows the next higher layer to request that the device form a new network and become the Zigbee Coordinator for that network. The result of this action (status) is returned to the ZDO_NetworkFormationConfirmCB() callback. NLME_StartRouterRequest(): This function allows the next higher layer to request that the device to start functioning as a router. The result of this action (status) is returned to the ZDO_StartRouterConfirmCB() callback. It is best not to use this function directly and instead use ZDO_StartDevice(). NLME_JoinRequest(): This function allows the next higher layer to request that the device to join itself to a network. The result of this action (status) is returned to the ZDO_JoinConfirmCB() callback. NLME_ReJoinRequest(): Use this function to rejoin a network that this device has already been joined to. The result of this action (status) is returned to the ZDO_JoinConfirmCB() callback.
  • 46. 38 NLME_OrphanJoinRequest(): This function requests the network layer to orphan join into the network. This function is a scan with an implied join. The result of this action (status) is returned to the ZDO_JoinConfirmCB() callback. NLME_PermitJoiningRequest(): This function defines how the next higher layer of a coordinator or router device may permit devices to join its network for a fixed period. NLME_DirectJoinRequest(): This function allows the next higher layer to request the NWK layer on a router or coordinator device to add another device as its child device. NLME_LeaveReq(): This function allows the next higher layer to request that it or another device leaves the network. Currently, calling this function will NOT cause the parent of the leaving device to re-allocate the device’s address. NLME_RemoveChild(): This function allows the next higher layer to request that. NwkPollReq(): Call this function to manually request a MAC data request. This function is for end devices only. Normally, for end devices, the polling is automatically handled by the network layer and the application can manipulate the poll rate by calling NLME_SetPollRate(). If the poll rate is set to 0, the application can manually do the polls by call this function. NLME_SetPollRate(): Use this function to set/change the Network Poll Rate. This function is for end devices only. Normally, for end devices, the polling is automatically handled by the network layer and the application can manipulate the poll rate by calling NLME_SetPollRate(). NLME_SetQueuedPollRate():Use this function to set/change the Queued Poll Rate. This function is for end devices only. If a poll for data results in a data message, the poll rate is immediately set to the Queued Poll Rate to drain the parent of queued data. NLME_SetResponseRate(): Use this function to set/change the Response Poll Rate. This function is for end devices only. This is the poll rate after sending a data request, the idea being that we are expecting a response quickly (instead of wait the normal poll rate). 7.4.2 Network Variables and Utility APIs NLME_GetExtAddr(): This function will return a pointer to the device's IEEE 64 bit address. NLME_GetShortAddr(): This function will return the device's network (short - 16 bit) address.
  • 47. 39 NLME_GetCoordShortAddr(): This function will return the device's parent’s network (short – 16 bit) address. This is NOT the Zigbee Coordinator’s short address (it’s always 0x0000). In MAC terms, the parent is called a coordinator. NLME_GetCoordExtAddr(): This function will get the device's parent’s IEEE (64 bit) address. This is NOT the Zigbee Coordinator’s extended address. In MAC terms, the parent is called a coordinator. NLME_SetRequest(): This function allows the next higher layer to set the value of a NIB (network information base) attribute. NLME_GetRequest(): This function allows the next higher layer to get the value of a NIB (network information base) attribute. NLME_IsAddressBroadcast(): Based on device capabilities this function evaluates the supplied address and determines whether it is a valid broadcast address for this device given its capabilities. NLME_GetProtocolVersion(): This function uses the GET API access to the NIB to retrieve the current protocol version. NLME_SetBroadcastFilter(): This function sets a bit mask based on the capabilities of the device. It will be used to process valid broadcast addresses. NLME_UpdateNV(): This function will write the NIB to non-volatile memory, and is to be called if the user application changes anything in the NIB. If the NIB is updated normally through joining, there is no need to call this function.
  • 48. 40 8 Compiling options for Zigbee stack IAR WorkBench EW8051 is used for compiling Zigbee stack 8.1 Selecting logical device type: Zigbee devices can be configured in one of three ways: 1. Zigbee Coordinator – This device is configured to start the IEEE 802.15.4 network and will serve as the PAN Coordinator in that network. 2. Zigbee Router – This device is configured to associate with a Zigbee Coordinator, then allow other routers or end devices to associate with it. It will route data packets in the network. 3. Zigbee End Device – This device is configured to join a pre-existing network and will associate with a Zigbee Coordinator or Zigbee Router. 8.2 Compile options for a specific project are located in two places. 1. Options that are rarely, if ever, changed are located in linker control files, one for each logical device type discussed above. Path: C:Texas InstrumentsZStack-1.4.3-1.2.1ProjectszstackToolsCC2430DB 2. User-defined options and ones that change to enable/disable features are located in the IAR project file. 8.2.1 Compile Options In IAR Project Files: The compile options for each of the supported configurations are stored in location C:Texas InstrumentsZStack-1.4.3-1.2.1ProjectszstackSamplesGenericAppCC2430DB a file with ewp extension. To modify the compile options, select the Options… item from the Project pull-down menu. Select the C/C++ Compiler item and click on the Preprocessor tab. The compile options for this configuration are located in the box labeled Defined symbols: (one per line):
  • 49. 41 Figure 8-1 Compiling options To add a compile option to this configuration, simply add the item on a new line within this box. To disable a compile option, place an x at the left edge of the line. Note that the MT_ZDO_FUNC option has been disabled in the example shown above. This option could have been deleted but this is not recommended since it might need to be re-enabled at a later time. 8.3 Using compiling options: Compile options are used to select between features that are provided in the source files. Most compile options act as on/off switches for specific sections within source programs. Some options are used to provide a user-defined numerical value, such as DEFAULT_CHANLIST, to the compiler to override default values. Each of the Z-Stack projects provides an IAR project file which specifies the compile options to be used for that specific project. The programmer can add or remove options as needed to include or exclude portions of the available software functions. Note that changing compile options may require other changes to the project file. 8.3.1 General compile options and definitions: BLINK_LEDS: Enable extended LED blinking functions COORDINATOR_BINDING: Enable Coordinator binding (Coordinator only) DEFAULT_CHANLIST: Override the default channel definition in file NLMEDE.h DEFAULT_KEY: Default security key ED_BIND: Enable bind/unbind processing when COORDINATOR_BINDING not active HOLD_AUTO_START Disable automatic start-up of ZDApp event processing loop KEYPOLL Enable key-polling
  • 50. 42 LCD_SUPPORTED Enable LCD emulation – text sent to ZTool serial port. Optional parameter =DEBUG copies LCD messages to the debug port MAC_OPT_FFD Enable Full Function Device (FFD) MANAGED_SCAN Enable delays between channel scans MAX_BCAST Maximum number of simultaneous broadcasts supported by a device at any given time NONWK Disable NWK, APS, and ZDO functionality NV_INIT Enable loading of “basic” NV items at device reset NWK_MAX_BINDING_ENTRIES Maximum number of entries in the binding table NWK_MAX_DATA_RETRIES The maximum number of times retry looking for the next hop address of a message NWK_MAX_DEVICES Maximum number of devices in the network POWER_SAVING Enable power saving functions for battery-powered devices ZDO_COORDINATOR Enable the device as a Coordinator 8.3.2 The compile options in the following table cannot be changed or used: CC2430BB Target is a SoC-BB battery board CC2430DB Target is a CC2430DB evaluation board CC2430EB Target is a SmartRF04EB evaluation board CPU32MHZ Clock rate of the CPU - Can be 16 or 32 MHZ EXTERNAL_RAM Enable use of external RAM memory for the OSAL heap FORCE_MAC_NEAR Forces MAC code into the NEAR memory segment GENERIC=__generic Defines complier keyword for generic pointers MACSIM Enable MAC simulation
  • 51. 43 NWK_TEST Enable Network test functions ROOT=__near_func Defines compiler keyword for ROOT memory WIN32 Enable Windows simulation 8.3.3 Zigbee Device Object (ZDO) Compile Options: ZDO_NWKADDR_REQUEST Enable Network Address Request function and response processing ZDO_MATCH_REQUEST Enable Match Descriptor Request function and response processing ZDO_NODEDESC_REQUEST Enable Node Descriptor Request function and response processing ZDO_ENDDEVICEBIND_REQUEST Enable End Device Bind Request function and response processing ZDO_BIND_UNBIND_REQUEST Enable Bind and Unbind Request function and response processing ZDO_MGMT_NWKDISC_REQUEST Enable Mgmt Nwk Discovery Request function and response processing ZDO_MGMT_LQI_REQUEST Enable Mgmt LQI Request function and response processing ZDO_MGMT_RTG_REQUEST Enable Mgmt Routing Table Request function and response processing
  • 52. 44 9 Conclusion One of the main challenges in the design of routing protocols for WSNs is energy efficiency due to the scarce energy resources of sensors. The ultimate objective behind the routing protocol design is to keep the sensors operating for as long as possible, thus extending the network lifetime. The energy consumption of the sensors is dominated by data transmission and reception. Therefore, routing protocols designed for WSNs should be as energy efficient as possible to prolong the lifetime of individual sensors, and hence the network lifetime. 10 Future Scope A wireless sensor network is an active research area with numerous workshops and conferences arranged each year. A wireless sensor network is a set of hundreds or thousands of micro sensor nodes that have capabilities of sensing, establishing wireless communication between each other and doing computational and processing operations. Sensor networks have wide variety of applications and systems with vastly varying requirements and characteristics. In this project ZigBee protocol is used which is the best for lower data rates. A lot of research is in progress to develop the as many as possible profiles to reach the rapidly growing need. Using the wireless sensing networks many fields can be automated and simplified. And in industries Manpower and time can be minimized and efficiency and accuracy can be maximized. Based on the growing technologies lot of applications can be done using wireless sensing networks. And we can say that lot of scope is there in research and development and also in industrial area.
  • 53. 45 11 References  www.zigbee.org  www.freaklabs.org  www.sensor-networks.org  www.ti.com  www.iar.com