UNIT 6

INFRASTRUCTURE ESTABLISHMENT FOR WSN

Localization and Positioning Tracking

• Determine its physical position (with respect to some

coordinate system) or symbolic location

• Using the help of

• Anchor nodes that know their position

• Directly adjacent

• Over multiple hops

• • Using different means to determine distances/angles

locally

2

Properties of localization and positioning procedures• The simple intuition of “providing location information to a

node” has a number of facets that should be classified to

make the options for a location procedure clear.

• 1. Physical position versus symbolic location

• 2. Absolute versus relative coordinates

• 3. Localized versus centralized computation

• 4.Accuracy and precision

• 5.Scale

3

Possible approaches

Three main approaches exist to determine a node’s

position:

1. proximity-based approaches

Exploit finite range of wireless communication E.g.:

easy to

determine location in a room with infrared room

number

announcements

2. triangulation and trilateration

• Lateration versus angulation

• Determining distances

• Received signal strength indicator(RSSI)

• Time of arrival

• Time difference of arrival4

3. scene analysis

• The most evident form of it is to analyze pictures taken

by a camera and to try to derive the position from this

picture. This requires substantial computational effort and

is hardly appropriate for sensor nodes.

• Radio environment has characteristic “signatures”,

” fingerprints”

• Can be measured beforehand, stored, compared with

current situation

5

6

• Determining angles

As an alternative to measuring distances between

nodes, angles can be measured.

7

Single-hop localization

• concentrates on systems where a node with unknown

position can directly communicate with anchors.

• single-hop systems usually predate wsn.

• multihop communication to anchors is necessary.

• Active Badge

- “Active Badge Location System”

- system designed and built for locating simple, portable

devices

- within a building. It uses diffused infrared as

transmission medium and exploits the natural limitation of

infrared waves by walls.

- A globally unique identifier via infrared to receivers

8

• Active office

- Targeted the positioning of indoor devices.

- a central controller sends a radio message,

containing the device’s address.

- Pulse is received by the receiver.

- Sending the radio pulse is repeated every 200

ms,

allowing the mobile devices to sleep for most

of the

time.9

• RADAR

- The RADAR system is also geared toward indoor

computation of position estimates. Its most interesting

aspect is its usage of scene analysis techniques,

comparing the received signal characteristics from

multiple anchors.

• Cricket

- compute their own positions or locations.

• Overlapping connectivity

- periodically send out transmissions.

- absolute accuracy depends on the number of

anchors – more anchors allow a finer-grained

resolution of the area.

10

11

12

Positioning in multi-hop environments

• several anchor nodes.

• limited geographic availability of (relatively) precise

ranging or position information.

• Connectivity in a multihop network

• 1. A semidefinite program feasibility formulation

• -the position determination as a feasibility problem.

• -pushed apart, pull apart

• 2. MultiDimensional scaling

• -problem of range-free, connectivity-based locationing

• -shortest path algorithm roughly estimates positions of

nodes.

• -fairly stable with respect to anchor placement 13

• 3.Multihop range estimation

• 4.Iterative and collaborative multilateration

14

Impact of anchor placement

15

• Accuracy and precision improve.

• Entity is wandering around the given area.

• Point of maximum location error.

• Adaptive placement algorithms, suited mostly for low-

density networks

• on/off anchors to reduce energy consumption while

providing a given level of positioning accuracy.

• The obvious drawback of this approach is the need to

have an absolute measure of positioning error.

16

Summery

• Determining positions – and, to a lesser degree, also

locations – in a wireless sensor network is burdened with

considerable overhead and the danger of inaccuracies

and imprecision.

• A no negligible amount of anchors is necessary for

global coordinate systems, and the time and message

overhead necessary to compute positions if no direct

communication between anchors and nodes is available

should not be underestimated.

• It is possible to derive out of erroneous measurements an

often satisfactory degree of position estimates.

17

Operating Systems for WSN: OS Design Issues

• Resource constrains

• Data centric applications

• Variable topology

• Process management and scheduling (Earlier job first)

• Context switching

• Memory management

• Event driven

• APIs for WSN for application development

• OS for WSN can not have file system (as there is no

external device available)

18

WSN OS should have following features

• Compact and small in size

• Should provide real time support

• Effective resource management

• Power management

9/22/2015

20

OS Design Issues and Challenges in WSN

• Network level interests are connectivity, routing,

communication channel characteristics, protocols etc and

node level interests, hardware, radio, CPU, sensors and

limited energy.

• WSN OS can be classified as Node Level (Local) and

Network Level(Distributed)

• Restricted Resources

- limited battery power, processing capability, memory

and

bandwidth.

