[02]TinyOS,

including its event-driven mechanism, schedule strategy

mechanics, power management mechanism, and etc. Then, the
component-based architecture of TinyOS is analyzed. Based
on these, the transplant scheme, the design principle of the
layer of hardware description and the selection principle of
processor are provided. Finally, this paper gives some
conclusions and foresight.

[03]Component Based TinyOS Applications

[04]Effective Scheduling Algorithms for Quality of Service Management in TinyOS

[06]SJP schedulilng
[07] Task Scheduling Mechanism
[05] Routing Protocol based on TinyOS

[09] Security issues

TinyOS is designed for Wireless Sensor Networks. Wireless Sensor Networks may
consist of several nodes. These nodes have many practical applications like temperature
sensing humidity sensing, eco system monitoring and many more. These nodes can be
installed anywhere and their data may be collected centrally. These nodes are dispersed
and accessed remotely so to perform their tasks effectively we need a well defined
Operating System with different architecture and approach than others.

In this paper we will briefly discuss different aspects of TinyOS including Event driven
mechanism, efficient Scheduling Algorithms for Quality of Service like SJP scheduling,
routing protocol and component-based architecture of tinyOS. Constraints like Power
consumption, coding and memory limitations, security issues would also be addressed in
this paper.
Introduction:
[02]
Wireless Sensor Network (WSN) is made by the
convergence of sensor, micro-electro-mechanism system and
networks technologies [1~3]. It has become one of the front
fields to research. As a novel technology about acquiring and
processing information, it brings a lot of challenges to us, and
one of them is the micro embedded operating system.
The research on micro operating system must be done firstly.
The capability of the hardware is so limited that the embedded
operating system has to realize efficient management of the
hardware in a limited space. As a result, choosing appropriate
operating system for the nodes of wireless sensor networks is
very important.
Based on the requirements of WSN, this paper puts forward
the design target of operating system. As there is a wide range
of potential applications, the variation in physical devices is
likely to be large. So good transplanting is a key element [4]
for the operating system of the nodes of wireless sensor
networks. According to the characteristics of WSN and the
demands analysis of node operating system, the authors do
profound studies on the classical operating system TinyOS

[03]

TinyOS has been a successful basis for interrupt-driven sensor-

net applications. Its component model is designed to minimize ap-
plication code size by linking in only needed functionality, and to
speed application development through component reuse. Unfortunately , creating reliable tinyOS
applications by building on existing component specially those written by others is notoriously difficult
A principal challenge is that proper use of the TinyOS
interfaces has never been carefully specified, giving developers un-
wanted degrees of freedom. Developers of reusable components
are forced to assume that their interfaces will be misused, requiring
defensive programming that adds development and resource over-
head. Similarly, those reusing existing components are forced to
assume that interface calls may fail, even when used properly, ne-
cessitating development overhead due to error checking and failure
recovery strategies. These problems have been shown to be rele-
vant for the interfaces in TinyOS l.x, which we checked for this
paper, and we believe they are present in TinyOS 2.0 as well.
[07]
TinyOS was the defacto standard for WSN.
TinyOS provided two level scheduling mechanisms: events and tasks. Tasks were mainly applied to non-
strict real-time application. All tasks were equivalent with each other and no priority. They all were placed
in a single queue in which tasks were scheduled by the FCFS(First Come First Serve) rule. One task could
not preempt another while another was running. Events handler was executed to response to hardware
interrupts, these interrupts could preempt any task, even when it was running, and lower priority interrupts
as well. Events handler only handled simple work and left hard work to tasks. When there was no task to be
run in the tasks queue, TinyOS make WSN node sleep for saving energy. When an interrupt happened,
TinyOS would be activated from sleeping. The scheduling mechanism of TinyOS was shown as Figure 1.
This scheduling mechanism was very simple and good at practicing, and able to apply to most WSN
applications which were lack of energy and system resources. By this scheduling, TinyOS was made very
popular and was regarded as the defacto standard in WSN. However, TinyOS has also some intuitive
deficiency, such as can not dealing with problems that short executing time task had to wait for long
executing time task, important task had to wait for less important task, and so on. It could create serious
problems(task discarding, task overloading, low efficient communication and so on) in applications,
especially in real-time applications. So we needed to study the scheduling mechanism of TinyOS in order
to satisfy much more WSN applications.

