PRACTICAL-02

Aim: Exploring and understanding TinyOS computational concepts: - Events,

Commands and Task.
 Introduction: What is TinyOS?

TinyOS is an embedded, component-based operating system and platform for low-power

wireless devices, such as those used in wireless sensor networks (WSNs), smartdust, ubiquitous
computing, personal area networks, building automation, and smart meters. It is written in the
programming language nesC, as a set of cooperating tasks and processes. It began as a
collaboration between the University of California, Berkeley, Intel Research, and Crossbow
Technology, was released as free and open-source software under a BSD license, and has since
grown into an international consortium, the TinyOS Alliance.

 Why is TinyOS? Problems with traditional OS

 Multithreaded architecture not useful.

 Large memory footprint

 Does not help to conserve energy and power

 Programming language used

TinyOS applications are written in the programming language nesC, a dialect of the C language
optimized for the memory limits of sensor networks. Its supplementary tools are mainly in the
form of Java and shell script front-ends. Associated libraries and tools, such as the nesC
compiler and Atmel AVR binutils toolchains, are mostly written in C.

 Features and functions of TinyOS

 Completely non-blocking

 Programs are built out of software components

 Tasts are non- preemptive and run in FIFO order

 TinyOS code is statistically linked

 Advantages

 Small in size:

The source code of TinyOS is small in size. Due to smaller code devices run fast and OS does
not tend to overload the device.

 Event-driven OS:

TinyOS is an event-driven OS that means it depends upon the events it receives from the
surrounding environment.

 Low memory needed:

TinyOS needs low memory to run. We don’t need to buy higher memory devices to run this
operating system.

 Modularity:

TinyOS has different modules in it. Each module performs its own function. The modules
include tasks, commands, events, microcontroller, hardware, and software.

 Reusability:

TinyOS can be reusable on similar devices.

 Use low voltages:

Due to low memory and space usage TinyOS use low battery. TinyOS can run on smaller
devices also which have low voltage.

 Disadvantages

 Adjustments needed:

There need some adjustments to make communication between hardware and software. This is
because of low voltage restriction.

 Asynchronous in nature:

As network sensor devices have to update its data from surrounding in every second, so
programmers have to keep this in mind to make the code work in any case.

 Difficult to program:

It is difficult to make a program for TinyOS due to some restriction like asynchronous behavior,
memory limit, and low voltage. NesC programming language is the major disadvantage of this
OS. It is difficult for programmers to write efficient code in NesC.
 PRACTICAL-03

Aim: Understanding TOSSIM for - Mote-mote radio communication - Mote-PC

serial communication

Introduction
TOSSIM is a discrete event simulator for TinyOS sensor networks. Instead of compiling a TinyOS application
for a mote, users can compile it into the TOSSIM framework, which runs on a PC. This allows users to debug,
test, and analyze algorithms in a controlled and repeatable environment. As TOSSIM runs on a PC, users can
examine their TinyOS code using debuggers and other development tools. Brief summmary of its
characteristics:

 Fidelity: By default, TOSSIM captures TinyOS’ behavior at a very low level. It simulates the network at the
bit level, simulates each individual ADC capture, and every interrupt in the system.
 Time: While TOSSIM precisely times interrupts (allowing things like bit-level radio simulation), it does not
model execution time. From TOSSIM’s perspective, a piece of code runs instantaneously. Time is kept at
a 4MHz granularity (the CPU clock rate of the rene and mica platforms).
 Models: TOSSIM itself does not model the real world. Instead, it provides abstractions of certain real-
world phenomena (such as bit error). With tools outside the simulation itself, users can then manipulate
these abstractions to implement whatever models they want to use.
o Radio: TOSSIM does not model radio propagation; instead, it provides a radio abstraction of directed
independent bit errors between two nodes. An external program can provide a desired radio model
and map it to these bit errors. Having directed bit error rates means that asymmetric links can be
easily modeled.
o Power/Energy: TOSSIM does not model power draw or energy consumption. However, it is very
simple to add annotations to components that consume power to provide information on when their
power states change (e.g., turned on or off). After a simulation is run, a user can apply a energy or
power model to these transitions, calculating overall energy consumption.
 Building: TOSSIM builds directly from TinyOS code. To simulate a protocol or system, you must write a
TinyOS implementation of it.
 Imperfections: Although TOSSIM captures TinyOS behavior at a very low level, it makes several
