116 (IJCNS) International Journal of Computer and Network Security,

Vol. 2, No. 2, February 2010

Efficient Code Dissemination

Reprogramming Protocol for WSN
R.P.Shaikh 1, Dr. V.M. Thakare2, Dr. R.V. Dharaskar3
1
Computer Science Department
GHRCE, Nagpur
rpshaikh@gmail.com
2
HOD , Computer Science Department
GHRCE, Nagpur.
rvdharaskar@gmail.com

3
HOD , Computer Science Department
SGB Amaravati University.
vilthakare@rediffmail.com

Abstract: Network reprogramming is a way of reprogramming can disseminate efficiently a large data object from one node
wireless sensor nodes by disseminating the program code over to many other nodes over an entire wireless sensor network.
radio for uploading new code or for changing the functionality The three important steps for code dissemination
of existing code.. Existing reprogramming protocols, such as protocols is: advertisement of available software, selection
Deluge,achieve this by bundling the reprogramming protocol of a source, and reliable download to the target,which may
and the application as one program image, hence it increases then become a source in turn (Figure1).
the overall size of the image which is transferred through the
network. This increases both time and energy required for
network reprogramming. A proposed protocol divides the code
image into application and reprogramming support. It pre-
installs the reprogramming protocol as one image and the
application program equipped with the ability to listen to new
code updates as the second image that mitigates the above
problem.

Keyword : Wireless Sensor Network, Sensor, Wireless

reprogramming, code dissemination.

1. Introduction Figure 1. Three Way handshake for code distribution

A wireless sensor network is expected to consist of a
potentially large number of low-cost, low-power, and
multifunctional sensor nodes that communicate over short
distances through wireless links. Due to their potential to
provide fine-grained sensing and actuation at a reasonable
cost, wireless sensor networks are considered ideal
candidates for a wide range of applications, such as industry
monitoring, data acquisition in hazardous environments,
and military operations. It is desirable and sometimes
necessary to reprogram sensor nodes through wireless links
after they are deployed, due to, for example, the need of
removing bugs and adding new functionalities. The process
of propagating a new code image to the nodes in a network
is commonly referred to as code dissemination.
Traditionally, reprogramming was done manually.
Therefore, nodes were reprogrammed one by one. However,
as the size of sensor nodes becomes larger and larger this
technique is not very efficient. What is more, it might be
impossible to collect all the nodes from the field and then to
reprogram them. Hence, reprogramming needs to be
accomplished without physical contact with the nodes. A
reliable data dissemination protocol is to be implemented
which takes under consideration the previous factors and
Thus, reprogramming sensor nodes, i.e. changing
the software running on sensor nodes after deployment, is
necessary for sensor networks. A scheme is required to
wirelessly reprogram the nodes The scenario poses many
challenges, of them being energy, bandwidth and
reprogramming. Requirements and Properties of Code
Distribution are :
1. The complete image, starting from specific points in the
network, must reach all the nodes. This is a requirement.
We do not consider the ex- tended problem of reaching only
a subset of the nodes.
2. If the image cannot fit into a single packet, it must be
placed in stable storage until the transfer is complete, at
which point the node can be safely reprogrammed. This is
also a required property.
3. The lifetime of the network should not be severely
affected by the distribution operation. This is a desirable
property.
 (IJCNS) International Journal of Computer and Network Security, 117
