2010 Second International conference on Computing, Communication and Networking Technologies
SPIN Implementation in TinyOS Environment using nesC Zeenat Rehena1, Krishanu Kumar2, Sarbani Roy2, Nandini Mukherjee2 1
School of Mobile Computing and Communication, Jadavpur University Department of Computer Science & Engineering, Jadavpur University Kolkata – 700 032, India
[email protected],
[email protected],
[email protected],
[email protected]
2
Abstract- In this paper we present the simulation result of Sensor Protocol for Information via Negotiation (SPIN), a wireless sensor routing protocol, using TinyOS and nesC. TinyOS is a widely used operating system for modern wireless sensors, as its modular system is flexible and powerful. But programming with TinyOS can be challenging because it requires a new language, nesC. SPIN protocol is a data-centric routing protocol for Wireless Sensor Network (WSN). SPIN fits under event-driven delivery model. For implementing SPIN we divide the protocol into three phases. These are Initialization phase, DataCollection phase and Negotiation phase. The protocol is simulated in TOSSIM simulator which is an integral part of nesC.
I.
INTRODUCTION
In the last few years, the number of sensor node platforms has increased in a significant way. Parallely, an operating system was developed especially for wireless sensor network [3]-[5] (WSN). TinyOS [1] is an open source operating system based on nesC [2] which is a component descriptor language. WSN is composed of large number of sensor nodes which are small in size, low cost and have limited memory size. These individual nodes are able to interact with their environment by sensing or controlling physical parameters. These nodes collaborate amongst themselves in order to fulfill their tasks since a single node is incapable of doing so. They have no fixed topology, but it is possible to deploy thousands of sensor nodes in a vast area. Generally, the sensor nodes work unattended and transmit their observed values to base node or sink node which serve as an intermediary between the user and the WSN. The important features of a WSN set-up are:-it is infrastructure-less and has self-organizing capability. The networks may consist of different types of sensors such as seismic, thermal, visual, etc. which are able to monitor a wide variety of ambient conditions. On the other hand, there is no disbelief that TinyOS has the most important role in the WSN, because it provides a common reference for the researchers to cooperate and to come up with different solutions. TinyOS provides the easiest way to write WSN applications, but it is neither simple nor trivial. Since the hardware in the sensor nodes has become
978-1-4244-6589-7/10/$26.00 ©2010 IEEE
more heterogeneous and more platforms exist, the applications’ portability becomes extremely complex. TinyOS is a tiny operating system developed at the University of California, Berkeley which is an event-based embedded operating system. Its main objective is to design and develop a high concurrency system which is low in energy consumption. The developers have introduced four different types of technology in the TinyOS to solve the requirements of WSN. These four technologies are: light-threaded, initiative information, event-driven and component-based programming. Sensor node(s) should report to the sink(s) or base node (s) once they have data events matching their tasks. For this type of interaction, generally more than one sensor nodes are required. Most sensor applications process the data gathered from multiple sensor nodes. So for this collaborative activity we need a routing algorithm to route the data efficiently and reliably. Also, sensor nodes are constrained in terms of transmission power, on-board energy, processing capacity and storage. Routing algorithms are invented to negotiate many aspects like faster data reach, energy savings and to avoid redundancy. There are several types of routing algorithms used in WSN. Data-centric routing protocol is one of them. It requires attribute based naming [5], [8], [9]. For attribute based naming, the users are more interested in querying an attribute of the phenomenon, rather than querying an individual node. Attribute based naming is used to carry out queries by using the attributes of the phenomenon. Attributebased naming also makes broadcasting, attribute-based multicasting, and any-casting important for sensor networks. This paper mainly focuses on SPIN routing algorithm. It belongs to data-centric routing protocol. Here sensor nodes broadcast an advertisement i.e. metadata representing the available data and wait for a response requesting data from the interested neighboring nodes. The negotiation is done before sending the actual data. This paper describes the implementation of SPIN [7], [8] protocol using TinyOS and nesC. The paper is organized as follows. A short description of TinyOS and nesC is given in section II. Algorithm of SPIN protocol is described in section III-A and implementation detail is given in section III-B. The
nesC components, which are used to implement the SPIN protocol, are defined in section III-C. In section IV the simulation environment and test results are given and we conclude the paper in section V. II. TINYOS AND nesC TinyOS is an embedded operating system developed to meet the needs of wireless sensor networks. It consists of a large collection of components which are useful in networked embedded systems, such as communication, timing, and lightweight task scheduling. TinyOS is not a hard real-time operating system, but provides a component-based, event driven programming model within a very small footprint. TinyOS applications are constructed as a graph of components which interact with each other, and also with the underlying TinyOS scheduler and platform hardware. Actually, TinyOS is a set of software components that can be “wired” together into a single binary which is run on the motes. The nesC language was created to support TinyOS. nesC programs are prepared as compositions of interacting components. These components come in two flavors: modules, which implement specific functionality, and configurations, which define connections between components. Each nesC component has one or more interfaces. These interfaces define how the component directly interacts with other components. Generally, interfaces consist of commands and events. Commands are requests to perform some services, while events are mechanisms for signaling to a component that an activity it requested has been completed, or that an external phenomenon such as an interrupt has occurred. Again a component has two classes of interfaces: those it provides and those it uses. A component that provides an interface must implement functions for each command in the interface, and may signal any of the events, while a component that uses an interface must implement functions to handle each event in the interface, and may call any of the commands. Configuration component wires interface providers to interface users. An interface generally models some service, e.g. sending a message, and is specified by an interface type. Figure 1 shows a simplified form of the TimerM component, part of the TinyOS timer service that provides the StdControl and Timer interfaces and uses a Clock interface.
module TimerM { provides { interface StdControl; interface Timer[uint8_t id]; } uses interface Clock; } Figure 1: Graphical representation TimerM component and nesC specification
In the above figure provided interfaces are shown above the TimerM component and used interfaces are below it. The
downward arrowheads depict commands and upward arrowheads depict events of the interfaces. Every TinyOS application is described by a top level configuration that wires together different components used to build the application. III. SPIN PROTOCOL SPIN is a data-centric [7], [8], [12], [13] routing protocol for WSN. It disseminates all the information from each node to every other node in the network. It includes two aspects. One, the sensor nodes negotiate with each other before transmitting the actual data. Meanwhile, the node confirms that whether it has received the same information for that metadata. Second, each node in the network must monitor the consumption of energy. It is basically a three-way handshake protocol. This enables a user to query any node and get the required information immediately. SPIN uses three types of message structure for its operation. These are ADV, REQ and DATA. Initially, nodes broadcast advertisement packet to all the neighbor nodes using ADV packet format mainly called metadata. If any node is interested for that advertisement packet, then REQ packet is sent to the advertiser to request the data. Finally, after getting REQ, the advertising node sends actual data using DATA packet to the requesting node. SPIN protocol is best suited where event-driven application is needed. A. Algorithm: SPIN We divide SPIN protocol in three parts: Initialization phase, DataCollection phase and Negotiation phase. The initialization phase is shown in Figure 2. In the Initialization phase all the sensor nodes are first synchronized to the global time. After synchronization, a sensor application program is run and DATA packets are generated periodically.
Figure 2: Initialization phase
In the DataCollection Phase, each node obtains DATA packet either from its own sensing application or from its neighbors. The DATA packet contains the address of the origin node, sequence number and a payload containing timestamp and sensor reading. The node stores that payload in its own memory. Then it starts negotiation. The DataCollection phase is represented in Figure 3. This is a
continuous process for data collection. Data is collected periodically until node is switched off or down. In the Negotiation phase, a small metadata is ADV is sent before sending actual DATA packet. On receiving ADV, neighbors request the advertiser using REQ packet for the corresponding data. Finally, the DATA packet is sent. This is shown in Figure 4.
origin node = A seq no. = 1254 At this moment, node B sends REQ to node A. The REQ contains the values as follows: type = REQ sending node = B origin node = A seq no. = 1254
Figure 4: Negotiation phase Figure 3: DataCollection phase
During the DataCollection phase, a node collects samples and generates the ADV packet. Then it starts negotiation phase. Consider the following example. Suppose an event has happened in the surrounding of node A, it samples some data and sends to node B. Suppose node B is interested for the data. Therefore, node A generates ADV packet so that data is propagated throughout the network. The ADV packet contains the following information: type = ADV sending node = A
B. Implementation of SPIN Protocol Whenever a node gets sensor data either from its own application or from other nodes, initially, it saves the data in its memory using the function storepkt. Also it calls function setCurrent to indicate which packet is presently residing in its memory. This is necessary because a delayed REQ for a previously advertised packet may arrive. Hence the function getCurrent is used to determine whether the received REQ is for the presently stored data. As soon as the advertiser gets an appropriate REQ packet, it broadcasts the DATA packet.
We know that a node having data, first broadcasts a metadata i.e. ADV packet. It first checks its record to ascertain whether it already has seen that data using the function chkHistory. If indeed the data is new, it sends a unicast REQ packet to the advertiser and waits for the DATA packet. Moreover, it calls setDesired to indicate which DATA packet it is waiting for. Whenever it intercepts a broadcast DATA packet it checks if this is the expected packet or not. To implement this, we used here the function getDesired. If the desired packet is received, the node updates its record accordingly. This is also done by the function updHistory. Then the node either broadcasts ADV or, if this is the sink, it forwards the packet to the serial port. For implementing the idea behind the SPIN algorithm, we used three different types of message structures. These are represented in Figure 5. The ADV and REQ message structures are same which is shown in 5(1). Each field of the message structure is described in the TABLE 1
routing component library. It is the main component of the multi-hop messaging layer and provides the packet movement logic. • MHSpinPSM: This module provides the route selection logic for the SPIN protocol. Also keeps track of data last seen from each node. • MHSpinRouter: This module wires all the components together. • MHSpinAdvM: This module provides the metadata advertisement mechanism. • MHSpinReqM: This module contains the mechanism for sending a request for data upon receiving an advertisement packet. • MyMsgM: This module provides the application driver code by sending packets containing sensor data periodically. • TimeSyncM: This module provides a basic time synchronization service for the network. Nodes synchronize to a network global time. The component diagram for the above components is shown in Figure 6.
(1)
(2) Figure 5: Message structure. ADV & REQ message structure (1). DATA message structure (2) TABLE 1 DESCRIPTION OF MESSAGE STRUCTURE Sl. No. 1
Field name Type
2
Origin Node
3 4 5
Sending Node Seq No. Timestamp
6 7
Info Address
Description Indicates the type of the message. e.g. ADV Source node’s id which has data about event Id of the sending node Packet sequence no. Indicates at what time the event was generated Actual sensor reading Address of the source node
C. Required Component This section explains the required components for the SPIN protocol. The required components for overall mechanism are divided into Application Module and Routing Module. In order to detect an event a simple application is used. • MHEngineM: This module is a modified version of MultiHopEngineM which is the actual TinyOS multi-hop
Figure 6: Component Diagram of the Components used in the SPIN protocol
IV.
SIMULATION AND RESULT
We have simulated the SPIN protocol using TOSSIM [14] simulator of TinyOS. In order to evaluate the SPIN routing protocol using TOSSIM, it is necessary to define a lossy topology network model. Lossy topologies are defined using the following notation: :< node id>:< bit error rate>. A lossy topology is a directed graph which defines the connectivity of a sensor network. The first two parameters indicate that the second node can receive packets transmitted by the first node. The third parameter is a floating point number between 0 and 1 and gives the bit error rate of the link. All links were defined as having a 0% error rate. A. Simulation Environment TOSSIM can simulate many sensor nodes at once. We have considered a network topology consisting of 30 fixed sensor
B. Results and Discussions The Application module submits the data generated by the sensor nodes. This application uses a timer for periodically reading data. The MHSpinRouter is the configuration which wires the modules and interfaces together. This configuration also includes the message structures for multi-hop routing mechanism. The MHEngineM used in this paper is a modified version of the MultiHopEngineM component which is part of the standard TinyOS multi-hop routing library. The component provides the overall packet movement logic for multi-hop routing. It utilizes the services of the route selection module to select the next hop which is the broadcast address in this case for the packet to be sent. The MHEngineM component provides the Send interface to the higher layers in the networking stack and uses the ReceiveMsg and SendMsg interfaces of lower networking layers to send and receive data over the network. The RouteSelect interface is used to communicate with the path selection module whose implementation is discussed below. MHSpinPSM is the path selection module for SPIN protocol. It is responsible for providing the MHEngineM module with a routing decision via the RouteSelect interface. The main consideration is of course the energy usage of the network. As each node continues to sense, transmit and receive packets the total energy decreases gradually. As expected total energy consumption of the network decreases gradually with time. Figure 7 shows the results of running the application for 2 minutes in a network consisting of 30 nodes. The energy decreases at a slow rate and even after 120 seconds the network still has around 80% of initial energy. Therefore, it is concluded that use of metadata actually increases energy efficiency of the network. This is because in SPIN when a node sends advertisement i.e. ADV packet for data, it waits for the request i.e. REQ packet, thereby preventing redundant data packet transmission. Avg. Remaining Energy vs Time
Figure 7: Average Energy Remaining with Time
Figure 8 depicts the average number of packets sent and received by each node as a function of simulation time. Due to metadata negotiation SPIN sent almost zero redundant data packets and decreased the number of wasted data packets in the network. Again from Figure 8, it is obvious that data loss is consistent with the increase of time. Therefore SPIN protocol is also reliable in terms of packet transmission. Number of Packets vs Time 120 100 No. of Packets
nodes. It runs the same code that runs on sensor network hardware. Each node uses the SPIN protocol to route periodic sensor readings to the base station. The simulation is run for 10 minutes.
80 Sent Packets
60
Received Packets 40 20 0 0
10 20 30 40 50 60 70 80 90 100 110 120 Time (sec)
Figure 8: No. of sent and received packets with time
V.
CONCLUSION AND FUTURE WORK
In this paper we have implemented the SPIN protocol using nesC language. One major advantage of this protocol is the simplicity. Each node needs only its local information about the network topology. Implementation is done in nesC and we have modified the existing message structure provided by the TinyOS library for this implementation. Here TOSSIM simulator is used for simulation. For simulation purpose, we have used lossy topology. From the simulation results it is concluded that SPIN becomes much more energy efficient with time. It also reduces the redundant data packet due to meta-data negotiation. One problem existing with SPIN is that, if any node between source and destination is not interested to the ADV packet, the actual data will not reach the destination. But this work still has some drawbacks. The comparisons between SPIN and other protocols are not done here. The comparison and implementation of other protocols may be carried out in future. It may also be possible to modify the existing SPIN protocol in future to overcome problems associated with it.
Avg. Remaining Energy
120
REFERENCES
100 80 60
Remaining Energy
40 20 0 0
20
40
60
Time (sec)
80
0 10
0 12
[1] P. Levis et al., “TinyOS: An operating system for sensor networks,” in Ambient Intelligence, W. Weber, J. Rabaey, and E. Aarts, Eds. Berlin: Springer, pp. 115–148, 2005. [2] D. Gay, P. Levis, R. von Behren, M. Welsh, E. Brewer, and D. Culler, “The nesC language: A holistic approach to networked embedded systems,” ACM SIGPLAN Notices, vol. 38, no. 5, pp. 1–11, 2003. [3] I.F. Akyildiz, W.Su, E. Cayirci, Y. Sankarasubramaniam, “Wireless sensor networks: a survey”. Computer
Networks: The International Journal of Computer and Telecommunications Networking, vol. 38 no. 4, pp. 393– 422, 2002. [4] Holger Karl, Andreas Willig, “A short survey of wireless sensor networks”, TKN, Technical Report TKN-03-018, 2003. [5] Ian F. Akyildiz, Mehmet C. Vuran, Ozgur B. Akan, Weilian Su. Wireless Sensor Networks: A Survey Revisited. Computer Networks Journal (Elsevier Science), vol. 45, no. 3, 2004. [6] Carlos F. Garcia Hernandez, Pablo H. IbargüengoytiaGonzález, Joaquín Garcia Hernandez and Jesus A. PérezDíaz, Wireless Sensor Networks and Applications: a Survey, IJCSNS, International Journal of Computer Science and Network Security, Vol.7 no.3, 2007. [7] K. Akkaya and M. Younis, A Survey On Routing Protocols For Wireless Sensor Networks, Elsevier Ad Hoc Network Journal, Vol. 3 , pp. 325-349, 2005. [8] Jamal N. Al-Karaki, Ahmed E. Kamal, Routing Techniques in Wireless Sensor Networks: A Survey, Wireless Communications, IEEE, Vol. 11, no. 6, pp. 6-28, 2004. [9] J. Elson, and D. Estrin, Random, Ephemeral Transaction, Identifiers in Dynamic Sensor Networks, 21st International Conference on Distributed Computing Systems, Mesa, AZ, pp. 459-468, 2001. [10] D. Estrin, L. Girod, G. Pottie, and M. Srivastava, “Instrumenting the World with Wireless Sensor Networks,” International Conference on Acoustics, Speech, and Signal Processing (ICASSP2001), Salt Lake City, Utah, May 2001. [11] D. Janakiram, A V U Phani Kumar, A. Mallikarjuna Reddy V. Distributed Collaboration Event Detection in Wireless Sensor Networks, ACM International Conference Proceeding Series, Vol. 115, pp.1 – 8, 2005. [12] M. Ditzel, K. Langendoen. D3: Data-centric Data Dissemination in Wireless Sensor Networks, 8th European Conference on Wireless Technology, 2005. [13] W. Heinzelman, J. Kulik, and H. Balakrishnan, Adaptive Protocols for Information Dissemination in Wireless Sensor Networks, 5th ACM/IEEE Mobicom Conference (MobiCom '99), pp. 174-85, 1999. [14] P.Levis and N.Lee, TOSSIM: A Simulator for TinyOS Networks, Included with the TinyOS 1.1.0 software, 2003.