simplifying assumptions. This means that it is very possible that code which runs in a simulation might
not run on a real mote. For example, in TOSSIM interrupts are non-preemptive (a result of being a
discrete event simulator).
 Networking: Currently, TOSSIM simulates the 40Kbit RFM mica networking stack, including the MAC,
encoding, timing, and synchronous acknowledgements.
 Authority: Initial experience from real-world deployments has shown that TinyOS networks have very
complex and highly variable behavior. While TOSSIM is useful to get a sense of how algorithms perform
in comparison to one another, TOSSIM results shouldn’t be considered authoritative.

Compiling and Running a Simulation

TOSSIM is automatically built when you compile an application. Applications are compiled by entering an
application directory (e.g. /apps/Blink) and typing make. Alternatively, when in an application directory, you
can type make pc, which will only compile a simulation of the application.
  dbg
TOSSIM provides configuration of debugging output at run-time. Much of the TinyOS source contains
debugging statements. Each debugging statement is accompanied by one or more modal flags. When the
simulator starts, it reads in the DBG environment variable to determine which modes should be enabled.
Modes are stored and processed as entries in a bit-mask, so a single output can be enabled for multiple
modes, and a user can specify multiple modes to be displayed.
 Network Monitoring and Packet Injection
To interact with a simulated network, you must use SerialForwarder, the standard TinyOS interface tool. To
work with TOSSIM, SerialForwarder’s input source must be set appropriately. TOSSIM provides two modes:
communication through a serial port to mote 0 and network snooping.

Radio Models
TOSSIM simulates the TinyOS network at the bit level, using TinyOS component implementations almost
identical to the mica 40Kbit RFM-based stack. TOSSIM provides two radio models: simple and lossy. The mica2
CC1000-based stack does not currently have a simulation implementation.
 Using LossyBuilder
LossyBuilder assumes each mote has a transmission radius of 50 feet. Combined with the bit error rate, this
means each mote transmits its signal in a disc of radius 50 feet, with the bit error rate increasing with distance
from the center.
 Bit Errors and Packet Errors
The forumula for calculating packet error rates (Ep) from bit error rates (Eb) for the mica RFM 40Kb stack with
SecDed encoding is:
Ep = 1 − (Ss · (Se)d)
Ss = (1 − Eb)9
Se = (1 − Eb)8 + (8 · Eb · (1 − Eb)12)
Ep = 1 − ((1 − Eb)9 · ((1 − Eb)8 + (8 · Eb · (1 − Eb)12))d)
where Ss is the start symbol success probability, Se the probability a packet byte is uncorrupted (zero or
one bit errors), and d is the number of bytes in the packet.

 Lossy Model Actuation

Specifying a loss topology with a file defines a static topology over an entire simulation. There are simulation
situations, however, in which changing topologies are needed. TOSSIM therefore allows users to modify the
loss topology at run-time.

ADC Models
TOSSIM provides two ADC models: random and generic. The model chosen specifies how readings taken from
the ADC are generated. Whenever any channel in the ADC is sampled in the random model, it returns a 10-bit
random value (the rene and mica ADCs are 10 bits).

EEPROM
TOSSIM models the EEPROM at the line (16-byte block) level. TOSSIM models it with a large, memorymapped
file. By default, this file is anonymous, and disappears when a simulation ends.
TinyViz
TinyViz is a Java visualization and actuation environment for TOSSIM. The main TinyViz class is a jar file,
tools/java/net/tinyos/sim/tinyviz.jar. TinyViz can be attached to a running simulation. Also, TOSSIM can be
made to wait for TinyViz to connect before it starts up, with the -gui flag. This allows users to be sure that
TinyViz captures all of the events in a given simulation.
 TinyViz Plugins
Users can write new plugins, which TinyViz can dynamically load. A simple event bus sits in the center of
TinyViz; simulator messages sent to TinyViz appear as events, which any plugin can respond to. For example,
when a mote transmits a packet in TOSSIM, the simulator sends a packet send message to TinyViz, which
generates a packet send event and broadcasts it on the event bus.

Using gdb
The binary executable produced by typing make pc in any app directory can be debugged using GDB.
Developers of TinyOS code can step through programs they have written, debugging deterministic, logical
aspects of their code before loading programs onto motes.

Concurrency Model
TOSSIM captures the TinyOS event-driven concurrency model at interrupt and task granularity. For a
description of the TinyOS concurrency model, refer to the TinyOS documentation. This document does not
describe the model, merely how TOSSIM implements it.