4. The memory and storage requirements of the mechanism
should not be very high since that would limit the available
space for the normal application. This property is also
desirable.
2. Relatedwork
Code dissemination protocols have been developed to
propagate new code images using the wireless network
formed by the sensor nodes. Data dissemination in wireless
networks, retransmission of broadcasts can lead to the
broadcast storm problem, where redundancy, contention,
and collisions impair performance and reliability. Scalable
Reliable Multicast (SRM) is a reliable multicast mechanism
built for wired networks [15], using communication
suppression techniques to minimize network congestion and
request implosion at the server. SPIN-RL is an epidemic
algorithm designed for broadcast networks that makes use
of a three phase (advertisement-request-data) handshaking
protocol between nodes to disseminate data [16]. The
epidemic property is important since WSNs experience high
loss rates, asymmetric connectivity, and transient links due
to node failures and repopulation. However, their results
show control message redundancy at over 95% as it only
considers the suppression of redundant request messages,
and SPIN-RL does not perform as well as naive flooding for
lossy network models.
The earliest network reprogramming protocol XNP[17]
only operated over a single hop and did not provide
incremental updates of the code image. . A special Boot
Loader must be resident in a reserved section of program
memory, and the xnp protocol module must be wired into an
application (to allow for subsequent XNP updates). A host
PC application xnp loads the image, via a base station mote
running TOSBase (this acts as a serial-to-wireless bridge) to
one (mote-id specific) or many (group-id specific) nodes
within direct radio range of the base. The image is sent in
capsules, one per packet; there is a fixed time delay between
packet transmissions. In unicast mode, XNP checks delivery
for each capsule; in broadcast mode, missing packets are
handled, after the full image download has completed, using
a follow-up query request (nodes respond with a list of
missing capsules). The program is loaded into external
(nonprogram) memory. Applications are halted during the
program download. When a reboot command is issued (via
the xnp host program), then the boot loader is called: this
copies the program from external to program memory, and
then jumps to the start of the new program.
MOAP [4] is a multi-hop, over-the-air code distribution
mechanism. It uses store-and-forward, providing a ‘ripple’
pattern of updates; lost segments are identified by the
receiver using a sliding window, and are re-requested using
a unicast message to prevent duplication; a keep alive timer
is used to recover from unanswered unicast retransmission
requests – when it expires a broadcast request is sent. The
basestation broadcasts publish messages advertising the
version number of the new code. Receiving nodes check this
against their own version number, and can request the
update with subscribe messages. A link-statistics
mechanism is used to try to avoid unreliable links. After
waiting a period to receive all subscriptions, the sender
Vol. 2, No. 2, February 2010
then starts the data transfer. Missing segments are requested
directly from the sender, which prioritises these over further
data transmissions. Once a node has received an entire
image, it becomes a sender in turn. If a sender receives no
subscribe messages, it transfers the new image to program
memory from EPROM, and reboots with the new code.
Sliding window acknowledgements reduce power
consumption (reduced EEPROM reads) at the cost of
reduced out-of-order message tolerance. There is no support
for rate control, or suppressing multiple senders (apart from
link statistics).
Trickle[6] runs under TinyOS/Mate – it acts as a service
to continuously propagate code updates throughout the
network. Periodically (gossiping interval τ) using the
maintenance algorithm every node broadcasts a code
summary (‘metadata’) if it has not overheard a certain
number of neighbours transmit the same information. If a
recipient detects the need for an update (either in the sender
or in the receiver) then it brings everyone nearby up to date
by broadcasting the needed code. Trickle dynamically
regulates the per-node, Trickle-related traffic to a particular
rate (rx + tx), thus adjusting automatically to the local
network density. This scales well, even with packet loss
taken into account. A listen-only period is used to minimise
the short-listen problem (where de synchronised nodes may
cause redundant transmissions due to a shift in their timer
phases). The CSMA hidden-terminal problem does not lead
to excessive misbehaviour by Trickle, as long as the traffic
rate is kept low. By dynamically changing the gossip
interval, Trickle can propagate changes rapidly, while using
less network bandwidth when there are no known changes.
Programs fit into a single TinyOS packet.
3. System Models
The conventional reprogramming protocol system model for
sensor networks is depicted in figure 2, in which the code
images are propagated from base station to every sensor
node in the network
Figure 2. Reprogramming model for sensor network
118 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 2, February 2010

