Case studies and experiments of SNMP

in wireless networks
J. Kantorovitch, P. Mhnen
Centre for Wireless Communications
University of Oulu
Finland
Today, there is a diversity of wireless equipment based on
different hardware solutions, running various operation
systems and supporting all kinds of existing protocols. Reality
shows that most of the wireless LAN products offer SNMP to
support network management. However managing wireless
LANs is a different and harder task compare to wireline
network management because of the particular nature of the
wireless environment. One of the main problems is the
unpredictable behavior of the wireless channel due to fading,
jamming, and other environment dependent factors. Signal
quality can vary quite dramatically, which might suddenly
reduce the efficiency of the management operation. The
bandwidth of wireless links is another issue that will probably
be always limited due to the properties of the physical medium
and regulatory limits on the use of radio spectrum.

AbstractThis paper studies an issue in the management of

wireless networks. As SNMP is the most widely used network
management protocol, it is natural to adopt SNMP-based
management solutions for WLANs. In this aspect, we investigate
the behavior of Wireless SNMP in different scenarios, specifying
particular wireless channel state conditions (good/bad) and
background traffic load. The performance of an SNMP-based
system is evaluated, using simulations verified by measurements.
What if SNMP would be concurrent? Will it flood a network
with management traffic or would it improve the performance of
Wireless SNMP? The lessons learned from the simulation
performed on serial and concurrent SNMP are also
discussed in this paper.
KeywordsSNMP; WLANs; Opnet

With these aspects, we study SNMP in wireless networks.

We look at the possibility to adapt, extend and carefully
configure an SNMP-based management application to work
optimally in a wireless environment.

I. INTRODUCTION
The Simple Network Management Protocol (SNMP) [1]
provides management capability for TCP/IP-based networks
and currently is the most widely used standardized network
management tool. SNMP agents are available for all kinds of
network devices ranging from computers to bridges, modems,
and printers. SNMP is favored and strongly supported from
the vendor community and is successfully used for the
management of wired networks. SNMP based management
systems have a number of weaknesses and benefits which
have been discussed extensively in the literature [2][3][4]. In
this paper, we are not going to focus on them, rather the goal
of this research is to consider SNMP-based management
solutions keeping in mind the particular features of a wireless
environment.

II. CASE STUDIES AND EXPERIMENTS

This chapter gives an overview of the tests and
experiments performed on Wireless SNMP. The lessons
learned, and some useful examples of SNMP configuration
and usage in a wireless environment are discussed. Our studies
are mainly based on the IEEE.802.11b wireless standard [5].
First, we tested SNMP-based system performance in real
network conditions measuring the response time of the
management application to see if it depends, and how much,
on the wireless link quality and system load. Consequently,
specifying the particular polling interval, we estimate the
maximum number of mobile nodes that a single manager is
able to manage. This knowledge can then be used in the
WLAN network design and planning process. The
measurements are usually dependent on the measurement
platform used. Such factors as hardware characteristics,
software configuration, and even environment properties
influence the performance of the system. Also, the problem
with measurements is the difficulty to obtain the behavior of
the system for high system load. Therefore, to improve the

The number of WLAN networks has been increasing

rapidly especially within companies. WLAN networks are also
provided as services in airports, hotels, and cafeterias. These
networks most probably will also play an important role in
forthcoming "4G" heterogeneous networks. Hence, we believe
that operator and company owned WLAN networks will
become ubiquitous in the near future. This fact will be also
mean that there is a requirement to manage those networks
professionally and because of the sheer size of those networks,
the amount and quality of management traffic is not
insignificant.

This work is funded in part by the Academy of Finland (grant

50624). We also acknowledge partial support through the
TATTI-project.
0-7803-7658-7/02/$17.00 (C) 2002 IEEE

179

The mobile terminals have been set in different

environments with a signal to noise ratio of about 35 dB
("good" link quality) and with a signal to noise ratio of about
5-10 dB ("bad" link quality). The detailed description of the
measurements performed can be found from [8].

reliability and verify our measurement results for high system

load, we also perform the simulation on standard SNMP.

Response time (s)

It is also worth mentioning that so far SNMP performance