Internals
Currently, TOSSIM compiles by using alternative implementations of some core system components (e.g.
Main.nc, HPLUART.nc) and incorporating a few extra files (e.g. event queue.c). The basic TOSSIM structure
definitions exist in platform/pc/nido.h. These include the global simulation state (event queue, time, etc.) and
individual node state.
 TOSSIM Architecture
TOSSIM replaces a small number of TinyOS components, the components that handle interrupts and the Main
component.

TOSSIM Implementations
To load a component, the nesC compiler uses a directory search path. The default search path is:
• The application directory
• tos/platform/xxx (the selected platform)
• tos/sensorboards/xxx (the selected sensor board(s))
• tos/system 15
• tos/lib
Mote-PC serial communication and SerialForwarder (TOS 2.1.1 and later)

Packet sources and TestSerial

The first step is to check that you are able to get your PC to communicate with a mote. Most motes have a
serial port or similar interface. For example, the mica family can directly control a serial port: programming
boards basically connect the mote's serial port pins to the actual serial port on the board. Telos motes also
have a serial interface, but it talks to their USB hardware, which is similar in functionality but very different in
terms of cables and connectors.

MOTECOM
If you do not pass a -comm parameter, then tools will check the MOTECOM environment variable for a packet
source, and if there is no MOTECOM, they default to a SerialForwarder. This means that if you're always
communicating with a mote over your serial port, you can just set MOTECOM and no longer have to specify
the -comm parameter.

BaseStation and net.tinyos.tools.Listen

BaseStation is a basic TinyOS utility application. It acts as a bridge between the serial port and radio network.
When it receives a packet from the serial port, it transmits it on the radio; when it receives a packets over the
radio, it transmits it to the serial port.

MIG: generating packet objects

The Listen program is the most basic way of communicating with the mote; it just prints binary packets to the
screen. Obviously it is not easy to visualize the sensor data using this program.

SerialForwarder and other packet sources

One problem with directly using the serial port is that only one PC program can interact with the mote.
Additionally, it requires you to run the application on the PC which is physically connected to the mote.

Packet Sources
In addition to serial ports and SerialForwarders, the TinyOS messaging library supports a third packet source,
motes which are connected to an ethernet port through a Crossbow MIB 600 ethernet board. This is the full
set of packet sources:

Syntax Source
serial@PORT:SPEED Serial ports
sf@HOST:PORT SerialForwarder, TMote Connect
network@HOST:PORT MIB 600
In the network packet source, the default MIB 600 port is 10002. The Moteiv TMote Connect appliance is a
SerialForwarder packet source.
Sending a packet to the serial port in TinyOS
Sending an AM packet to the serial port in TinyOS is very much like sending it to the radio. A component uses
the AMSend interface, calls AMSend.send, and handles AMSend.sendDone. The serial stack will send it over
the serial port regardless of the AM address specified.

TOSThreads Example
For TOSThreads applications, the TOSThreads library provides both nesC and C APIs for serial communication.
nesC APIs are in tos/lib/tosthreads/system/: BlockingSerialActiveMessageC component provides the
BlockingStdControl interface to turn ON/OFF serial communication.
 PRACTICAL- 04

Aim: Create simple Adhoc network.

Description:

● Simulator used : Omnet++

● Simulator can be downloaded from below link:
https://omnetpp.org/omnetpp (recommended version is omnet++ 4.2.2).
● After installing Omnet++, we need to install inet framework which is specially designed
for wireless simulation. You can download inet framework from below link.
https://inet.omnetpp.org/Download.html
● After downloading there are certain steps to be followed to include this framework in
omnet++ as follows:

● Download the INET sources.

● Unpack it into the directory of your choice: (tar xvfz inet-
<version>.tgz)(recommended is tar or .tgz)
● Recommeded version is inet 2.1
● Start the Omnet++ IDE, and import the project via File -> Import -> Existing
Projects to the Workspace. A project named inet should appear.
● Build with Project -> Build, or hit ctrl+b
● Now you should be able to launch example simulations.

Steps for practical:

● Then open inet/examples/

● Right click on adhoc -create new folder as SimpleAdhoc.
● Right click on your newly created folder and select NED file. Give name as Net1.
Click on new manages mobility wireless network wizard.
Then configure as follows

Then click on finish.

Below is the code that will be available in source part of net1.ned once configured.

package inet.examples.adhoc.SimpleAdhoc;

// numOfHosts: 5

import inet.networklayer.autorouting.ipv4.IPv4NetworkConfigurator;
import inet.nodes.inet.WirelessHost;
import inet.nodes.wireless.AccessPoint;
import inet.world.radio.ChannelControl;