4. The three substantially more sophisticated Deluge[6] is a density-aware protocol with epidemic
protocols : behavior that can help propagate the code reliable over
unpredictable network conditions. It represents the data
object as a set of fixed-size pages, a key feature needed for
4.1 MNP
spatial multiplexing. Deluge is based on protocol Trickle , a
protocol designed for manipulating code updates in sensor
The design goal of MNP[8] is to choose a local source of
networks. Deluge's basinality (borrowed from Trickle) is the
the code which can satisfy the maximum number of nodes.
suppression and dynamic adjustment of the broadcast rate
They provide energy savings by turning off the radio of non-
so as to limit the transmitted messages among n. Deluge
sender nodes. MNP is targeted at MICA2 motes running
uses an epidemic protocol for efficient advertisement of
TinyOS and uses the XNP boot loader along with a
code meta data and spatial multiplexing for efficient
dedicated network protocol to provide multi-hop, in-network
propagation of code images. Deluge is generally accepted as
programming. The MNP protocol operates in 4 phases:
the state of the art for code dissemination in wireless sensor
1. Advertisement/Request, where sources advertise the new
networks, and has been included in recent TinyOS
version of the code, and all interested nodes make requests.
distributions
Nodes listen to both advertisements and requests, and decide
Deluge is a data dissemination protocol and algorithm for
whether to start forwarding code or not (this acts as a
propagating large amounts of data throughout a WSN using
suppression scheme to avoid network overload);
incremental upgrades for enhanced performance. It is
2. Forward/Download, where a source broadcasts a
particularly aimed at disseminating software image updates,
StartDownload message to prepare the receivers, and then
identified by incremental version numbers, for network
sends the program code a packet at a time (in packet-sized
reprogramming. The program image is split into fixed size
segments) to the receivers to be stored in external memory
pages that can be ‘reasonably’ buffered in RAM, and each
(EEPROM) – there is no ack, the receiver keeps a linked-list
page is split into fixed size packets so that a packet can be
of missing segments in EEPROM to save RAM space;
sent without fragmentation by the TinyOS network stack. A
3. Query/Update, where the source broadcasts a Query to all
bit vector of pages received can be sent in a single TinyOS
its receivers, which respond by unicast by asking for the
network packet. Nodes broadcast advertisements containing
missing packets (segments) – these are then rebroadcast by
a version number and a bit vector of the associated pages
the source node, and then another Query is broadcast until
received, using a variable period based on updating activity.
there are no requests for missing packets. The receivers,
If a node determines that it needs to upgrade part of its
having received the full image, now become source nodes
image to match a newer version, then, after listening to
and start advertising the new program;
further advertisements for a time, it sends a request to the
4. Reboot, entered when a source received no requests in
selected neighbour for the lowest page number required, and
response to an advertisement, where the new program
the packets required within that page. After listening for
image is transferred to program memory, and the node
further requests, the sender selects a page, and broadcasts
reboots with the new code. A node sends a download
every requested packet in that page. When a node receives
request to all senders, this assists in sender selection, and
the last packet required to complete a page, it broadcasts an
also allows the hidden terminal effect to be reduced (as
advertisement before requesting further pages – this
other potential senders can overhead this request). The
enhances parallelisation (‘spatial multiplexing’) of the
sender selection algorithm attempts to allow only one active
update within the network (as the node can now issue
sender in a particular neighborhood.
further requests in parallel with responding to requests from
other nodes). The protocol keeps the state data to a fixed
4.2 FRESHET
size, independent of the number of neighbours. There are no
ACK’s or NACK’s – requesters either request new pages, or
Freshet[10] is different in aggressively optimizing the
re-request missing packets from a previous page. There is
energy consumption for reprogramming. It introduces a new
no global co-ordination to select senders; heuristics are used
phase called blitzkrieg when the code update is started from
to try and elect relatively remote senders in order to
the base node. During the blitzkrieg phase, information
minimise radio network contention. Incremental updating is
about the code and topology (primarily the number of hops
supported through the use of Complete Advertisements
a node is away from the wave front where the code is at)
which indicate which pages in an image have changed since
propagates through the network rapidly. Using the topology
the previous version; requesters can then request just the
information each node estimates when the code will arrive
changed pages. Future versions of Deluge are expected to
in its vicinity and the three way handshake will be initiated
address the following issues: control message suppression,
– the distribution phase. Each node can go to sleep in
running updates concurrently with applications, explicitly
between the blitzkrieg phase and the distribution phase
reducing energy consumption, and support for multiple
thereby saving energy. Freshet also optimizes the energy
types and versions of images.
consumption by exponentially reducing the meta-data rate
during conditions of stability in the network when no new
code is being introduced, called the quiescent phase. 5. Proposed Protocol

4.3 DELUGE Each protocol discuss above transfers the image of the entire
reprogramming protocol together with the minimally
necessary part.The researchers have found that it is difficult
 (IJCNS) International Journal of Computer and Network Security, 119
