Cost effective WSN Network Monitoring and Control using Modified SNMP

(1)

International Journal of Emerging Technology and Advanced Engineering

Website: www.ijetae.com (ISSN 2250-2459,ISO 9001:2008 Certified Journal, Volume 3, Issue 3, March 2013)

735

Cost effective WSN Network Monitoring and Control using

Modified SNMP

Rizwan Aslam Butt

1

, Syed M. Usman Ali1

2

, Shahid ur Rehman

3

1,2,3_{Department of Electronic Engineering, NED university of Engineering and Technology Karachi, Pakistan}

Abstract— We have successfully designed an efficient

Simple Network Management Protocol (SNMP) for the monitoring, management and control of low cost Wireless Sensor Network (WSN). SNMP is a very popular protocol for network management in an IP based network. But since its packet fields are very much variable so it requires Type Length Value (TLV) encoding before transmission, which increases its size considerably and makes it quite impossible to use in a WSN network where nodes are mostly resource restricted. Moreover, SNMP is mostly used for retrieving management information from the network but not for initiating actions on network nodes. In this present investigation, we have presented a light weight SNMP protocol without a need of TLV encoding for not only managing the WSN network but also capable of controlling the network nodes. The proposed protocol has been successfully tested in a star configuration based WSN network nodes comprise on cost effective 8 bit microcontrollers and HC-05 Bluetooth modules.

Keywords— Bluetooth network, microcontrollers, Simple

Network Management Protocol (SNMP), WSN Network Management, Wireless Sensor Network.

I. INTRODUCTION

The availability of low cost radio modules like Bluetooth [1], zigbee [2] and wifi for interfacing with general purpose microcontroller modules has led to the evolution of small sensor nodes for acquiring environment / process data and transmitting it to some central server for monitoring or management purpose. Depending upon the need and particular application requirements these nodes numbers may vary up to hundred and even thousands. A typical node consists of programmable controller, on-board memory, typical sensors and a radio link as shown in Fig.1. Such WSN nodes are also termed as motes. Many ready-made motes designed for general purpose sensing are also nowadays available like TelosB, Mica2 and Micaz as described in [3]. There are also some more powerful sensor nodes with high bandwidth employing Bluetooth radio such as iMote [4] and BTnode [5]. Since WSN motes are generally dispersed so they are mostly battery powered and hence has limited energy which imposes restriction on complex processing and data routing techniques.

Moreover since WSN applications require a lot of such nodes so it is desirable to minimize the cost of each node as much as possible [6].

Fig.1: A schematic showing the typical mote architecture

The application areas of wireless sensors are diverse and amazing like smart home, smart care, environmental data collection, forest fire monitoring, land slide detection, machine health and performance monitoring [7] and etc. Network Management is often the essential requirement for monitoring the network faults, sensor data and node status. The WSN network topology has two basic categories [8] as shown in Fig.2.

Fig.2: Schematic showing WSN topologies

(2)

International Journal of Emerging Technology and Advanced Engineering

736 The sink node in simple cases can be a PC or it may be a node itself but would require it to have with more processing power and memory.

Whatever the network topology employed but the network management is an essential requirement for a network. SNMP is the most popular network management in IP based networks. To implement SNMP on a WSN node is not an easy task due to some constraints like limited memory, processing power and power available on WSN nodes. It has been reported in the literature that such technique is applicable as reported by ANMP et al [11], GUERILLA et al [12] and SHAMAN et al [13] but on the cost of more memory and computation so not suitable for most of the WSN designs. Other wireless management techniques that are not using SNMP can be categorized as: i) Middleware category like IMPALA [14] and MATE [15], MARWIS [16]; ii) Specific method category with SNMS [17] or Node energy level manager method [18]. The first category uses the concept of a middleware. Advantage of these approaches is that it is easier to adapt to the local constraints and processing but again the down side is requirement of more memory and processing resources. As for the second category is concerned it was actually designed for specific treatments like node‟s energy. These approaches are also not modular and adaptable to the specific scenarios. So these are not real management tools to answer to the large scale WSN networks. So we can conclude on this by saying that Network Management technique in true sense requires some SNMP like protocol. Since it is quite heavier so some of the researchers have developed their modified versions of SNMP like protocols and given the idea of using a proxy layer like in [17][18].

