1830

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 5, MAY 2011

Management and Plug and Play of Sensor Networks Using SNMP

Syed Alamdar Hussain, Student Member, IEEE, and Deniz Gurkan, Member, IEEE
AbstractRecently, the network management of sensor nodes has gained interest as more sensors are being networked with Internet technologies as opposed to traditional instrumentation and measurement networks. Sensor networking standardization efforts lead a more interoperable way of identication and communication among sensors, and networking technologies provide multiple-access mechanisms to a high number of sensors. The convergence of sensor networking toward internetworking provides exibility in protocol development for network management. This paper presents a novel demonstration of such a convergence by utilizing a common network management protocol, i.e., Simple Network Management Protocol (SNMP), and a sensor networking standardization effort, i.e., Transducer Electronic Data Sheet (TEDS). The TEDS information for two types of sensors has been transferred to the SNMP domain through a novel management information base design, and the network management system has been implemented on an actual testbed. Index TermsIEEE standards, intelligent actuators, intelligent networks, intelligent sensors, management information systems, transducers.

I. M ANAGEMENT OF S ENSOR N ETWORKS MANAGEMENT system developed for sensor networks must be capable of integrating operation, conguration, administration, security, and maintenance of all sensor nodes present in the network. The system consists of a manager, a managed system, a database of management information, and the network protocol, as shown in Fig. 1. The Simple Network Management Protocol (SNMP) is the most widely accepted application layer protocol for the remote management of networks and devices. The reason for its popularity is its simplicity in implementation. The network management industry and the SNMP protocol, in particular, have matured since their commencement. The SNMP architecture helps achieve the following goals [1]: 1) minimizing the number and the complexity of the management functions; 2) providing exibility in expansion for operation and management;

3) isolating the architecture from the mechanism of particular hosts and gateways. The SNMP provides a way to discover various SNMPmanaged nodes in the network using the SNMP ping. The manager systems can discover and map the SNMP-managed nodes in the network, making the administration and the maintenance of nodes in the network possible [2]. The managing system can retrieve the information through the Get, GetNext, and GetBulk protocol operations. It can also change the conguration of control variables through the Set protocol operation to actively manage a system, hence providing measurement capabilities, data collection, and conguration of network elements. The SNMP agent also has the capability of reporting asynchronous messages to manager systems using Trap or Inform [3], notifying the manager about alerts or special events that are to be monitored [4]. An important requirement for the SNMP was to minimize managed-element processing overhead. The SNMP was therefore designed to collect and report information but not to provide sophisticated information processing. The network overhead of using User Datagram Protocol (UDP)/Internet Protocol (IP) is relatively small. A UDP/IP header requires 28 octets (assuming no IP options). Since the UDP is connectionless, it will generate no overhead trafc of its own (such as Transmission Control Protocol states such as SYN synchronize, FINnish, and ACKacknowledgment) [5]. A reduced processing overhead and a common platform enables growth and platform independence. This allows the SNMP to be used on almost every IP network, often using a single centralized Network Management System (NMS). The more powerful and secure Common Management Information Protocol (CMIP), developed in the mid-1990s, was expected to replace the SNMP. However, the fact that the CMIP uses ten times the network overhead has meant that the SNMP is still the major player in the industry. One thing that sets the SNMP apart from so many other standards is that it is widely available and interoperable among a variety of network components. A. SNMP: Management Information Base

Manuscript received June 25, 2010; revised January 10, 2011; accepted January 11, 2011. Date of current version April 6, 2011. This work was supported by the Mobitrum Corporation. The Associate Editor coordinating the review process for this paper was Dr. Domenico Grimaldi. The authors are with the Department of Engineering Technology, University of Houston, Houston, TX 77004 USA (e-mail: dgurkan@central.uh.edu). Color versions of one or more of the gures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identier 10.1109/TIM.2011.2113115

The SNMP is dened in terms of management information variables, generally called objects. Each object describes a particular characteristic of a device. A collection of objects used in SNMP is called a management information base (MIB) [6], a conceptual framework that encapsulates a certain view of the network entities being useful for the management purposes and the relationship between these entities. In order to manage

0018-9456/$26.00 2011 IEEE