to improve over Deluge the rate of transfer of data over the
wireless link. Hence to optimize what needs to be
transferred, keeping the basic mode of transfer the same as
in Deluge ,transfer just what is needed, in other words, the
application code (or the code of the updates to the
application).This idea gives rise to our proposed protocol.It
transfers close to the minimally required image size by
segmenting the total program image into an application
image and the reprogramming image.(Application image
refer to the user application , reprogramming image refer to
protocol component for protocol, such as MNP ,Deluge or
Freshet) The benefit of our protocol shows up in fewer
number of bytes transferred over the wireless medium
leading to increased energy savings and reduced delay for
reprogramming
5.1 Protocol Description
An application is modified by linking it to a small
component called Application Support (AS) while
Reprogramming Support (RS) is pre-installed in each node.
Overall, design principle is to limit the size of AS and
providing it the facility to switch to RS when triggered by a
code update related message.
Consider that initially all nodes have RS as image 0 and
the application with AS as image 1 Each node is executing
the image 1 code. The node that initiates the
reprogramming is attached to a computer through the serial
port and is called the base node. Following is the
description of how Stream works when a new user
application, again with the Stream-AS component added to
it, has to be injected into the network.
1.Reboot procedure takes place as follows:
a. The base node executing image 1 initiates the process by
generating a command to reboot from image 0. It broadcasts
the reboot command to its one hop neighbors and itself
reboots from image 0.
b. When a node running the user application receives the
reboot command, it rebroadcasts the reboot command and
itself reboots from image 0.
2.When all nodes receives reboot command they all start
running RS. Then the new user application is injected into
the network using RS.
3.Reprogramming of entire network stars using three way
handshake as discussed above. Each node maintains a set S
containing the node ids of the nodes from which it has
received the requests for code.
4. Once the node downloads the new code completely, it
performs a single-hop broadcast of an ACK indicating it has
completed downloading.
5. When a node receives the ACK from a node, it removes
the id of from its set S.
6. When the set S is empty and all the images are complete
and after sometime entire network is reprogrammed and
nodes will reboot from apllcation support.
5.2 Advantages :
•Reduce transmitted bit over wireless medium leading to
increased energy savings and reduced delay for
reprogramming
Vol. 2, No. 2, February 2010
•Reduce programming time, energy costs and program
memory
•Improve the protocol for a new node to get image from
network
•It optimizes the steady state energy expenditure by
switching from a push-based mechanism where periodically
node sends advertisements to pull based mechanism where
newly inserted node request for the code.
•In Freshet to save energy the sleeping time of node is to be
estimated prior and this estimation if often found inaccurate
due to variability of the wireless channel however stream
protocol achieve this goal by rebooting the node from
Stream-RS only when new node arrives at one of its
neighbors thus the user application running on the node can
put the node to sleep till the time to reboot comes. This
opportunistic sleeping feature conserve energy in resource
constrained sensored network.
•In Deluge, once a node’s reprogramming is over, it keeps
on advertising the code image it has hence radio resources
are continuously used in the steady state but in stream
,Stream-AS does not advertise the data it has .
5.3 Evaluation Results
With the help of reprogramming using the ns-2 simulator
we have to evaluate the message inter-arrival period and
compared it with the total energy consumption of the sensor
nodes. Indeed our aim is to compare our proposed protocol
with the known Deluge protocol [6] for wireless sensor
network and obtain the result and graph as displayed in
Table I.and fig 3. Main objective is observe that the energy
consumption has also been reduced because of the reduction
in the overall size of the program image that needs to be
transferred over the wireless medium which may increase
the time and energy required for reprogramming the sensor
nodes. Thus fewer number of bytes transferred over the
wireless medium leading to increased energy savings and
reduced delay for reprogramming
Table 1: Time Taken for Download Phase
Code Size Download
time
Case 1 45.2 KB 112 sec
Case 2 54.3 KB 120 sec
Case 3 67.8 KB 135 sec
Case 4 75.7 KB 139 sec
Case 5 80.2 KB 141 sec
120 (IJCNS) International Journal of Computer and Network Security,
Figure 3. Message inter arrival period (SEC)
Other Parameters of implementation on ns-2 is as shown in
in Table II
Table 2: Parameters for Implementation on ns2
There are a number of open research problems common to
all the classes:
1.Before initiating an update, it would be invaluable to be
able run a model (such as a simulation) to
determine/analyze reprogramming time and the energy cost
of different update options on the current network
configuration, and thus allow the user to make informed
tradeoffs against energy. For example: which is the best
injection strategy for the current configuration? What size
reduction technique will result in the quickest update? etc.
2. There is not yet a definitive answer to the best way to
reduce the size of updates, with modular, differences-based,
and compression all showing promise in different
circumstances.
3. There are a number of different injection strategies in
use: simulating a base station, sending the update to a base
Vol. 2, No. 2, February 2010
station for dissemination, sending the update to a number of
seed nodes for further dissemination, and sending the
update individually to each node.
4. It is likely that an energy aware approach will have to be
taken in order to respond to current energy patterns in a
sensor net (ref. energy-aware MAC layers, and energy-
aware Routing).
5.In order to support the various possible patterns in which
software updates may be received, and to support any
requirements for backwards and forwards version
compatibility, tighter control over the order of node
activation will be required.
6. There are a number of aspects of this which are not
directly related to software updating, but the key ones which
are related are: checking the downloaded software before
activation (integrity, version mismatches, platform
mismatches) and dynamically checking the operation of the
downloaded software after is has been activated. It is likely
that further advances will be necessary in this area, probably
using techniques from autonomic computing, to increase the
robustness of software updates.
7. There is a need for tools to monitor the ‘version’ state of
a WSN and report status and problems to an operator/user.
These will be able to use existing techniques for fusing data
to reduce the overhead, and for tracking update-related
faults.
8. The normal issues of: key-distribution, authentication,
secrecy, integrity, and authorization needing to be
addressed. Results from existing WSN security research will
be needed, along with other work specific to the software
update problem.
9. The protocols used need to be energy-aware, so that the
current energy-state of both individual nodes and the entire
network can be taken into account during an update.
10. Recovering from faulty updates methods are required
before execution and during execution has been done
6. Conclusion
This paper examines the challenges of incorporating
scalable bandwidth management scheme and reducing the
reprogramming time, the number of bytes transferred, the
energy expended, and the usage of program memory for
wireless reprogramming in WSN environment with brief
description of some existing proposals that specifically
address this problem .
In future analysis of parameters as shown in table I &
tableII by Simulation experiments to show the increasing
advantages of proposed protocol over Deluge with larger
network sizes. Certain issues were not addressed in this
work, like the security issue, reliability etc. If an
acknowledgement/code segment lost in a particular hop of
multihop network due wireless medium constraints, then the
nodes which are in that hop have to take some necessary
actions to achieve reliability.
References
[1] P. Levis, N. Patel, S. Shenker, D. Culler, “Trickle: a
selfregulating algorithm for code propagation &
 (IJCNS) International Journal of Computer and Network Security, 121