In this paper, we have proposed a new wireless management technique (WMT) with enhanced features of controlling the network nodes along with network monitoring using a modified version of SNMP. We have tested this protocol in our star based network and evaluated its performance with respect to standard SNMPv2c protocol. All these advantageous features of our proposed network design can be easily applied to other WSN designs.

II. RELATED WORK

The idea of using alternative light weight protocol for SNMP and providing a proxy to translate standard SNMP has been presented earlier by Aur´elien JACQUOT, Jean-Pierre CHANET, Kun Mean HOU, Xunxing DIAO and Jian-Jin LI in [17][18] .

They have given the concept of managing a multi-hop network using SNMP by implementing a translator process in a Gateway node that on one side listens to standard SNMP queries and further retrieves the required information from the network using their customized management process. They have also employed the concept of Master nodes monitoring a set of slave WSN nodes. Each master node has some estimator model to check the received process data, like temperature, humidity and soil moisture, against the predefined thresholds. Moreover the cluster head actually maintains the values for particular processes and replies to management queries from the Gateway. They have also introduced a MIB extension containing typical objects suitable to their environment. For their Gateway they have used ATMEL7S256 processor with 256kb Flash memory and 64k RAM. The wireless radio link used was zigbee 802.15.4.

Another similar work has been presented by Shafique et. Al in 2010 [19] but with different terminologies. For example instead of Master node they have designed a coordinator node which communicates with a group of WSN nodes using zigbee. For IP interfacing with their network they have again defined a gateway node which provides zigbee to IPv6 interfacing as well as SNMP to local management protocol translation. They have also introduced their own MIB extension but the MIB objects are not for general purpose management but are related to configuration and designed for helping in reducing the node‟s power consumption by reducing node‟s reporting time to the Gateway node.

III. OUR NEW PROTOCOL:SNMP-W

The proposed protocol SNMP-W is for WSN networks. Our new protocol is not only lighter than standard SNMP but also more capable. We also have proposed a new MIB tree extension for managing and controlling a WSN node. In the following sections first we describe our MIB extension and then using these MIB objects compare performance of our protocol with standard SNMP.

A. Our Mib Extension

(3)

International Journal of Emerging Technology and Advanced Engineering

737 So we propose the following WSN tree which has ACTION branch for controlling the node‟s 10 digital ports, STATE branch for acquiring the data from node‟s 08 ANALOG ports or DIGITAL ports while the STATUS branch variables can be used for acquiring node‟s available power (avPower), nearby neighbors (nNeighbours), nearest Neighbour address (nNeighbourAddr),address of Gateway node (addrGateway) , location of the node (locNode) and contact information for the node location (nContact).The data types for dPort is byte and for aPort it is integer to accommodate value from a 10/13 bit adc .In the STATUS branch all the MIB variables are byte array except for the avPower , nNeighbours and radioType which are of type byte. For testing purpose we have place our MIB extension beneath the Experimental Group in the standard Management Information Tree (MIT).

Fig.2: Proposed MIB Extension for WSN Node management

B. Object Enquiry with Standard SNMP

Standard SNMPv2c consists of following three main fields namely; (i) Version (ii) Community (iii) PDU. Where PDU consists of further five fields as shown in Table1.

The PDU type is a 1-byte value that identifies which PDU format the SNMP packet is using. The values for the PDU types are as follows:

TABLE-1 SNMPPDUTYPES

GetRequest 0xA0

GetNextRequest 0xA1

GetResponse 0xA2

SetRequest 0xA3

Trap 0xA4

While the Request-ID is a 4-byte integer value that is used to uniquely identify each query sent to a device. The response from the device must contain a matching request-ID. The error status and error index fields are both 1-byte integers. They contain a zero for the GetRequest. The GetResponse packet contains values that indicate whether an error has occurred in the SNMP transaction. The specific values for the kind of error are described in RFC 1213 [21]. A variable binding represents a single object identifier/object, from MIB tree, value pair in the SNMP packet.

But SNMP can‟t be transmitted as it is, as it has some variable fields like community and variable-bindings which would require knowledge of field length for parsing at the receiver end. So a SNMP packet is TLV encoded before transmission.

