dcwsn unit 6 infrastructure establishment for wsn · properties of localization and positioning...
TRANSCRIPT
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