HUSSAIN AND GURKAN: MANAGEMENT AND PLUG AND PLAY OF SENSOR NETWORKS USING SNMP

1831

Fig. 1.

NMS: from an SNMP perspective.

heterogeneous systems, each management system needs to implement the MIB dened in open systems interconnection (OSI) [7]. Dening objects using modules allows for signicant exibility in dening the variables that allow the management of different types of devices. The use of MIB objects solves the problem of the network management protocol being tied to the network management information. Each device may represent information in a different way; for all of them to communicate with each other, the management information should be represented in a consistent manner. The part of the SNMP framework that ensures the universality of MIB objects is the Structure of Management Information (SMI) standard. The SMI denes the rules for how MIB objects and modules are constructed. In the SMI, MIB objects are described using a precise set of denitions based on a data description language called the ISO Abstract Syntax Notation 1 standard [8]. They use a hierarchical namespace containing object identiers (OID). The complete path from top of the tree down to the point of interest forms the OID. Each OID is unique and identies a variable that can be read or set via the SNMP. The MIB is used by both the agent and management processes to store and exchange management information [7], [9]. B. IEEE 1451 In order for sensors to successfully integrate, they must have networking capabilities that provide information ow and control. Currently, there is no dened common digital interface standard between transducers and how they should provide the information ow. However, there is a strong push in the industry to harmonize the standards that enable networking and data acquisition of sensors. One such effort is the creation of the IEEE 1451 standard for smart-sensor networks to combine data acquisition control systems with networking [10]. IEEE 1451 changes the sensor measurement paradigm by creating a measurement data model that realizes that a measurement is more than a value and thus establishes a unique method for setting up sensor measurements, providing time and location stamping of measured data. IEEE 1451.1 denes a network-independent information model enabling transducers to interface to network-capable application processors. It provides a denition for a transducer and its components using an object-oriented model, which consists of a set of object classes with specied attributes, actions, and behaviors chosen to provide a clear comprehensive description of a transducer [11].

The IEEE Std. 1451.42004 is a part of a family of smart transducer interface standards designed for connecting transducers to existing instrumentation and control networks, dening a mechanism for adding self-describing capabilities to the transducer. The key feature is the Transducer Electronic Data Sheet (TEDS) that automates the process of inputting sensorrelated information [12]. The ability for the sensors or the actuators to have transducer data sheets will allow the plug and play of the IEEE 1451-compatible sensors and actuators for different control networks and hot swap (startup) connections of nodes in the network. The IEEE 1451.4 standard clearly denes a class of IEEE templates, categorizing the common types of sensors and actuators. For each template, there is also a set of properties covering all types of functions, such as measurements, electrical signal output, power supply, transfer function, and calibration information [12]. These qualities allow the standard to be easily ported into the MIB structure of the SNMP. In other words, each of these properties dened could be directly used to form MIB objects for the proposed design. Due to the wide industrial acceptance of the IEEE 1451.4 TEDS, this proposed MIB design is based on the IEEE 1451.4 instead of other forms of the TEDS dened in the IEEE 1451.2, 1451.0, 1451.3, etc. Companies such as the Honeywell Sensotec and the National Instruments have been implementing the IEEE 1451.4 TEDS to dene their sensors and actuators. II. N ETWORK M ANAGEMENT A PPROACH We report the design and the implementation of a novel MIB structure, which can be used to represent the IEEE 1451.4 TEDS. Dening a standard MIB for obtaining information related to physical sensors will simplify the process of identifying them, and their management becomes independent of the manufacturing vendors. A. Previous Work Previously, there has been attempts to deploy methodologies that utilize lightweight SNMP-based MIBs for the management of sensor networks, considerably reducing overhead in the network. LiveNode Non-invasive Context-aware and modular Management (LiveNCM) was developed to meet management and saving energy demands for energy-efcient sensor networks. LiveNCM introduced two new concepts. First, it implemented a noninvasive context-aware diagnosis for the data

1832

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 5, MAY 2011