[06]
The TinyOS is an embedded operating system for network sensor based on event-driven, and its goal is to
support the concurrency intense operations of network sensors with minimal hardware [1]. The TinyOS job
scheduling is based on non-preempting first-come-first-served strategy (FCFS), which helps to reduce the
system requirement for storage space. However, it is not able to give highly real time network jobs quick
response, and it is likely to be overloaded [2], resulting in the job lost and the information throughput
getting lower etc. Literature [3] proposes a double ring scheduling strategy, improving the system response
speed. Literature [4] reports that the WSN system real-time can be improved by the TinyOS priority
scheduling strategy based on time limit. Literature [5] put forward a job priority scheduling algorithm to
increase the throughput of overloaded nodes comparatively and thus to resolve the question of overload of
local node package. This paper presents a SJP algorithm based on time limit and shortestjob-first
Priority scheduling strategy, and the system throughput was also considered.
SJP:
In order to improve the emergency jobs quick response, hard and
soft real-time jobs are divided by the SJP algorithmaccording to
the job significance. Hard real-time job has hardtime constrains,
and the miss of its time limit can causeserious consequences. The
soft real-time job has soft constrains, the miss of its time limit in
some cases can beaccepted, and no serious consequences occur.
[04]
The major contribution of this work is introduction of a novel dynamic scheduling
algorithm to handle prioritized data communication in wireless sensor networks.
Additionally, wireless sensor network environments impose significant communication
and computation limitations that have forced us to come up with new algorithms to
implement the proposed dynamic scheduling algorithm. Tiny-DWFQ dynamically adjusts
its parameters in order to fulfill the Quality of Service
(QoS) requirements of the data being sent throughout the network in the midst of
continuously changing network conditions and requirements. One of the major obstacles
that we overcame in achieving this was designing and implementing a lightweight
algorithm, specifically for resource constrained wireless sensor networks, that is robust
enough to handle continuous real-time data flows. Due to the limited computational
capacity of wireless sensor networks, most significantly memory, computational capacity,
and bandwidth, our algorithm is designed specifically to meet these demanding
requirements. Bandwidth limitations in any wireless network provide a restricted amount
of resources to be shared amongst competing data flows. Thus, in order to maximize the
available resources, we designed TinyDWFQ to be a congestion reactive, scheduling
Algorithm.

In order to meet the overall needs of many different types of communication, it is necessary for data to be
categorized based on its importance, or priority level within the network.

Ideally we would be able to transmit all of the data all of the time. However when network congestion
occurs due to the limited available bandwidth, a decision must be made as to which data should be sent and
in which order. These decisions are the responsibilities of our Tiny-DWFQ scheduling algorithm.

[05* pending-routing issue]

[09] Power issue

Wireless Sensor Networks (WSNs) are a valuable technol-

ogy to support the development of new applications in many
different areas, such as: environmental and habitat monitoring,
surveillance, indoor climate control, structural monitoring,
medical diagnostics, disaster management, and so on [1], [2].
They can be defined as a special type of multi-hop ad-hoc networks,
and participating nodes are typically battery operated,
thus having access to a limited amount of energy. Moreover,
these nodes often exhibit additional constraints, such as limited
processing, storage and communication capabilities [3].
In several WSN-based applications, the nodes are left unattended
for their whole operational lifetime after deployment.
Moreover, the sensing and processing tasks the node will
execute, as well as the overhead introduced by the node’s
operating system (OS), must be accounted for in the energy
consumption. Hence, understanding the impact of processing
and communications tasks on the nodes’ energy usage provides
the necessary knowledge to choose the appropriate duty cycle.
This approach allows the sensor network node to alternate between
active, idle and low-power periods, thus saving energy.
Indeed, the careful choice of the duty cycles is a common
power conservation approach in real deployments [4], [5].

Security issue
Most WSN deployments do not consider security among
their requirements because of the execution time/energy overhead
it adds to the system; hence, security tends to be
considered simply as an undesirable “extra cost” in such
constrained environments. However, when targeting WSNs
for health applications or applications that monitor sensitive
information, it is important to consider confidentiality;
therefore, in these scenarios, the deployment of encryption
algorithms is essential. Furthermore, in many situations data
integrity and authenticity are also critical, since the existence
of invalid data could lead to mistaken actions with severe
consequences; since the origin of such invalid information
can be either natural (caused by hardware malfunctioning,
transmission errors, etc.) or intentional (e.g., generated by fake
sensors introduced in the network with malicious intent), the
deployment of Message Authentication Codes (MACs) is also
made necessary. Finally, since such algorithms depend on the
existence of secret keys for their functioning, applications need
to deal with the distribution of such keys, what is a especially
challenging issue in WSNs [6]. [/* is it enough or proceed down */]
Due to the constraints intrinsic to WSNs, security mechanisms
employed must be extremely lightweight. The literature
includes some comparative evaluations of traditional hash
functions, block and stream ciphers [7], [8], [9], [10] in sensor
networks. The main goal of these analysis is to determine
the most adequate algorithms for deployment in WSNs, considering
both efficiency and security requirements. Similarly,
many authors have tried to identify efficient implementations
of Elliptic Curve Cryptography (ECC) for such constrained
scenarios [11], [12], [13]. The results obtained in these studies
usually show that the deployment of general-purpose algorithms
leads to the need of choosing performance over security
level or vice-versa. For example, after analyzing the efficiency
of several traditional block ciphers in WSNs, Law et al. [7]
recommends AES [14] and Skipjack [15] for scenarios with,
respectively, high and low security requirements. Due to this
urge for security in many important scenarios and to the need
of sufficiently lightweight solutions, some algorithms specifically
designed for WSNs have been proposed and analyzed in
the last years, such as TinyTate [11] (for key management),
Curupira [16], [17] (block ciphers) and Marvin [18] (a MAC
algorithm).
Despite their importance for providing further information

about the impact of security mechanisms on WSNs, these