Fig.2 SNMPv2c packet format

(4)

International Journal of Emerging Technology and Advanced Engineering

738

Fig.3 TLV encoded SNMP GET-REQUEST packet for dPort0 object

This is clearly visible that this packet would require 37 bytes for transmission. Moreover with the available MIB objects and current PDU types, it is very difficult to ask the receiver to initiate an action at the receiver end.

C. Object Enquiry with our Modified SNMP

Since TLV encoding puts a lot of burden on the standard SNMP packet so to avoid it we propose our modified SNMP packet to include length information for variable fields as shown in Fig.4.The start and end fields will have a fixed value to delimit the packet. For testing purpose we have used values of 42 and 40 respectively. The version filed will have value of „1‟. „LC‟ stands for Length of Community and it will have count of the bytes in community field. The PDU TYPE , REQUEST ID , ERROR STATUS , ERROR INDEX all serve the same purpose as in the standard SNMP but we have restricted their size to 1 byte only. LOVB stands for Length of Variable Binding and will have count for the number of bytes in OID. Similarly we have introduced a LV field for indicating the length of the value field in bytes. We have introduced a new PDU type PERFORM-ACTION in addition to GET-REQUEST, GET-RESPONSE and SET-REQUEST PDU‟s to control the digital ports at the WSN node. For testing purpose we have used the values A, B, C and D for GET-REQUEST, GET-RESPONSE, PERFORM-ACTION and SET-REQUEST PDUs respectively.

To show the reduced overhead with our new SNMP packet format we send the same GET-REQUEST query as in section-B for „dPort0‟ object from our manager application to our Bluetooth node. The final transmitted packet with the community = test1 and rest all field filled in is shown in fig5.

Fig.4: Our new modified SNMP packet

It is clearly evident that the same GET-REQUEST PDU now requires 19 bytes instead of 37 bytes. Here we have made one more assumption that WSN node will always respond to its own MIB extension only so instead of sending whole OID we will always start it from 0x06 instead of writing the whole 0x01 0x03 0x06 0x1 0x3 0x1 MIB Ids. If the SNMP query starts from some other value, our receiver simply reply with error of “NOT SUPPORTED OBJECT”. We have successfully tested our new protocol on our WSN network. We have described the details in the next section.

Fig.5 modified SNMP packet filled with values before transmission

IV. EXPERIMENTAL SETUP

Our experimental setup comprises of two WSN nodes programmed with our SNMP agent and a server application developed in Dot Net environment. Our two node hardware comprises of 8051 and PIc16f877 8 bit microcontrollers with HC-05 bluetooth radio links as shown in Fig.6. In the following sections we describe the working of our SNMP Manager and Agent applications.

A. Our SNMP Agent

(5)

International Journal of Emerging Technology and Advanced Engineering

739

Fig.6: Flow chart for the SNMP Agent process in our WSN nodes

B. Our SNMP Manager

We have developed a GUI based SNMP manager application in visual studio 2008.Since HC-05 Bluetooth modules support serial port profile , our manager application scans for nearby modules and retrieves the com port mappings. It then selects a particular module and establishes connection with it using the com port mapping. We have provided the user an interface to inquire status of any analog or digital port or change the state of a digital port. On the background we use our modified SNMP protocol to achieve the monitoring, status enquiry and control tasks.

V. CONCLUSION

We have successfully demonstrated a modified version of SNMP protocol for management, monitoring and control of a single hop WSN Network. Our proposed protocol doesn‟t require TLV encoding for transmission resulting in more than 50% reduction in the packet size. We have successfully checked our protocol on 8-bit microcontroller based WSN nodes with Bluetooth links. It is also very easy to have a gateway node with a proxy process to translate TLV encoded SNMP packets to our modified version for providing IP interface to our WSN network. We are now in the process expanding the range of our network by redesigning it in the multi-hop topology with a gateway providing IP interface to our network and check the performance of our proposed protocol.

REFERENCES

[1] www.bluetooth.com [2] www.zigbee.org