management, reducing the volume of information exchanged by deducing the node state from a single message. The second concept introduced an estimator model to compute some values that can be predicted. Thus, a node sends data only when necessary. The MIB structure used by LiveNCM had distinguished seven groups: description, system, energy, transmission, measurement, local interfaces, and time [13]. A smart transducer MIB containing the IEEE 1451.2 TEDS information was designed for the creation of a SNMP-based smart transducer interface module (STIM). This MIB contains the meta, meta identication, channel, channel identication, calibration, and calibration identication of TEDS information; extension abilities for manufacturers; and control and status information of the standard IEEE 1451.2-based STIM. The attachment of such a MIB to an SNMP agent resulted in a network-reachable transducer-independent interface, formalizing the control of different networked devices resulting in the fast and simple development of smart transducer networks [14]. The Entity MIB introduced in 1996 dened the need for a standardized way of representing a single agent, which supports multiple instances of one MIB. The Entity MIB denes a textual convention PhysicalClass, which is an enumerated value providing an indication of the general hardware type of a particular physical entity. Chassis, backplane, container, power supply, fan, sensor, module, and port were the physical entities recognized as a part of the Entity MIB. Thus, physical sensors are represented in the Entity MIB with entPhysicalEntry and an entPhysicalClass value of sensor 8 [15]. With the wide increase in the deployment of sensors in various applications, the need for providing more access to information pertaining to sensors has risen. As a result, the Entity Sensor MIB was dened as an extension to the Entity MIB for describing managed objects for sensors alone. The MIB objects dened in the Entity Sensor MIB provide a sparse augmentation to the entPhysicalTable in the Entity MIB for entries in which the associated entPhysicalClass object is equal to sensor 8. An agent is expected to maintain an entPhySensorEntry with the same entPhysicalIndex value for each entPhysicalEntry representing a physical sensor [16]. Therefore, the implementation of the entityPhysicalGroup is required for agents that implement the Entity Sensor MIB. The Entity Sensor MIB contains a single group called the entitySensorValue group, which denes objects to convey the current value and status of a physical sensor. This group contains a single table called the entSensorTable, which provides a small number of READ-only objects [17].

adding a self-describing behavior to sensors with an analog signal interface. The heart of the IEEE 1451.4 standard is the denition of the TEDS, i.e., an information structure that contains the critical sensor information to enable the plug-and-play operation. The TEDS information is divided into several key sections. The rst portion of the TEDS, i.e., the basic TEDS, contains the required sensor identication information, including the manufacturer, the model number, and the serial number of the sensor [12]. The basic TEDS may be followed by a standard TEDS that contain the specic data sheet information for the sensors. The Entity Sensor MIB can be extended to accommodate the TEDS information. We have introduced a new object called the template ID to the entSensorTable mentioned in the previous work section. As the template ID uniquely identies each template dened in the IEEE 1451.4 standard, this object acts as the index to the table apart from the entPhysicalIndex (see Fig. 2). Having introduced the template ID, the next step was to bring in the basic TEDS. The just-dened template ID can be further extended to two tables. The basic TEDS can be grouped together in a systemInfoTable, and as there can be multiple sensors/transducers belonging to the same template type, to differentiate them, we have dened a columnar object in the tables as the sensorID, which will uniquely identify the transducers [18]. The standard, extended, and user-areadened TEDS vary according to the transducer type, and hence, they can be grouped together in a separate table for each template ID. In other words, we can have a template 25 TEDS table for template ID = 25 and a template 36 TEDS table for a template ID = 36. Both the tables will have a sparse augmentation to the entSensorTable in the Entity Sensor MIB for entries in which the associated template ID object. An agent is expected to maintain a systemInfoEntry with the same template ID value for each entSensorValue representing a transducer [18]. C. Design Considerations The primary goal in sensor networks is minimizing the energy usage and conserving as much as possible by reducing the amount of communication between nodes. The processor residing in the nodes has signicant speed and memory constraints. There have been many considerations taken into account while designing the MIB for keeping the communication overhead as minimum as possible. The use of long OID resulting from unnecessary hierarchies have been avoided [13]. The use of complex indexing schemes was avoided, resulting in keeping the overhead from instance identiers as low as possible. The SNMPv3 provides two types of security models, i.e., the userbased security model (USM) and the transport security model (TSM) [3]. The use of the TSM also minimizes overhead; the USM security parameters are passed within each SNMP message, whereas the TSM enables operators to leverage the existing security infrastructure. The GetModify SNMP message fetches only the modied tabular variables instead of the entire table and thus minimizes the data trafc transmitted between the manager and agent when compared with other Get methods (Get/GetNext/GetBulk) [19]. It reduces the overhead

