What is ZigBee?

ZigBee is an IEEE 802.15.4-based specification for a suite of high-level communication protocols used to create personal area networks with small, low-power digital radios. It operates on top of IEEE 802.15.4 to address issues in the upper protocol layers and application profiles by adding logical network, security and application software.

Sensors and control devices don’t need high bandwidth. They need low latency and very low power consumption. ZigBee offers product interoperability and vendor independence – win-win for customers. It defines modules for quality assessment, receiver energy detection and clear channel assessment.

The maximum distance between nodes is up to 70 m. ZigBee supports 3 network topologies: star, mesh and cluster tree (hybrid of the first two). It uses a master-slave configuration suitable for star networks comprising of many infrequently used devices that transmit small data packets. Master nodes can talk to each other. It supports up to 254 nodes and can be increased if necessary.

It incurs low latency – a node that is powered down can wake up and transmit a packet in 15 ms, which is an important feature for time-critical messages, e.g. in a nuclear plant. A node may act as a coordinator (FFD), router (FFD) , or end device (FFD or RFD).

ZigBee Network Model

The functions performed by a coordinator include setting up a network, transmits network beacons, management of network nodes, stores network node information and routes messages between paired networks.

A network node searches for available network, transfers data from its application/environment and determines whether there is data pending and requests data from the network coordinator.

What is Contiki?

Contiki is an operating system (OS) that was designed specifically for resource-constrained sensor nodes. An OS for sensor nodes must support lightweight mechanisms and abstractions that caters to the needs of applications while taking into consideration the limitations of the constrained devices. Contiki was developed with these constrains in mind.

Contiki is implemented in the C language. The kernel is event-driven, which allows it to support concurrency without the need for per-thread stacks or locking mechanism. Contiki uses a hybrid of event-driven systems and preemptive threads — it implements preemptive multi-threading as an application library that is optionally linked with programs that explicitly require it.

Unlike most OS for embedded systems which require a complete binary image of the entire system to be built and downloaded into each device, Contiki allows dynamic loading and unloading of programs and services at runtime.

The Contiki system consists of a kernel, libraries, a program loader and a set of processes. A process is either an application program or a service. It is defined by an event handler function and an optional poll handler function. A process state is held in the process's private memory and the kernel keeps a pointer to the process state. A service implements functionality used by more than one application processes. All processes can be dynamically replaced at runtime.

A Contiki system is partitioned into two parts:

1. Core - consisting of the kernel, program loader and the most commonly used parts of the language runtime and support libraries, and a communication stack with device drivers for the communication devices. The core is compiled into one binary image that is stored in the devices before they are deployed. It is rarely modified, but a special boot loader can be used to overwrite or patch the core.
2. Loaded programs - this is how programs are loaded into the system. A loaded program obtains the binaries either using the communication stack or by using directly attached storage, such as EEPROM.

The kernel supports two types of event:

1. Asynchronous events are a form of defrerred procedure call - they are queued by the kernel and dispatched to the target process some time later.
2. Synchronous events are similar to asynchronous events but immediately causes the target process to be scheduled. Control returns to the posting process after the target has finished processing the event.

Power conservation is a critical feature when dealing with wireless devices. The Contiki kernel does not provide an explicit power save abstraction, but allows applications to implement the mechanism. The event scheduler exposes the event queue size and applications use this information to power down the processor when no events are scheduled.

Source:

1. A. Dunkels, B. Gronvall, T. Voigt, "Contiki - A Lightweight and Flexible Operating System for Tiny Networked Sensors", Proc. of 29th Annual IEEE International Conference on Local Computer Networks, 2004