has not been evaluated carefully for wireless networks. Most
of the known simulation models [15] assume that links and
nodes have no load and links are error free. But it is known
very well that application response time is a function of the
number of concurrent users contending for the bandwidth. The
number of the users is a very important parameter for the
evaluation of SNMP in the case of wireless shared-bandwidth
networking technologies. In our research we are going further
trying to approach some realistic network conditions. The
performance of the SNMP management application is
investigated under different situations specifying particular
channel state conditions (good/bad) and background traffic
load to obtain application response time and estimate the
number of agents that the single manager is able to manage.

8
6
4
2
0
0,08

0,22

0,37

0,52

System load

0,67

good link quality

bad link quality

Fig.1. Response time as a function of system load

The obtained results for the response time recorded as a

function of the system load (as a fraction of the system
capacity) are presented in Fig. 1. It is clearly seen from the
figure that the response time in notifying the network manager
much depends on wireless link quality. For the same system
load, the response time for bad link quality is about 2-3 times
longer compared with the environment with good channel
conditions. Also as expected, the response time increases in an
exponential way as the load of the system grows. Some
deviations from this can be found in the middle area of the
graph but this could be explained by fluctuations in wireless
channel quality.

The tests reported here are performed in order to acquire

practical knowledge about SNMP. Hence, this paper does not
aim for detailed theoretical analysis, which is postponed to a
later stage of the project. We simply aim to have set of
measurements and simulations to study the reliability and
response time variance of SNMP in a typical WLAN
environment. In the following, section A outlines main
measurement results and in section B, we evaluate the
performance of SNMP using simulation technique. The results
from the simulation are compared with the measurements
performed. The nature of the SNMP manager-agent
communication is discussed in section C. What if the SNMP
manager would work concurrently? If instead of using a
traditional SNMP manager that handles only one managed
agent in time, we use concurrent SNMP that is able to perform
managing asynchronically. Would this configuration flood a
network with the management traffic or would it improve the
response time of the management application? The lessons
learned from this experiment are outlined in this section.

Consequently to estimate the number of agents that a

single manager is able to manage, we considered the particular
scenario where the SNMP manager is polling managing agents
with an interval of 15 min. The results of the calculation [8]
are presented in Fig. 2. According to the measurements, even
with a system load of up to 70 % about 140 devices still can
be managed in an environment with bad channel conditions.
However, as early discussed, this number could be slightly
overestimated and might be corrected by simulation for high
system load.

A. SNMP with measurements

The net-snmp-4.1.2 tool [6] has been selected as a
management solution and IEEE802.11b [5], operated in the
university building that is a typical modern office complex has
been used as a testbed in the measurement setup. The manager
application and SNMP daemons run on the Access Point (AP)
and Mobile Terminals (MT), respectively. We use standard
PC-based platforms for the AP and laptops as MTs running
Linux (kerner version 2.2.14). To trace SNMP at the manager
and agent sides we used tcpdump [12] and tcptrace tools [13].
Tcpdump monitors a hosts interface I/O buffers and generates
a single log file that is used by the tcptrace program to output
a lot of useful information about tcp/udp traffic. MGEN [14],
which is a UDP-based tool, has assisted to simulate the
network traffic. As an example of objects to be inquired, we
chose the SNMP MIB-II [7], which is a standard management
information base for Internet based networks. The data is
about 12 kbytes in size has been retrieved with the SNMP
GetBulk operation.

1250

(N)

1000
750
500
250
0
0,08

0,22

0,37

System Load

0,52

0,67
good link quality
bad link quality

Fig.2. Estimated number of managed devices as a function of system load

B. SNMP with simulation

The OPNET [9] tool is extensively used for simulation.
Wireless LAN IEEE 802.11 standard simulation model
configured with 11 Mbps is used for the medium access
control (MAC) sublayer and three physical (PHY) layers. The

180

Response time, s

wireless network topology is created according to a Basic

Service Set (BSS), which includes AP and mobile stations
communicating with the AP. Mobile terminals, running
SNMP agent software, are set up in various distances from the
Base Station (BS) running SNMP manager software. The
response time from an SNMP agent for a manager request
depends on the distance between the manager and the
particular agent. However, we are interested in measuring the
overall average SNMP application response time, so in the
case of a large number of mobile terminals (some of them near
the BS, some far away), it is reasonable to approximate the
above described topology as a star with equal branches. Also,
it is not necessary to represent every node running an SNMP
application, because an SNMP manger deals with only one
agent in time. The SNMP application response time would be
the response time from the single agent multiplied by the
number of agents belonging to the particular BSS. The final
simulation setup is presented in Fig. 3, where the SNMP agent
is set about 40 m from the SNMP manager.