B. Proposed Design Private enterprises such as Cisco, HP, Cabletron, 3Comm, and Avaya, which manufacture networking devices such as switches, routers, hubs, and servers, are SNMP compatible with their own private MIB. Our proposed design makes the sensor SNMP compatible. The IEEE 1451.4 standard reduces the time and the challenges associated with sensor conguration. The standard establishes a universally accepted method of giving sensors the plug-and-play capability dening a mechanism for

HUSSAIN AND GURKAN: MANAGEMENT AND PLUG AND PLAY OF SENSOR NETWORKS USING SNMP

1833

Fig. 2.

MIB design: extending the Entity Sensor MIB.

Fig. 3.

MIB implementation: for a sensor node.

needed to update the MIB of the manager and minimizes the latency. III. I MPLEMENTATION The MIB addresses the specications of managed objects, dening the relationship between the managed objects and groups of related objects into MIB modules. The MIB is a virtual database, and to effectively manage a particular agent, as many objects that can be implemented by the agent must be dened in the MIB. The MIB is compiled in the manager during the implementation. However, a MIB needs to be implemented

in both the manager and the agent to acquire information [20]. Dening a MIB for a network device will provide the administrator with the ability to congure it, monitor fault occurrence, and measure performance and security, contributing toward better management of the network device. The rst step in the implementation was the creation of the MIB to accommodate the IEEE 1451.4 TEDS. The IEEE 1451.4 provides standard templates for about 25 different kinds of sensors. To demonstrate the implementation, we have taken into consideration two templates types, i.e., an accelerometer/force transducer (template ID = 25) and a thermocouple (template ID = 36) (see Fig. 3). The MIB editor is one of the

1834

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 5, MAY 2011

Fig. 4. MIB creation: dening a tabular column using the MIB editor.

Fig. 5. Reporting of the TEDS.

utilities provided by the WebNMS SNMP C agent development toolkit, which allows you to design and create your own MIB using a graphical environment, giving you options to add scalars, tables, imports, and various constructs conforming to SMI standards to make it a complete MIB [21], [22]. Upon creation, the tool generates the SMI code for the MIB as the output (see Fig. 4). Once the MIB is ready, the next step would be to compile it. We used the MIB compiler utility distributed with the WebNMS SNMP C agent development toolkit. It develops custom SNMP agents taking MIB les as input [21]. We provided the MIB le

that we created in our rst step of the implementation, and it generates a generic code that can be modied according to the user requirements. After modifying the code, we compiled it to get the SNMP agent executable. We deployed a sensor network consisting of three nodes congured to connect to a local area network via their Ethernet ports with static IP addresses. Among the three nodes, two nodes are acting as the transducer interface module (TIM) and have sensors plugged into them, reporting the TEDS information. The third node is loaded with the SNMP agent executable obtained from the MIB compiler and is hence acting as the

HUSSAIN AND GURKAN: MANAGEMENT AND PLUG AND PLAY OF SENSOR NETWORKS USING SNMP

1835

Fig. 6.

Querying the agent: requesting for a variable.

smart-sensor node providing processing capabilities. Of the two nodes reporting TEDS, we have one node plugged with accelerometer/force transducers and the other plugged with thermocouple sensors. The plug-and-play feature is achieved by making the transducer describe itself to the data acquisitions system (smartsensor node) by sending its TEDS information as soon as it is plugged in. The TEDS is stored in the Flash memory of nodes acting as the TIM (see Fig. 5). When we plug a sensor corresponding to the TEDS le into one of the nodes input channels, the node reports its TEDS to the smart-sensor node on behalf of the sensor, thus achieving plug and play. The .ted le received is in binary form and needs to be converted to text form to display the information in readable form to the manager of the network. We have written a code that converts these binary-form TEDSs to text/decimal form and writes them to a text le. The code resides in the smart-sensor node. The SNMP manager manages the sensor network. We make use of the MIB browser, i.e., a utility provided by the WebNMS SNMP C agent development toolkit. It takes in the MIB le as input and can query an SNMP agent of all the variables in the MIB. The tool also has a trap collector in order to receive traps or notication messages from the agents. We load the MIB that we have created using the MIB editor and provide the IP address of the smart-sensor node acting as the agent to the MIB browser for it to query the agent for the value of the managed variables. When we select a certain variable whose value we are interested in, the MIB browser sends a GetRequest SNMP message to the agent (see Fig. 6). The agent fetches the value of the requested variable that is stored in the converted text les and reports it back to the MIB browser, which displays the information for the user on its graphical environment. We have designed the MIB to contain