maintenance in wireless sensor network,” in:
Proceedings of the First USENIX/ACM Symposium on
Networked Systems Design and Implementation “ (NSDI
2004) .
[2] “Remote Incremental Linking for Energy-Efficient
Reprogramming of Sensor Networks”,Joel Koshy & Raju
Pandey University of California, Davis, California
95616, USA.
[3] J.W. Hui, D. Culler, The dynamic behavior of a data
dissemination protocol for network programming at
scale, in: The Proceedings of the Second International
Conference on Embedded Networked Sensor Systems,
Baltimore, MD,USA, 2004, pp. 81–94.
[4] T. Stathopoulos, J. Heidemann, D. Estrin, A remote
code update mechanism for wireless sensor networks,
Technical Report CENS Technical Report 30, 2003.
[5] Synapse: A Network Reprogramming Protocol for
Wireless Sensor Networks using Fountain Codes”
Michele Rossi, Giovanni Zanca, Luca Stabellini
Riccardo Crepaldi, Albert F. Harris III and Michele
Zorzi Dept. of Information Engineering, University of
Padova, 35131 Padova, Italy.
[6] R.K. Panta, I. Khalil, S. Bagchi, “Stream: low
overhead wireless reprogramming for sensor networks,
in: Proceedings of the 26th IEEE International
Conference on Computer Communications (INFOCOM),
May 2007, pp. 928–936.”
[7] M. D. Krasniewski, S. Bagchi, C-L. Yang, W. J.
Chappell, “Energy efficient, On-demand
Reprogramming of Large-scale Sensor Networks,”
Submitted to IEEE Transactions on Mobile Computing
(TMC). Available as Purdue ECE Technical Report TR-
ECE-06-02, 2006.
[8] S.S.Kulkarni and L. Wang, “MNP: Multihop Network
Reprogramming Service for Sensor Networks,” in IEEE
ICDCS, Columbus, Ohio, USA, Jun. 2005.
[9] Efficient wireless reprogramming through reduced
bandwidth usage and opportunistic sleeping,” Rajesh
Krishna Panta , Saurabh Bagchi , Issa M. Khalil a
Dependable Computing Systems Lab, School of
Electrical and Computer Engineering, Purdue University
[10] N. Reijers, K. Langendoen, “Efficient code distribution
in wireless sensor networks, in:” Proceedings of the
Second ACM International Conference on Wireless
Sensor Networks and Applications (WSNA), 2003, pp.
60–67.
[11] J. Koshy, R. Pandey, “Remote incremental linking for
energy efficient reprogramming of sensor networks” in:
Proceedings of the Second European Workshop on
Wireless Sensor Networks (EWSN), 2005, pp. 354–365
[12] “Updating Software in Wireless Sensor Networks: A
Survey” S. Brown, Dept. of Computer Science, National
University of Ireland, Maynooth C.J. Sreenan, Mobile &
Internet Systems Laboratory, Dept. of Computer Science,
University College Cork, Ireland Technical Report
UCCCS- 2006-13-07
[13] Shen,, Srisathapornphat, Jaikaeo: “Sensor Information
Networking Architecture and Applications”. In: Proc. of
the International Workshop on Pervasive Computing,
Toronto, Canada, August. IEEE(2004) 52-59
Vol. 2, No. 2, February 2010
[14] Stann, F., Heidemann, “RMST: Reliable Data
Transport in Sensor Networks”. In: Proc. of the 1st IEEE
Intl. Workshop on Sensor Network Applications and
Protocols. IEEE (2003) 102-112
[15] Beutel, J., Dyer, M., Meier, Ringwald, Thiele: Next-
Generation Deployment Support for Sensor Networks.
TIK-Report No: 207. Computer Engineering and
Networks Lab, Swiss Federal Institute of
Technology(ETH), Zurich (2004)
[16] S. K. Kasera, G. Hj´almt´ysson, D. F. Towsley, and J.
F.Kurose. “Scalable reliable multicast using multiple
multicast channels. IEEE/ACM Transactions on
Networking, 8(3):294–310, 2000.”
[17] J.Kulik, W. R. Heinzelman, and H.Balakrishnan.”
Negotiation-based protocols for disseminating
information in wireless sensor networks. Wireless
Networks,8(2-3):169–185, 2002.”
[18] Crossbow Tech Inc.,” Mote In-Network Programming”
User Ref, http://www.tinyos.net/tinyos 1.x/doc/Xnp.pdf,
2003
[19] Q.Wang, Y.Y. Zhu., L. Cheng, “Reprogramming
wireless sensor networks: challenges and approaches”,
IEEE Networks, 2006, 20(3): 48.
[20] A. Chlipala, J. Hui, and G. Tolle. Deluge: Data
dissemination for network reprogramming at scale.
Authors Profile
Dr V M Thakare is Professor
and Head of PG department of
computer Science and Engg in
SGB Amravati University
Amravati, Maharastra (India) and
has completed ME in Advance
Electronics and Ph.D. In computer
Science/Engg. His Area of
Research are Robotics and Artificial Intelligence,
Information Technology. He is Recognized Giude for
computer science and computer engineering in this
University and In other universities also. He has also
received received national level Award for excellent paper
award. More than 10 candidates are working for Ph D
Under his supervision. He has Published and presented
more than 115 papers at National and international level.
He has worked on various national level bodies like
AICTE/UGC and also worked on various bodies of other
universities. He is presently member of BOS, RRC, BUTR
of this university and also chairman and Member of various
committees of this university .
Dr. Rajiv Dharaskar is presently
working as Professor at PG
Department of Computer Science and
Engineering, GH Raisoni College of
Engineering, Nagpur. He is Ph.D. in
Computer Science & Engineering in
the Faculty of Engineering &
Technology, M.Tech. in Computers,
P.G. Dip., M.Phil., and M.Sc. He is
122 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 2, February 2010

having 24 years of teaching and 18 years of R&D

experience in the field of Computers & IT. He is approved
PhD guide for Computer Engineering and Science for
Nagpur and Amravati University and 22 research scholars
are perusing Ph.D. degree under his guidance. He is an
author of number books on Programming Languages.

Riyaz Shaikh received B.E degree in

Computer Technology from Nagpur
University.Joined as MIS INCHARGE
in Govt Project at ZP.Before that she
also worked as Lecturer in Polytechnic
and MCA college. Presently perusing
Master of Engineering degree in
Wireless communication and
Computing branch under Computer Science department at
GHRCE , Nagpur university , India . Her area of interest
are wireless adhoc and sensor network.