network Net1
{
parameters:
int numOfHosts;

submodules:
host[numOfHosts]: WirelessHost
{
@display("r=,,#707070");
}

ap: AccessPoint
{
@display("p=213,174;r=,,#707070");
}

channelControl: ChannelControl
{
numChannels = 2;
@display("p=61,46");
}

configurator: IPv4NetworkConfigurator
{
@display("p=140,50");
}
}
On design part you will find components appearing according to the code as the above
snapshot.

Same as do this in omnetpp.ini file:

Source code for omnetpp.ini:

[General]
network = Net1

*.numOfHosts = 5

#debug-on-errors = true
tkenv-plugin-path = ../../../etc/plugins

**.constraintAreaMinX = 0m
**.constraintAreaMinY = 0m
**.constraintAreaMinZ = 0m
**.constraintAreaMaxX = 600m
**.constraintAreaMaxY = 400m
**.constraintAreaMaxZ = 0m
**.debug = true
**.coreDebug = false
**.host*.**.channelNumber = 0

# channel physical parameters

*.channelControl.carrierFrequency = 2.4GHz
*.channelControl.pMax = 2.0mW
*.channelControl.sat = -110dBm
*.channelControl.alpha = 2

# mobility
**.host*.mobilityType = "MassMobility"
**.host*.mobility.initFromDisplayString = false
**.host*.mobility.changeInterval = truncnormal(2s, 0.5s)
**.host*.mobility.changeAngleBy = normal(0deg, 30deg)
**.host*.mobility.speed = truncnormal(20mps, 8mps)
**.host*.mobility.updateInterval = 100ms

# ping app (host[0] pinged by others)

*.host[0].numPingApps = 0
*.host[*].numPingApps = 2
*.host[*].pingApp[*].destAddr = "host[0]"
**.pingApp[0].startTime = uniform(1s,5s)
**.pingApp[1].startTime = 5s+uniform(1s,5s)
**.pingApp[*].printPing = true

# nic settings
**.wlan[*].bitrate = 2Mbps

**.wlan[*].mgmt.frameCapacity = 10

**.wlan[*].mac.address = "auto"
**.wlan[*].mac.maxQueueSize = 14
**.wlan[*].mac.rtsThresholdBytes = 3000B
**.wlan[*].mac.retryLimit = 7
**.wlan[*].mac.cwMinData = 7

**.wlan[*].radio.transmitterPower = 2mW
**.wlan[*].radio.thermalNoise = -110dBm
**.wlan[*].radio.sensitivity = -85dBm
**.wlan[*].radio.pathLossAlpha = 2
**.wlan[*].radio.snirThreshold = 4dB

[Config Ping1]
description = "host1 pinging host0"

[Config Ping2] # __interactive__

description = "n hosts"
# leave numHosts undefined here

**.mobility.constraintAreaMinZ = 0m
**.mobility.constraintAreaMaxZ = 0m
**.mobility.constraintAreaMinX = 0m
**.mobility.constraintAreaMinY = 0m
**.mobility.constraintAreaMaxX = 600m
**.mobility.constraintAreaMaxY = 400m
**.debug = false
**.coreDebug = false

**.channelNumber = 0

# channel physical parameters

*.channelControl.carrierFrequency = 2.4GHz
*.channelControl.pMax = 20.0mW
*.channelControl.sat = -110dBm
*.channelControl.alpha = 2

# mobility

**.host[*].mobilityType = "MassMobility"
**.host[*].mobility.changeInterval = truncnormal(2s, 0.5s)
**.host[*].mobility.changeAngleBy = normal(0deg, 30deg)
**.host[*].mobility.speed = truncnormal(20mps, 8mps)
**.host[*].mobility.updateInterval = 100ms

# nic settings
**.bitrate = 2Mbps

**.mac.address = "auto"
**.mac.maxQueueSize = 14
**.mac.rtsThresholdBytes = 3000B
**.wlan[*].mac.retryLimit = 7
**.wlan[*].mac.cwMinData = 7
**.wlan[*].mac.cwMinMulticast = 31

**.radio.transmitterPower = 20.0mW
**.radio.carrierFrequency = 2.4GHz
**.radio.thermalNoise = -110dBm
**.radio.sensitivity = -85dBm
**.radio.pathLossAlpha = 2
**.radio.snirThreshold = 4dB

# relay unit configuration