0,3
0,25
0,2
good
bad

0,15
0,1
0,05
0
0

10

20

30

50

80

System load, %

90

Fig.4. Simulation results for the response time recorded as a function of

system load

The obtained results for the application response time,

recorded as a function of the system load are presented in Fig.
4. The error bars of 0.002s and 0.05s for good and bad
channel states respectively are also shown in the figure.
Simulation results clearly demonstrate the same phenomena as
we found in our measurements. That is the considerable
difference in response time for the environments with good
and bad link conditions and also that the response time of the
management application increases in an exponential way
(especially it is seen now from the simulation) as the system
grows beyond a load of about 50%.
The only difference that we found from the comparison of
the simulation and measurements is the discrepancy in
magnitude of the application response time. Partly, the
particular factors such as properties of the operation system
used, hardware, protocols which can not be absolutely taken
into account in the simulation model can explain this.
Another reason is that OPNET does not support any
mechanisms to model retransmissions on the application level.
The retransmissions are performed only on the MAC layer,
where the maximum number of transmission attempts before a
data frame is discarded is set to seven. Thus a real SNMP
protocol has its own mechanism to control message loss like
the number of retransmissions and retransmission timeout. In
our measurements we found that SNMP actively uses its own
recovery mechanism even for good channel conditions. It is
especially useful, when the channel conditions are becoming
worse (the number of retransmissions was found to be about
35 % of all packets). In fact, the SNMP administrator can
specify the relevant options (e.g. timeout, number of
retransmissions) adapting an SNMP tool with respect to link
quality.

Fig.3. Simulation setup

The Custom Application (CA) model provided by the

Model Library assisted to build an SNMP management
application. In order to specify the relevant attributes, which
are mainly the packet size and number of packets per SNMP
request, the measurements collected for the wireless SNMP
agent performance test has been used.
The solution for implementing the wireless channel, with
the possibility of "good" and "bad" channel states is the
Gilbert model [11], based on a two state Markov chain. The
channel configuration node (see Fig. 3) is aimed at providing
the configuration of the bit error rate (BER Bad/Good state),
transitions probabilities (q, r), and the minimum transition
time (T) from good (about 30 dB) to bad (about 5-10 dB) state
and vice versa. Because the received signal quality is rapidly
varying, it is possible that in the case of a large number of
SNMP agents, some of the manager - agent sessions will fall
into the fading regions, which would considerably extend the
response time compared to a non-fading region of the signal.
So to measure the response time reliably, a single SNMP
agent is polled continuously during three hours each time after
the previous management task has been completed.

In spite of some discrepancy found, both results obtained

from the simulations and the measurements are very valuable
in a practical point of view. The measurement results can be
used as a reference model for low system load and the
simulations allow interpolation [10] of the measurements,
performing careful design of the network for high system load.
C. Concurrent SNMP
Typically an SNMP management station can handle only
one SNMP agent at a time. That means that when the manager
administrated network polls the particular agent it does no
other work until it is done with that agent. The poll may
involve a single get/response transaction or a series of such
transactions. We refer to this as "serial" SNMP. What if
instead of serial behavior, the SNMP manager would work

The system load or the presence of the other network users

is modeled using a "Background utilization" attribute on the
LAN objects. The WLAN is configured with an 11Mbps data
rate and UDP is used as a transport for SNMP messages.

181

such as routing, accounting or access to network configuration

the response time interval might be a critical and demanding
issue.

"concurrently". Fig. 5 illustrates the difference between

serial and concurrent methods. Client and servers
represent SNMP manager and agents, respectively. The word
concurrent also indicates that in this scenario the SNMP
manager is able to inquire its agents in an asynchronous
manner handling several agents at the same time.

application response time, s

task
response
time
task
response
time

Fig.7. Raw data from the simulation of the concurrent (right) and serial
(left) management methods for 10 nodes in the environment with good
channel conditions

Fig.5. The illustration of the concurrent and serial methods

The concurrency sounds attractive, promising faster