[3] Jason L. Hill, David E. Culler: Mica: A Wireless Platform for Deeply Embedded Networks. IEEE Micro 22(6): 12-24 (2002) [4] J. Beutel, O. Kasten, F. Mattern, K. Römer, F. Siegemund and L.

Thiele: “Prototyping Wireless Sensor Networks with BTnodes”. Proc. 1st European Workshop on Wireless Sensor Networks (EWSN 2004), Springer LNCS, vol. 2920, Berlin, pages 323-338, January 2004.

[5] J. Beutel, M. Dyer, L. Meier, and L. Thiele, "Scalable topology control for deployment-sensor networks," in Proc. 4th Intl Conf. Information Processing in Sensor Networks (IPSN 05), pp. 359-363, IEEE, Piscataway,NJ, Apr. 2005.

[6] Ing.Jakub Saliva, “Technologies used in Wireless Sesnor Networks” , 15th International Conference on Systems, Signals and Image Processing, 25-28 June 2008.

[7] Yen Yang Lim, Marco Messina, Frank Kargl , Leena Ganguli, Martin Fischer, Tommy Tsang, “SNMP-Proxy For Wireless Sensor Network”, IEEE 5th International Conference on Information Technology, 7-9 April 2008.

[8] SOHRABY, Kazem, Daniel, Minoli, Taieb, Znati, “Wireless Sensor Networks: Technology, protocols and Applications “, Wiley, 2006, ISBN 978-0-471-74300-2.

(6)

International Journal of Emerging Technology and Advanced Engineering

740

[9] Kumar, Naveen, “Improved LEACH Protocol for Wireless Sensor Networks “, IEEE 7th International Conference on Wireless Communications, Networking and Mobile Computing (WiCOM), 23-25 Sept. 2011.

[10] Yiming Shen , Wireless sensor network energy-efficient routing techniques based on improved GEAR “, IEEE International Conference on Network Infrastructure and Digital Content, 2009. IC-NIDC 2009.

[11] W. Chen, N. Jain, and S. Singh, “Anmp: Ad hoc network management protocol,” in Selected Areas in Communications, IEEE Journal on, 1999,p. 26.

[12] C. Shen, C. Jaikaeo, C. Srisathapornphat, and H. Huang, “The guerrilla management architecture for ad hoc networks,” in MILCOM 2002, vol. 1, 2002, pp. 467–472.

[13] A. Sethi, D. Zhu, and P. Kalyanasundaram, “Shaman - an environment for distributed management applications,” in Integrated Network Management Proceedings, Seattle, USA, 2001, pp. 321– 324.

[14] T. Liu and M. Martonosi, “Impala: a middleware system for managing autonomic, parallel sensor systems,” in Proceedings of the ninth ACMSIGPLAN symposium on Principles and practice of parallel programming. San Diego, California, USA: ACM, 2003, pp. 107–118.

[15] P. Levis and D. Culler, “Mate: a tiny virtual machine for sensor networks,” in SIGOPS Oper. Syst. Rev., vol. 36, 2002, pp. 85–95. [16] Gerald Wagenknecht, Markus Anwander, Torsten Braun, Thomas

Staub, James Matheka, and Simon Morgenthaler , “MARWIS: A Management Architecture for Heterogeneous Wireless Sensor Networks” ,Springer Lecture Notes in Computer Science ,2008, Volume 5031, pp 177-188

[17] Chanet, Jean-Pierre; Hou, Kun Mean; Diao, Xunxing X.; Li, Jian-Jin J., “A new approach for Wireless Sensor Network management: LiveNCM” , IEEE conference on New Technologies, Mobility and Security, 2008.

[18] A. Boulis and M.B. Srivastava. Node-level energy management for sensor networks in the presence of multiple applications. In IEEE PerCom 2003, pages 41 – 49, Fort Worth, Texas, USA, 2003. [19] Shafique Ahmed Chaudhry, George Boyle, Weiping song, Cormac

Sreenan ,”EMP : A Network Management Protocol for IP based Wireless Sensor Networks” , IEEE International conference on Wireless and Ubiquitous Systems , 8-10 October 2010 , Sousse , Tunisia.

[20] Da-you Liu, Bo Yang, “Smart home research “IEEE International Conference on Machine Learning and Cybernetics, 2004.