Please disable adblock to view this page.

← Go home

WSN Operating System and Content Delivery Network


November 3, 2016
Published By : Pratik Kataria
Categorised in:

OS Design Issues

WSN operates at two levels. One is at the network level and the other is at node level.
Network level interests are connectivity, routing, communication channel characteristics, protocols, etc.
Node level interests are hardware, radio, CPU, sensors and limited energy.
At a higher level OS for WSN can also be classified as node-level (local) and networklevel (distributed).
The important issues related to node-level are limited resource management; concurrency handling, power management and memory management where as issues related to both are inter-node communication, failure handling, heterogeneity and scalability.

  • Should be compact and small in size.
  • Should provide real time support.
  • Should provide efficient resource management.
  • Should provide reliable and efficient code distribution.
  • Should support Power Management.
  • Should provide generic programming interface.


TinyOS is an embedded, component-based operating system and platform for low-power wireless devices.
It used in WSNs, smartdust, ubiquitous computing, personal area networks, building automation, and smart meters.
Smartdust is tiny microelectromechanical systems (MEMS) such as sensors, robots, or other devices, that can detect, light, temperature, vibration, magnetism, or chemicals.
It is written in the programming language nesC, as a set of cooperating tasks and processes.

Started out as a research project at Berkeley
-> goal: conserving resources
Component-based, event-driven programming language
Designed to run on embedded devices.
Minimal device and networking abstractions.
Application and OS are coupled—composed into one image.
Supports event based model.
Sleep mode facility is provided.
Commands are non blocking requests with return status.



Characteristic of TinyOS

  • No UI, power constrained
  • Unusually application specific HW and SW
  • Multiple flows, concurrency intensive bursts
  • Extremely passive vigilance ( power saving )
  • Tightly coupled with the application.

TinyOS Charactersitics

Small memory footprint
–non-preemptable(No any action in order to prevent happening) FIFO task scheduling
Power Efficient
–Puts microcontroller to sleep
–Puts radio to sleep
Concurrency-Intensive Operations
–Event-driven architecture
–Efficient Interrupts and event handling
No Real-time guarantees

TinyOS Two-level Scheduling

Tasks do computations
–Non-preemptive FIFO scheduling
–Bounded number of pending tasks
Events handle concurrent dataflows
–Interrupts trigger lowest level events
–Events preempt tasks, tasks do not
–Events can signal events, call commands, or post tasks


How it works : Scheduling

Two-level scheduling ( Event and Task )

  • Single shared stack ( used by both interrupt and function call)
  • Scheduler is simple FIFO with bounded number of pending task.
  • Task can NOT preempt each other.
  • Event has high priority than task. Event can pre-empt task.
  • Event can preempt each other , once enabled
  • When idle , scheduler shut down node except for clock.

Event implementation

Event is independent of FIFO scheduler.

  • Lowest level events are supported directly by Hardware interrupt
  • Software events propagate from lower level to upper level through function call

Software challenges

Power efficiency
Small memory footprint
Application specific
Concurrency-intensive operations

  • Multiple, high-rate data flows (radio, sensor, actuator(moving or controlling a mechanism or system))


  • Real-time query and feedback control of physical world
  • Little memory for buffering: Data must be processed on the fly
  • TinyOS: No buffering in radio hw: deadline miss  data loss
  • TinyOS provides NO real-time guarantees!
  • EDF (Earliest Deadline First) scheduling supported in TinyOS 2.x


MANTIS (MultimodAl system for NeTworks of In-situ wireless Sensors) provides a new multi-threaded embedded operating system integrated with a general-purpose single-board hardware platform to enable flexible and rapid prototyping of wireless sensor networks
The key design goals of MANTIS are

  • ease of use, i.e., a small learning curve that encourages novice programmers to rapidly prototype sensor applications
  • flexibility such that expert researchers can continue to adapt and extend the hardware/software system to suit the needs of advanced research

MANTIS OS is called MOS
MOS selects its model as classical structure of layered multi-threaded operating systems which includes multi-threading, preemptive scheduling with time slicing, I/O synchronization via mutual exclusion, a standard network stack, and device drivers

MOS choose a standard programming language that the entire kernel and API are written in standard C. This design choice not only almost eliminates the learning curve, but also grow many of the other benefits of a standard programming language, including cross-platform support and reuse of a vast legacy code base. C also eases development of cross-platform multimodal prototyping environments on X86 PCs