response time compared to traditional "serial" SNMP. The
potential advantage of this approach in particular for the
wireless environment is that the order of the responses coming
back to the SNMP manager are regulated by agents and the
environment conditions (e.g. link conditions) rather than by
the SNMP manager itself. Therefore that might reduce the
inter-polling interval time between successful agents
transactions. On the other hand, there is a possibility also of
the network flooding with SNMP traffic.

III. CONCLUSION
The performance of an SNMP based network management
system in a wireless environment is discussed in this paper.
The simulation results are verified and compared with the
measurements performed in real network conditions. It was
found that the response time in notifying the network manager
much depends on wireless link quality. For the same system
load, the response time for bad link quality is about 2-3 times
longer compared with the environment with good channel
conditions. Therefore, it is reasonable to consider channel
conditions in the process of network design and planning. The
system load must be taken into account, as well to consider
network dimensioning.

Response time, s

The results from the simulation for five, ten, and fifty
nodes in "serial" and "concurrent" mode are shown in Fig. 6.
Also, as an a example the raw data for the ten nodes simulated
in an environment with good channel conditions, is presented
in Fig. 7. The task response time is the time required to
complete a quire of the particular agent. The application
response time is time required to go through all agents. The
simulation setup is mainly the same as was described in
section B. The system load is set for all cases to 50% of the
whole capacity of the system.

Also, the issues related with the nature of the SNMP

manager - agent communication are presented in this research.
The "concurrent" SNMP is compared with the "serial" one.
The lessons learned from this experiment are that the response
time for the management application is better for the
"concurrent" mode, but the "serial" method is faster in task
response time. Also, in the "serial" method there is much less
scattering in task response time compare with the "concurrent"
one and that can be important for some real-time non generic
management applications.

5
4
3
2

conc_good
conc_bad

1
0
0

10

Nodes, n

50

serial_good
serial_bad

REFERENCES
[1]

Fig.6. The response time for the concurrent and serial methods as a
function of the number of nodes

Fig. 6 shows that the response time for an SNMP

application which is required to go through all agents for
desired data is better for the "concurrent" mode, than for
"serial". But regarding the task response time, required to get
the desired information from the single SNMP agent, the
"serial" method is faster than concurrent (see Fig. 7). Also
in the serial method there is much less scattering in task
response times compare with the concurrent one. Therefore,
with a serial configuration we can guarantee the particular
response time range, which might be important for some realtime applications. For example, if to use SNMP not just for
generic managing, but rather fit it into other networking tasks

[2]
[3]

[4]
[5]
[6]

182

J. Case, R. Mundy, D. Partain, and B. Stewart, Introduction to version

3 of the internet-standard network management framework, RFC2570,
April 1999.
W.
Stallings,
SNMP,
SNMPv2,
SNMPv3,
and
RMON 1 and 2, Addison Wesley, 1999.
B. Pagurek, Y. Wang, and T. White, Integration of Mobile Agents with
SNMP: Why and How, IEEE/IFI Network Operations and
Management Symposium, 2000.
R. Sprenkels, and J. P. Martin-Flatin, Bulk transfers of MIB data, The
Simple Times, 7(1):1-7, 1999.
IEEE standard for wireless LAN medium access control (MAC) and
physical layer (PHY) specifications, P802.11, November 1997.
Net-snmp management tool, http://net- snmp.sourceforge.net.

[7]

[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]

K. McCloghrie, and M. Rose, Management information base for

network management of TCP/IP-based internets: MIB-II, RFC 1213,
March 1991.
J. Kantorovitch, Z. Shelby, T. Saarinen, and P. Mhnen, Wireless
SNMP, INET conference, June 2000.
Opnet simulation tool, http://www.opnet.com.
J. Kantorovitch, and P. Mhnen, Evaluation of wireless network
management, accepted to China Wireless Congress, October 2002.
S. M. Ross, Stochastic processes, John Wisley and Sons, 1996.
Tcpdump tool, ftp://ftp.ee.lbl.gov.
Tcptrace tool, http://www.tcptrace.org/new.html.
Mgen tool, http://manimac.itd.nrlnavy.mil/MGEN.
M. Rubinstein, and O. Duarte, Evaluating tradeoff of mobile agents in
network management, Networking and Information Systems, vol. 99,
pp. 1-16, 1999.

183