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 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):

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

Design & Implementation of Routing Protocol for WSN

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Design & Implementation of Routing Protocol for WSN

Similar to Design & Implementation of Routing Protocol for WSN (20)

Recently uploaded

Recently uploaded (20)

Design & Implementation of Routing Protocol for WSN