• Portability

- The software work on different hardware platforms.21

• Customizability

- The design of OS should be in such a way that it should be

easily customizable and extensible to various applications.

• Multitasking

- more than one task

1. sense the data

2. collect data from other neighborhood sensor nodes

3. aggregate the data based on the certain conditions

provided

4. encrypt/decrypt the data before processing/forwarding

5. route the data to the sink node

22

• Network Dynamics

- The context of different dynamics of the environment.

- Transparency from network dynamics to the application.

• Distributed Nature

- Inter-Node Communication

- Failure Handling and Disconnection

- Heterogeneity

- Scalability

23

Examples of OS

TinyOS• An operating system for tiny, embedded, and networked

sensors• NesC language A dialect of C Language with extensions for

components• Uses FIFO scheduler• Fixed sized frames• Three Limitations• -Application complexity• - High cost of porting to a new platform• - reliability• Little more that a non-preemptive scheduler• Component-based architecture• Event-driven 24

• Static binding and allocation

- Every resource and service is bound at compile time

and all

allocation is static• Single thread of control• Non-blocking calls

- A call to start lengthy operation returns immediately.- The called component signals when the operation is complete

- Split phase

25

• nesC : programming language for TinyOS

Mica2 Mote :• Processor - Microcontroller: 7.4 MHz, 8 bit

• Memory: 4KB data, 128 KB program

• Sensors - Light, temperature, acceleration, acoustic, magnetic...

• Power

<1 week on two AA batteries in active mode

>1 year battery life on sleep modes!

9/22/2015

Traditional OS Architecture

27

Problem with Large Scale Deeply embedded system..

• Large memory & storage requirement

• Unnecessary and overkill functionality ( address space isolation,

complex I/O subsystem , UI ) for our scenario.

• Relative high system overhead ( e.g, context switch )

• Require complex and power consuming hardware support.

TinyOS Architecture

28

NO Kernel Direct hardware manipulation

NO Process management Only one process on the fly.

NO Virtual memory Single linear physical address space

NO Dynamic memory allocation Assigned at compile time

NO Software signal or exception Function Call instead

Tiny OS advantages

• Very little code • Small amount of memory• Events propagate quickly • Task switching is fast

9/22/2015

Nano-RK

Nano resource kernel • Nano-RK: An Energy-Aware Resource Centric Real Time

OS for Sensor Networks

• Design Goal• Battery Lifetime Requirements

• Networking Stack Support

• Classical OS Multitasking

• Unified Sensor Interface Abstraction

• Priority-based Preemptive Scheduling

• Timeliness and Schedulability

• Enforcement of Resource Usage Limits30

• 2 KB RAM and 18 KB ROM

• Light sensing

• Temperature sensing

• Power saving

• As embedded OS and Robotics

• CSMA/CA and TDMA

• surveillance and environmental monitoring

• Low power mode, Multitasking, priority based scheduling, thread based execution model

9/22/2015

The Nano-RK Architecture

• Static Approach

• OS & application co-located in a single address space.

• Admission control and schedulability analysis tests done offline.

• The Reservation Paradigm

The following are specified per task:

• CPU Reservations

• Sender/Receiver Bandwidth 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)32

33

Comparison with TinyOS

• The TinyOS is less responsive for application developers.

• TinyOS has a smaller memory footprint.

• Tasks cannot be preempted in TinyOS.

• Real Time Embedded Operating System?

• No priority based scheduling policy

• No resource allocation policy

• Design objective: Flexibility and accelerate innovation.

34

Mate OS

• Designed work on the top of Tiny OS

• Middleware

• Uses adhoc routing protocol

• Event driven

• Message send

• Message receive

• Timer

• subroutine

9/22/2015

Magnet OS

• Distributed adaptive OS

• Distributed OS

• Features

• To adapt underlying resource

• energy conservation

• Scalability for large networks

• for ad hoc and sensor networks whose goal is to enable power-aware, adaptive, and efficient ad hoc networking applications

9/22/2015

MANTIS OS

• It is thread based

• Energy efficient algorithm

• Simulation support provided

• Has multi tasking model

• Priority based scheduling

• Preemptive multi threaded model

• Embedded OS

• IO SYNC using mutual exclusion

• RR algorithm

• Interrupt driven

• Implements flooding, Stop and wait

•

9/22/2015

Lite OS

• Multithreaded, multithreading

• Has hierarchical file system

• Software update possible

• more interactive UI

• Unix like OS

• 8 MHZ

• Round robin, priority based

• Simulation support

• Language support

• Modular architecture

• no real time support for application development

9/22/2015

9/22/2015

9/22/2015

Thank You

41