studies lack a more detailed comparison with core tasks not
related to security, such as sensing and transmitting data. In
this work, we focus on the performance evaluation of basic
tasks (such as sensing and communication) and the execution
of security algorithms on our WSN testbed, as well as the
overhead introduced by the Operating System. We consider the
same set of experiments on both TinyOS [19] and Contiki [20]
operating systems, running on the Crossbow TelosB sensor
node. Since the same hardware platform is used, we are
able to see how the tasks behave in the different OS, and
how that affects the performance of the sensors. Our metrics
are the execution time and energy consumption of common
tasks (communication and sensing), which are compared with
encryption algorithms (namely, Curupira, Skipjack and AES),
Message Authentication Codes (Marvin and CMAC [21]),
and authenticated-encryption schemes (OCB [22] and LetterSoup
[18]). Therefore, our main contribution in this work is
the performance analysis of main WSN tasks (i.e., sensing,

processing and communication) running in two different OS’s

in the same hardware platform.
The remainder of this paper is organized as follows. Section
II details our testbed. In Section III the performance
evaluation methodology is described. Our results and analysis
of the different tasks on both OS are presented in Section IV.
We conclude the paper and discuss future work in Section V.

Body Starts here {make 2 outputs one as Structure of WSN second

as requirements of TinyOS regarding WSN}
[paper#02]

2. The Design Target of Operating System for WSN Node

Generally, the WSN node is a micro embedded system. Its process
capability, storage capability and communication capability are
inferior to the normal embedded system, and it
works by taking the energy limited batteries with itself to get the
power [6].
2.1. The Structure of WSN Node
Although we use unlike sensor nodes in different material
applications, usually, the WSN node is make up of data collection
module, data processing module, wireless communication module,
power supply module and etc[7,8]. The structure of sensor node is
shown in Fig.1.

[or use this and explain respectively]

 Location finding system Mobilizer

Processing Optional part

Sensing Unit
Unit
Processor Transceiv
Sensor ADC
Storage er

Power Unit Power

generator

Components of a Sensor Node

1Data collection Module This module is composed by kinds of

sensors and assistant
circuit. It presides over the collection of information and
conversion of data.
2Data Processing Module The data processing module is the
compute center of WSN
node, and generally, it is an embedded CPU. This module takes the
charge of controlling the tasks of sensors, such as saving and
disposing the data gathered by its data collection module or
transmitted by other nodes.
3Wireless Communication Module The wireless communication
module is mainly formed by
low power and short-haul wireless radio-frequency circuit and
transceiver. It sees for communicating and exchanging control
messages with other nodes and incepting and sending data.
Presently, the wireless radio-frequency receive chips that are used
mostly are RFM’s TR1000 and Chipcon’s CC1000 and CC2420.
4Power Supply Module It is made up of power supply unit and
dynamic power
management unit. This module provides the required power for
sensor node, mostly, it is chemical battery.

Operating System for WSN Node The WSN node operating

system provides essential
software auspice to sensor node and answers for managing the
node’s hardware resource and scheduling tasks for different
applications.
2.2. Requirement on WSN Node Operating System
For the diversity of WSN’s applications, the operating system for
the node must fulfill the strict requirements for different
applications according to the memory, processor and power. Also,
the operating system has to grant kinds of programs use the system
resource synchronously [9], such as communication, computing
and storage.
In the WSN, the single node has two extrusive traits. One of the
traits is the operations are subsequent, that means there may be
exist several logic control which need to be execute synchronously.
This trait requires the operating system can satisfy these kinds of
logic control flows effectively. The other trait is the WSN node
need to be modularizing. This asks the operating system can allow
the application programs make control of the hardware expediently
and the segments of application programs can be reset
conveniently with the guarantee from impacting the whole
spending.
Thus, the operating system for WSN node should fulfills the
demands as follow:
1 Small code quantity. For WSN node’s memory is limited, it
asks the operating system’s kernel code must as smaller as
possible. Then the operating system can manage the hardware
effectively in the limited space.
2 Modularization. The trend of WSN’s design is for specifically
applications and different applications use unlike hardware
platform. As the abroad applications of WSN, the changes of node
become huge. Thus it is very important to achieve application for
given hardware platform fleetly and expediently through
integrating software modules.
3Low power. Most of the WSN’s nodes adopt batteries to get
power. There are thousands of nodes and the circumstance that
nodes are bestrewed make it impossible to replace
batteries for the nodes, so the low power operating system can
extend the life cycle for the whole network. The operating system
for WSN must accord with this qualification.
4Subsequent operation. There exist a lot of subsequent operations
on WSN node, such as data sampling, data processing and data
transmitting might carry out synchronously. The operating system
for WSN needs to have the capability of sustaining strict
subsequent operations.
5Robustness. The large quantity of WSN node and the specialty of
its run circumstance call for the operating system working on
single node are robust. And the operating system should be
seasoned with the development of distributing applications
expediently.

If below slide u find suitable anywhere!!

Energy Consumption in Each Sensor Node

Each sensor node has limited energy supply

Nodes may not be rechargeable
Energy consumption in
Sensing
Data processing
Communication (most energy intensive)