WSN Operating System and Content Delivery Network
November 3, 2016
Categorised in: Data Communicaiton & Wireless Sensor Networks
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.
Small memory footprint
–non-preemptable(No any action in order to prevent happening) FIFO task scheduling
–Puts microcontroller to sleep
–Puts radio to sleep
–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 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
Small memory footprint
- 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
- 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
— 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
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
- Single ISP
- Overlay networks
- Enterprise premise
- Static images and texts
- Multimedia content: audio and video streams
- Dynamic HTML and XML pages
- Content providers
— Placing the content to the devices
— Steer users to a delivery node that is close
— Protocol processing, access control, QoS mechanisms
— Logging and billing
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
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
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
Goal: serve content to each client at desired quality of service
- Microsoft MMS
- Open standard RTP/RTSP
- RealNetworks RTP/RTSP
Usually part of the larger CDN system