MANTIS OS Functions

Network stack based on data flow and control flow
Command server reads request messages from the system-command input queue, verifies them, and passes the valid to the command processor.
User level lightweight processes with user thread.
Kernel makes the communication between hardware and software components
Scheduler is to provide a balanced mix of jobs, such as I/O bound and processor bound.
Device driver is a program that controls a particular type of device that is attached to your computer.

Architecture of MANTIS



Nano-RK OS

Design Goals

  • Designed to run on micro-controllers.
  • Battery Lifetime Requirements..
  • Real-time operating system (RTOS) from Carnegie Mellon University.
  • Classical OS Multitasking.
  • Unified Sensor Interface Abstraction
  • Priority-based Preemptive Scheduling
  • Timeliness and Schedulability
  • Enforcement of Resource Usage Limits

The Nano-RK Architecture

Static Approach
— OS & application co-located in a single address space.
— Admission control and schedulability analysis tests done offline.

Supports a fixed-priority fully preemptive scheduler and support real-time task sets.

Open source, is written in C and runs on the Atmel-based FireFly sensor networking platform, the MicaZ motes as well as the MSP430 processor.

The Reservation Paradigm
The following are specified per task:

  • CPU Reservations
  • Sender/Receiver Bandwidth Reservations
  • Sensor/Actuator Reservations

Power Awareness Support
Energy consumed by a task is the sum of:

  • CPU energy
  • Radio energy
  • Sensor/Actuator energy

Virtual Energy Reservations

  • (CPU, Network, Sensor)
  • Tweak parameters at pre-deployment stage.

Socket Abstraction and Support for Two-way communication
link between two programs.
Identify the application that data is destined to be sent to.
An endpoint is a combination of an IP address and a port number.
Populating application buffers on receipt of packets

  • Routing table data structures
  • Destination look-up functions
  • One-hop transmission of packets – Aggregate packets



LiteOS is a thread-based operating system and supports multiple applications

  • based on the principle of clean separation between the OS and the applications.
  • does not provide components or modules that should be “wired” together
  • provides several system calls
  • provides a shell – isolates the system calls from a user
  • provides a hierarchical file management system
  • provides a dynamic reprogramming technique

LiteOS Features

Real-time operating system (RTOS) from University of Illinois.
Environment based on Unix, threads, and C.
Allows both event-driven and thread-driven programming.
LiteOS is open source, written in C and runs on the Atmel AVR based MicaZ and IRIS sensor networking platform.
Latest version of LiteOS is 2.0.1, released on September 12, 2011.
Allows debugging sensor network applications directly through JTAG and AVR Studio.


What are Content Delivery Networks

  • A centrally managed network of devices that collectively facilitate the delivery of content to end users
  • Solve network bandwidth problem
  • Solve server throughput problem


CDN Categories

Network Infrastructure:

  • Single ISP
  • Overlay networks
  • Enterprise premise

Content types:

  • Static images and texts
  • Multimedia content: audio and video streams
  • Dynamic HTML and XML pages


  • Content providers
  • Enterprise

Technology Components

Content distribution
— Placing the content to the devices
Request routing
— Steer users to a delivery node that is close
Content delivery
— Protocol processing, access control, QoS mechanisms
Resource accounting
— Logging and billing

Content Distribution

Goal: position content objects into delivery devices
Different content types use different techniques:

  • Static images and texts: pulled & cached, or pushed
  • Multimedia contents: usually pre-positioned
  • Dynamic pages: requires prior setup

Distribution Mechanisms

HTTP request for pulling
— Example: standard HTTP reverse proxy
FTP of tar files
— Some equipment vendors use this technique
Rate limited tree-form replication
— Example: Cisco’s “Soda” algorithm

Content Consistency Mechanisms

Expiration times or TTL
Renaming in the HTML file
Web Cache Invalidation Protocol (WCIP)

  • Nodes receive invalidations when objects change
  • Objects are organized into channels
  • Nodes subscribe to a channel to receive invalidation

Request Routing

Goal: steer the client such that it fetches the content from a close node

  • DNS selection(maps internet domain names to the internet protocol (IP))
  • HTTP redirection
  • Transparent interception

Content Delivery

Goal: serve content to each client at desired quality of service
Supported protocols

  • HTTP
  • Microsoft MMS
  • Open standard RTP/RTSP
  • RealNetworks RTP/RTSP

Usually part of the larger CDN system