notications and traps. When a new sensor is plugged into one of the two TIM nodes or, in other words, when the smart-sensor node (agent) receives a new TEDS, it sends a trap/notication to the MIB browser indicating the same. We have utilized the same concept to also reect the removal of a sensor or a node leaving the network. The MIB contains a variable that indicates the status of the node, i.e., present or absent on the network. We congured the MIB browser to have a polling interval of 20 s to get the updated values for each poll. The polling interval can be chosen according to the expected rate of change in conguration, faults, or security expectations, and the performance of the particular sensor network. For example, a change that might be expected every 3 ms will dictate the polling of those particular parameters at every 3 ms (see Fig. 7). IV. C ONCLUSION Currently, it would not be possible for sensor nodes from different vendors on the network to communicate with each other if they are not interoperable. To be interoperable, the application layer protocol should be standardized. Such a standard should be independent of the underlying layers and the data link layer communication protocols as it has been conceptually proposed in the IEEE 1451. Apart from standardizing the application layer protocol, there is also a need for standardizing the information structure pertaining to the sensors and the transducers for better management. Hence, we have put forward the idea of combining the IEEE 1451.4 standard and the SNMP protocol to achieve the management and interoperability goals. Dening a MIB structure to represent the TEDS information will standardize the data representation, and the use of the SNMP will standardize the communication for interoperability among sensor nodes. Using SNMP MIBs has other benets, i.e., each individual variable of the MIB is accessible, and it

1836

IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 60, NO. 5, MAY 2011

Fig. 7. Displaying the value of the requested variable.

is possible to dene each TEDS variable as READ only or READ WRITE wherein prior to only the whole TEDS could be modied.

R EFERENCES
[1] M. A. Miller, Managing Internetworks with SNMP, 3rd ed. Hoboken, NJ: Wiley, 1999. [2] J. D.Case, M. S. Fedor, M. L. Schoffstall, and J. R. Davin, A Simple Network Management Protocol, (SNMP), DDN Network Information Center, SRI Int., May 1990, RFC 11 57. [3] J. Case, R. Mundy, D. Partain, and B. Stewart, Introduction to Version 3 of the Internet-Standard Network Management Framework, Apr. 1999, RFC 2570. [4] J. Case, K. McCloghire, M. Rose, and S. Waldbusser, Introduction to Version 2 of the Internet-Standard Network Management Framework, Apr. 1993. [5] F. Kastenholz, SNMP Communications Services, Oct. 1991, RFC 1270. [6] M. Rose and K. McCloghire, Structure and Identication of Management Information for TCP/IP-Based Internets, May 1990, RFC 1155. [7] K. McCloghire and M. Rose, Management Information Base for Network Management of TCP/IP-Based Internets: MIB-II, Mar. 1991, RFC 1213. [8] Int. Org. Standardization, Information Processing SystemsOpen Systems InterconnectionSpecication of Abstract Syntax Notation One (ASN.1), Int. Std. 8824, Dec. 1987. [9] M. Rose and K. McCloghire, Concise MIB Denitions, Mar. 1991, RFC 1212. [10] S. Gumudavelli, D. Gurkan, and R. Wang, Emulated network of IEEE 1451 application with multiple smart sensor reports, in Proc. IEEE Sensor Appl. Symp., New Orleans, LA, 2009, pp. 304308. [11] IEEE, IEEE Standard for a Smart Transducer Interface for Sensors and ActuatorsNetwork Capable Application Processor (NCAP) Information Model, IEEE Std. 1451.1, 1999. [12] IEEE, IEEE Standard for A Smart Transducer Interface for Sensors and ActuatorsMixed-Mode Communication Protocols and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Std. 1451.4, 2004. [13] A. Jacquot, J.-P. Chanet, K. M. Hou, X. Diao, and J.-J. Li, A new approach for wireless sensor network management: LiveNCM, in Proc. NTMS, Nov. 2008, pp. 16. [14] B. Scherer, C. Toth, T. Kovacshazy, and B. Vargha, SNMP-based approach to scalable smart transducer networks, in Proc. 20th IEEE IMTC, May 2003, pp. 721725. [15] K. McCloghrie and A. Bierman, Entity Management Information Base, Oct. 1996, RFC 2037.