**.relayUnitType = "MACRelayUnitNP"
**.relayUnit.addressTableSize = 100
**.relayUnit.agingTime = 120s
**.relayUnit.bufferSize = 1MiB
**.relayUnit.highWatermark = 512KiB
**.relayUnit.pauseUnits = 300 # pause for 300*512 bit (19200 byte) time
**.relayUnit.addressTableFile = ""
**.relayUnit.numCPUs = 2
**.relayUnit.processingTime = 2us
EXECUTION:

Now try to execute by right click on ned file Run as-1-Omnet++ simulation.

OUTPUT:
 PRACTICAL -05
Aim: Understanding, Reading and Analyzing Routing Table of a network.
Steps:
 Take four end devices i.e. PC’s, laptops or servers, two Router-PT and two switches
2950-24
 Connect those using connections as shown in below figure.

 Configure the first router FastEthernet0/0 and 1/0 and Serial2/0with static IP.
 Advertise the range of these IP’s in RIP.
 Similar configurations to be done on second router.
 Configure the devices connected via connection with router i.e. router IP and device
gateway should be same and device should have a same range static IP.
 All the configurations is shown below
Second router
 Now ping from one machine to another
 PRACTICAL-06
Aim: Create a basic MANET implementation simulation for Packet animation and
Packet Trace.
Steps:
 Then open inet/examples/
 Right click on manetrouting -create new folder as MobileNet.
 Right click on your newly created folder and select NED file. Give name as Net1.
 Select new adhoc mobility wireless network wizard.
 PRACTICAL-07
Aim: Implement a Wireless sensor network simulation.
Steps:
 Select all devices namely PC’s, laptops, server and three Access Point i.e. Access Point
PT-A, Access Point PT, Access Point PT-N.

 According to the channel strength of port 1 of access points change the physical
properties of end devices for wireless communication.
 Configure the Access point PT-A as below.

 Configure PC0 as
 Configuration of PC1

 Configuration of Access Point PT

 Configuration of Laptop0

 Configuration of Server0
 Configuration of Access Point N
 Pinging the devices in wireless connection
 PRACTICAL-08

Aim: Create MAC protocol simulation implementation for wireless sensor

Network.
Steps:
 Consider the following topology

 Adding the wireless interface to each Laptops

 Copy the MAC address of each component as follows
 We note the following MAC addresses and convert them to the following form
Component MAC Address Converted MAC address

Laptop0 000A.F3B4.7CDC 00:0A:F3:B4:7C:DC

Laptop1 0001.4269.6539 00:01:42:69:65:39

Laptop2 0060.5CB8.B919 00:60:5C:B8:B9:19

TabletPC 000C.8558.6B7B 00:0C:85:58:6B:7B

SmartPhone0 00D0.9774.32BD 00:D0:97:74:32:BD

SmartPhone1 0060.701E.0BE0 00:60.70:1E:0B:E0

 Now we add few addresses in the wireless MAC filter of the Wireless Router and then
use the given options for either allow or deny the Wireless access
 As seen in above screen shot we add the MAC address of Laptop0, Tablet, PC
SmartPhone0 in the list so as to deny them accessing the Wireless network and then
save the settings
 The result so obtained is as shown, the three devices denied any wireless connectivity
 Similarly we can change the setting so that the above devices get wireless connectivity
and the remaining devices do not get the wireless connectivity

 And save the setting and get the following

 PRACTICAL-09
Aim: Simulate Mobile Adhoc Network with Directional Antenna
 Consider the following topology

 Click on the Fan and do the following

 In the Advanced setting do the following for the Network adapter

 For the motion Detector sensor do the following

 In the Advanced setting do the following for the Network adapter

 For the smartphone change the SSID to the SSID in the Home Gateway0
 As seen above the SSID is HomeGateway, we use the same and set the SSID in the
Smartphone

 All the devices are now connected to the Home Gateway

  Now open the Web browser of the SmartPhone and type the IP address of the
HomeGateway

Username: admin

Password: admin
 After logging click on conditions and do the following

 Add another condition as follows

 Press the ok button after adding the two conditions

 In order to turn ON the fan Press the ALT key and left-click the mouse over the Sensor
 PRACTICAL-10
Aim: Create a mobile network using Cell Tower, Central Office Server, Web
browser and Web Server. Simulate connection between them.

Steps:
 Select one smartphone, cell-tower, Central Office Server, Hub, Router 1841 and a
wireless Router WRT300N.
 Connect those devices as shown below.
 Configure the central office server as shown below.
 Configure the wired router with IP address.
 Configure wireless router with IP address and Gateway.

 Now ping the wired router from cellular device and tract the network using tracert
command.