Design & Implementation of Routing Protocol for WSN

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

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

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)

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.

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

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

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

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

1

1 Software & Hardware requirements

IAR Embedded Workbench

CC debugger

CC2430 based SOC boards (Ubimotes)

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)

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.

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.

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

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.

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.

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.

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

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

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.

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,

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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


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


ZDP_MgmtBindRsp(): If the device supports this command (optional), calling this function will


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


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


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

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

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.

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.

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.

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.

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.

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 Instruments\ZStack-1.4.3-1.2.1\Projects\zstack\Tools\CC2430DB

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

Instruments\ZStack-1.4.3-1.2.1\Projects\zstack\Samples\GenericApp\CC2430DB 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):

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

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

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

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.

45

11 References

www.zigbee.org

www.freaklabs.org

www.sensor-networks.org

www.ti.com

www.iar.com

http://www.zigbee.org/

http://www.freaklabs.org/

http://www.sensor-networks.org/

http://www.ti.com/

http://www.iar.com/