V. F UTURE W ORK We expect the wide acceptance of the sensor networking MIBs because of the ease of using the SNMP in the near future. The IEEE 1451.0 standard denes an application program interface for applications that provide communications between the users network and the IEEE 1451.0 layer, introducing a new TEDS structure consisting of the same TEDS components (meta, transducer, calibration, etc.) describing the entire TIM, including the transducer, the signal conditioner, and the data converters [23]. Consequently, the IEEE 1451.0 TEDS can be included into the proposed MIB structure. In the future, security aspects of the SNMP can be integrated with the sensor network management. The above-discussed MIB design will be proposed as a new Internet engineering task force Internet draft to the corresponding workgroup. MIB proposals in Internet technologies will help increase the manageability of the network components.

ACKNOWLEDGMENT The authors would like to thank R. Wang and S. Gumudavelli for their valuable suggestions and discussions during this project.

HUSSAIN AND GURKAN: MANAGEMENT AND PLUG AND PLAY OF SENSOR NETWORKS USING SNMP

1837

[16] Entity-Sensor-MIB Tree, Jan. 25, 2011. [Online]. Available: http://www.mibdepot.com [17] A. Bierman, D. Romascanu, and K. C. Norseth, Entity Sensor Management Information Base, Dec. 2002, RFC 343. [18] S. A. Hussain, D. Gurkan, and S. Gumudavelli, Design of a management information base (MIB) for a smart sensor network, in Proc. Int. Instrum. Meas. Technol. Conf., May 2010, pp. 11261130. [19] S.-H. Park and M.-S. Park, An efcient transmission for large MIB tables in polling-based SNMP, in Proc. ICT, Mar. 2003, pp. 246252. [20] M. Subramanian, Network Management: Principles and Practice, 2nd ed. Reading, MA: Addison-Wesley. [21] WebNMS SNMP Agent Toolkit C Edition 6.4.02011, Jan. 25. [Online]. Available: http://www.webnms.com/cagent/index.html [22] R. E. Busby, Jr., M. L. Neilsen, and D. Andresen, Enhancing NWS for use in an SNMP managed Internetwork, in Proc. 14th IPDPS, May 2000, pp. 506511. [23] IEEE, IEEE Standard for A Smart Transducer Interface for Sensors and ActuatorsCommon Functions, Communication Protocols, and Transducer Electronic Data Sheet (TEDS) Formats, IEEE Std. 1451.0, Sep. 2007.

Deniz Gurkan (M92) received the B.S. and M.S. degrees in electrical engineering from Bilkent University, Ankara, Turkey, in 1996 and 1998, respectively, and the Ph.D. degree in electrical engineering from the University of Southern California, Los Angeles, in 2003. Since 2004, she has been a Member of the Faculty with the Department of Engineering Technology, University of Houston, Houston, TX. She has over 50 peer-reviewed articles in her eld. Her research interests are in measurement and instrumentation networks, sensor networks and standardization, and optical networking. Prof. Gurkan has been the Associate Editor for the IEEE TRANSACTIONS ON INSTRUMENTATION and MEASUREMENT since 2010. She has been a member of the Technical Committee for the IEEE Sensor Applications Symposium since 2008.

Syed Alamdar Hussain (S10) received the B.E. degree in information technology from Osmania University, Hyderabad, India, in 2007 and the M.S. degree in engineering technology with the University of Houston, TX. He completed his thesis research work in the MS program under a grant funded by Mobitrum Corp. His research interests include network communications and their management, sensor networks, and embedded systems.