Int. J. High Performance Computing and Networking, Vol. X, No.

Y, 200x 1

A proposal for an algorithm to count nodes using

wireless technologies

Eric Gamess*
Laboratory of Communications and Networks,
Central University of Venezuela,
Los Chaguaramos, Caracas 1040, Venezuela
Email: eric.gamess@ciens.ucv.ve
*Corresponding author

Manuel Contreras
School of Computer Science,
Central University of Venezuela,
Los Chaguaramos, Caracas 1040, Venezuela
Email: mcontre@ula.ve

Abstract: Algorithms to count objects (people, animals, devices, vehicles, etc.) have interested
the research community for a long time since they can be used as base tools in the development
of many applications. Up to now, most of the work done in this area is supported by turnstiles,
digital cameras, video cameras, pneumatic road tubes, magnetic sensors, infrared beams, or other
types of sensors. However, very few works have been developed using wireless communications
to count nodes. In this paper, we introduce a new algorithm for counting nodes equipped of a
wireless interface. To validate our proposal, we simulate the algorithm using OMNeT++/INET, a
famous network simulation tool. Our simulations show that the proposed algorithm computes a
number of nodes close to the real one, with a small number of messages and a short response
time.

Keywords: wireless networks; counting nodes; OMNeT++; INET; network simulator; algorithm.

Reference to this paper should be made as follows: Gamess, E. and Contreras, M. (xxxx)
‘A proposal for an algorithm to count nodes using wireless technologies’, Int. J. High
Performance Computing and Networking, Vol. X, No. Y, pp.xxx–xxx.

Biographical notes: Eric Gamess is currently an Associate Professor at the School of Computer
Science at Central University of Venezuela. He received his PhD in Computer Science at Central
University of Venezuela in 2000. His research interests include computer networks, high
performance computing, and computer science education.

Manuel Contreras received his Master in Computer Science from University of Los Andes, in
Venezuela. He is currently an Associate Professor at University of Los Andes, and is a PhD
candidate at Central University of Venezuela. His research interests include computer networks
and computer science education.

1 Introduction whether or not the cell must be divided. Nowadays, we

attempt to solve all these tasks using human operators or
Counting objects such as people, animals, devices, vehicles,
automatic systems, mainly based on turnstiles, digital
etc., has been of great interest in various fields. For
cameras, video cameras, pneumatic road tubes, magnetic
example, people can be counted in political, sporting,
sensors, infrared beams, etc.
musical, or social events for many reasons that include
The most traditional method to estimate the
statistics, capacity, billing, flow optimisation, safety, etc. In
number of objects is the manual counting. In this case
a parking lot, having the number of vehicles already parked
trained observers gather necessary data that cannot
can be useful to infer the number of free parking slots. For
be efficiently obtained through automated counts
protection and preservation of our fauna, it is important to
(Leduc, 2008). For example, a person can count about
get an estimation of the population of animal species that
1,000 to 2,000 pedestrians in an hour (Schweizer, 2005).
are in danger of becoming extinct. For a telecommunication
With a counter (a small equipment that counts pulses such
company, information about the number of customers that
as a hand tally counter), this person can double the amount
use cell phones in a particular cell is helpful to decide
of counted pedestrians. Bicycles and cars are other objects

Copyright © 20XX Inderscience Enterprises Ltd.

2 E. Gamess and M. Contreras
that can be counted by a trained observer. However, this
method has several drawbacks as the need to hire staff to
perform such work and the possibility of making significant
errors in situations with a high density of objects.
Another way to estimate the number of objects is by
using mechanical devices. The most representative
are the turnstiles that are used for counting people in an
access control system. Turnstiles present a high degree of
reliability, a high cost, and a low degree of automation for
information processing. They eliminate the cost of staff but
significantly reduce the spaces dedicated to the entrance/exit
of people, resulting in many cases in delays and
incommodities in the transit of people.
In the case of infrared technology, many applications
use a simple beam which is normally connected to a LCD
display on the side of the door of transport units (e.g., in
trains, buses, ferries). When a passenger enters the transport
unit, he cuts the light beam which is detected by a
microcontroller that reacts by incrementing a counter.
Magnetic sensors (Leduc, 2008) are used in the
transportation system. They can be fixed under or on top of
the roadbed. When a vehicle passes over the sensor, the
magnetic field of the engine modifies the one of the sensor.
This technology allows vehicle counting, vehicle
classification, and speed calculation. However, when the
density is high, these sensors have difficulties to
differentiate between closely spaced vehicles.
Communication has gained importance in the last two
decades. Nowadays, it is common that objects (people,
animals, devices, vehicles, etc.) are equipped of a wireless
interface for communication purposes. Algorithms can take
advantage of this technology to count objects. In this paper,
we propose an algorithm to count nodes using wireless
technologies. It differs from previous work for the
technology used (wireless technology), which is a strength
since wireless communication is gained acceptance and is
being implanted almost everywhere. The simulations that
we performed show that our algorithm efficiently computes
a number of nodes very close to the real one, for stationary
nodes. In addition, as revealed by the simulations, our
algorithm is also doing well for mobile nodes with moderate
speeds.
The rest of this paper is organised as follows.
In Section 2, we review the related work. In Section 3, we
introduce our algorithm to count nodes using wireless
technologies. Section 4 briefly introduces the simulation
tools that we use to validate our algorithm and provides
information of our simulation scenarios. Section 5 presents
an analysis of the results of our simulations. Finally,
Section 6 concludes the paper.
2 Related work
Detecting and counting objects has many applications, and
because of its usefulness has been done in various ways or
disciplines with several technologies that makes it
applicable to diverse situations. At the present time,
most of the proposals to count nodes are based on
methods and techniques that use conventional ‘in-situ’
technologies (turnstiles, digital cameras, video cameras,
sensors, etc.).
In the literature, there are many works that use images
or recordings of digital or video cameras. For example,
Bescos et al. (2003), Kettnaker and Zabih (1999) and
Khoudour et al. (1996) use them to count people in
surveillance systems and to count passengers in public
transport. Similarly, in the field of vehicular transportation,
Wu and Gu (2009) presented a new algorithm that takes
advantage of digital image processing and camera optics to
automatically estimate vehicle speed and vehicle count in
real-time. Daigavane and Bajaj (2010) introduced a
background subtraction and image segmentation using
morphological transformation to efficiently detect and count
dynamic objects on highways. Pornpanomchai et al. (2008)
proposed a system consisting of a PC connected to a video
camera to detect and count vehicles.
Sensor networks are also the basis of some works. For
example, Litzenberger et al. (2007) presented an embedded
system comprising a motion-sensitive optical sensor and
low-cost DSP to detect and count vehicles. Bu and Chan
(2005) use several laser sensors to detect and count people
in a bus station. Chen et al. (2008) proposed a cluster of
ultrasonic sensors that can successfully offset interference
problems and accurately detect the direction of moving
objects and distinguish closely tied objects for counting.
Unlike the work done with conventional ‘in-situ’
technologies which is abundant, there are just a few
proposals developed on top of wireless networks. Evers et
al. (2011) worked with wireless ad-hoc networks consisting
of small microprocessors with limited memory, where the
wireless communication between the microprocessors can
be highly unreliable. For this setting, they proposed a
number of algorithms to estimate the number of nodes in the
network, and the number of direct neighbours of each node.
Schwerdel et al. (2011) proposed a distributed algorithm to
estimate node counts in self-organising ring topologies.
They provided a lightweight, distributed algorithm to
estimate the size of the node population. Gamess and
Mahgoub (2011), using wireless technologies, presented a
novel VANET-based approach to obtain the position of the
last vehicle and the number of vehicles, in a line of vehicles
stopped at a traffic light. To compute the number of nodes,
they first obtain the length of the queue of vehicles stopped
at the traffic light and then divide this distance by a constant
value (seven metres).
In broad terms, most of the work done in this field is
based on ‘in-situ’ technologies. The other proposals
(Evers et al., 2011; Schwerdel et al., 2011; Gamess and
Mahgoub, 2011) referenced in this section, that use wireless
technologies, are limited to static nodes or nodes organised
in a specific topology.
 A proposal for an algorithm to count nodes using wireless technologies 3

3 Proposal of an algorithm to count nodes using
wireless technologies
In this section, we describe the proposal of our algorithm to
count nodes or devices equipped of a wireless network
interface, using wireless technologies.
3.1 Basic considerations for counting nodes
The basic approach of the algorithm to count nodes around
a determined position (the originator) is:
1 Propagate a broadcast message (called
COUNT_REQUEST) from the originator to nodes that
are far away from the originator with the number of
HopAway the receiver of the message is from the
originator of the COUNT_REQUEST.
2 Propagate unicast messages (called COUNT_REPLY)
from the nodes that are far away from the originator
toward the originator with the total number of nodes
counted up to now (called Total in the algorithm).
Figure 1 depicts a timing diagram related to the propagation
of the broadcast messages (COUNT_REQUEST) and the
unicast messages (COUNT_REPLY) for each node, where:
finally send a COUNT_REPLY message at time t5. It is
required that the node transmits the COUNT_REQUEST
message three times, since it is a broadcast message that can
collide with other messages without this being detected.
The timers in the diagram are defined in our algorithm
by the parameters RBCT_TIME (rebroadcast time),
INT_BTW_REQ (interval between request), REQ_TO
(request timeout), and TIME_TO_WAIT, and a brief
explanation of their roles is given as follows:
• RBCT_TIME (rebroadcast time): time between the
reception of the first COUNT_REQUEST, and the first
rebroadcast of the COUNT_REQUEST by the node.
• INT_BTW_REQ (interval between request): time
interval between the sending of COUNT_REQUEST
messages. In other words, it also represents the time
between two consecutive COUNT_REQUEST
messages sent by the actual node.
• REQ_TO (request timeout): it is the time between the
reception of the first COUNT_REQUEST and the
moment when the node has to send the
COUNT_REPLY message to nodeToGoBack toward
the originator.

• t1 = time when a node receives the first
COUNT_REQUEST
• t2 = t1 + RBCT_TIME
• t3 = t1 + RBCT_TIME + 1*INT_BTW_REQ
• t4 = t1 + RBCT_TIME + 2*INT_BTW_REQ
• t5 = t1 + REQ_TO.
Figure 1 also shows that a node will rebroadcast the
received COUNT_REQUEST message and will additionally
send a COUNT_REPLY message after a specific time, i.e.,
when a node receives the first COUNT_REQUEST message
at time t1, it will broadcast three consecutive
COUNT_REQUEST messages at time t2, t3 and t4, and will
• TIME_TO_WAIT: it is the time a node waits after the
rebroadcast of the last COUNT_REQUEST message
and the sending of the COUNT_REPLY message to
nodeToGoBack toward the originator. This time must
be big enough to allow the propagation of
COUNT_REQUEST messages from the actual node
toward nodes that are far away from the originator, and
the propagation of the COUNT_REPLY messages from
the nodes that are far away from the originator toward
the actual node. By the way, TIME_TO_WAIT is not a
constant value and will be computed by every node
according to HopLimit and how far away it is from the
originator (called HopAway in the algorithm).

Figure 1 Timing diagram

REQ_TO

t1 t2 t3 t4 t5
Time
RBCT_TIME INT_BTW_REQ INT_BTW_REQ TIME_TO_WAIT

Node receiv es the Node has to rebroadcast Node has to rebroadcast Node has to rebroadcast Node has to
f irst C OUNT_R EQUEST the C OUNT_R EQUEST the C OUNT_R EQUEST the C OUNT_R EQUEST send the
(1st rebroadcast) (2nd rebroadcast) (3rd rebroadcast) C OUNT_R EPLY
4 E. Gamess and M. Contreras
Figure 2 COUNT_REQUEST and COUNT_REPLY messages
3.2 COUNT_REQUEST and COUNT_REPLY
messages
COUNT_REQUEST and COUNT_REPLY messages have
the same protocol data unit (PDU) and are composed of six
fields (see Figure 2).
The field Message Type can be either 0 or 1. It is used to
identify the type of message. A value of 0 is for a
COUNT_REQUEST, while 1 is for a COUNT_REPLY.
Sequence Number is used to match requests with
replies and to distinguish between different requests
(COUNT_REQUEST). Timestamp is set by the originator
when it sends a COUNT_REQUEST message and is aimed
to control out-of-date messages and replay attacks. The
originator and the nodes broadcast COUNT_REQUEST
messages along with the argument HopAway which
represents the number of hops-away the receiver of the
COUNT_REQUEST message is from its originator. The
originator, which starts the process, must specify a value of
HopAway equal to 1. Each node that rebroadcasts the
message will select the smallest HopAway received up to
now and will increment this field by 1. Every time a node
updates its HopAway field due to the reception of a better
COUNT_REQUEST (closer to the originator), it has to
update its nodeToGoBack variable. nodeToGoBack is a
reference to the node with the lowest HopAway from which
the actual node has received a COUNT_REQUEST
message. HopLimit field is a way to control how far away
COUNT_REQUEST messages are propagated from the
originator toward the other nodes. It delimits the counting
range. The field Total is filled with the number of nodes
counted up to now. In COUNT_REQUEST messages, it is
always equal to 0. Before sending a COUNT_REPLY
message, a node must update this field according to the
COUNT_REPLY messages received so far, and add 1 to the
sum that represents itself. The COUNT_REPLY message is
sent to the node identified by nodeToGoBack.
3.3 Algorithm
The originator first sends three messages of type
COUNT_REQUEST as broadcast with a HopAway
equal to 1 (separated by INT_BTW_REQ). When a node
receives the first COUNT_REQUEST message, it will do
the following after:
• RBCT_TIME: the node rebroadcasts the
COUNT_REQUEST with a HopAway equal to the
minimum HopAway received by this time +1. The node
also registers the ID of the node (in variable
nodeToGoBack) that sent the COUNT_REQUEST with
the minimum HopAway.
• RBCT_TIME + 1 * INT_BTW_REQ: the node
rebroadcasts the previous COUNT_REQUEST
message (because of possible collision with the first
COUNT_REQUEST sent). If required, the fields of the
COUNT_REQUEST message are updated.
• RBCT_TIME + 2 * INT_BTW_REQ: the node
rebroadcasts the previous COUNT_REQUEST
message (because of possible collision with the first
and second COUNT_REQUEST sent). If required, the
fields of the COUNT_REQUEST message are updated.
• REQ_TO: If the node did receive COUNT_REPLY
messages, then the node computes the total of nodes
based on variable Total received in COUNT_REPLY
messages (+1 to represent itself in the total count) and
sends the result to nodeToGoBack, as a unicast
message. If after REQ_TO the node did not receive any
COUNT_REPLY message, then it generates a
COUNT_REPLY with Total equal to 1 (this 1
represents itself) and sends it to nodeToGoBack, as a
unicast message.
3.4 Example of propagation scenario
Figure 3 shows an example of scenario where n1, n2, n3, ...,
n12 are the nodes and O is the originator. Circles around the
nodes represent the propagation range of messages sent by
themselves.
In Figure 4, we can observe how COUNT_REQUEST
messages are propagated from the originator toward nodes
that are far away from the originator and how HopAway
(represented as HA) is updated. The first
COUNT_REQUEST message (with HA = 1) sent by the
originator is received by n1, n2, and n3, since they are
within its range of propagation. Each one of this receiver
node will retransmit the COUNT_REQUEST with a value
of HA = 2. The rebroadcast sent by n1 will be received by O
(the originator) and n9. O will discard the message, since it
is a copy of its own petition. n9 will rebroadcast the
COUNT_REQUEST with a HA = 3. This message is
received by n1 and n11. n1 will discard it, because it is a
count petition already received with a highest HA that the
one received from O. n11 will rebroadcast the
COUNT_REQUEST with a HA = 4. This petition will be
received by n9 that will discard it since it already got this
petition from n1 with a lowest HA.
 A proposal for an algorithm to count nodes using wireless technologies 5

Figure 3 Example of a propagation scenario (see online version for colours)

Figure 4 Propagation of COUNT_REQUEST messages (see online version for colours)

Likewise in Figure 5, we can see how COUNT_REPLY 3.5 Calculation of TIME_TO_WAIT

messages are propagated from nodes that are far away from
According to the timing diagram of Figure 1, we determine
the originator toward the originator and how Total is
the time that a node waits after the rebroadcast of the last
updated. n11 will not receive any COUNT_REPLY
COUNT_REQUEST message and the sending of the
message, and will send its own COUNT_REPLY to n9
COUNT_REPLY message to nodeToGoBack toward the
when its REQ_TO (request timeout) timer expires.
originator (called TIME_TO_WAIT), according to its
n11 will set the value of Total to 1 to represent itself in the
HopAway value as:
counting. n9 will only receive one COUNT_REPLY
message (from n11), and will add 1 to the received total, to • For the originator (HopAway = 0):
represent itself in the counting, before sending its own
TIME _ TO _ WAIT
COUNT_REPLY to n1 with Total = 2. n1 will only receive
one COUNT_REPLY message (from n9), and will add 1 to = HopLimit * RBCT _ TIME * α
the received total, to represent itself in the counting, before + NUM _ RBCT * ( HopLimit – 1)
sending its own COUNT_REPLY to O with Total = 3. The
* INT _ BTW _ REQ * β
originator will receive three COUNT_REPLY messages
from n1, n2, and n3, with a total of 3, 5, and 4, respectively. + HopLimit * DELAY * δ
The originator will sum the received totals, and conclude
that there are 12 nodes in its neighbourhood.
6 E. Gamess and M. Contreras

• For the last nodes (HopAway = HopLimit):
TIME _ TO _ WAIT = RBCT _ TIME * α
• And for other nodes:
TIME _ TO _ WAIT
= ( HopLimit – HopAway ) * RBCT _ TIME * α
+ NUM _ RBCT * ( HopLimit – 1 – HopAway )
* INT _ BTW _ REQ * β
+ ( HopLimit – HopAway ) * DELAY * δ
where α, β, and δ represent values to accelerate the
propagation of the COUNT_REQUEST
COUNT_REPLY messages. DELAY is a constant that
represents the time required to send a single message using
unicast.
To further clarify the concept of HopLimit, let us
consider the example of the simulation scenario of Figure 6.
As depicted, we can see that when the originator sends a
COUNT_REQUEST message with HopLimit equal to 1, it
must count four nodes (n8, n10, n16, and n18). With a value
of HopLimit equal to 2, the originator will count 8 nodes
(n4, n8, n10, n11, n12, n16, n18, and n19). With a value of
HopLimit equal to 3, the originator will count 11 nodes
(n4, n6, n8, n10, n11, n12, n15, n16, n18, n19, and n20).
Putting a value greater than 3 for HopLimit will not change
the counting, i.e., the originator will still count the same
and 11 nodes, since nine nodes (n1, n2, n3, n5, n7, n9, n13, n14,
and n17) cannot be reached from the originator.

Figure 5 Propagation of COUNT_REPLY messages (see online version for colours)

Figure 6 Example of simulation scenario (see online version for colours)

 A proposal for an algorithm to count nodes using wireless technologies 7

4 Simulation environment and scenarios The proposed algorithm was implemented in

OMNeT++/INET and we simulated different scenarios
There are several simulation environments offered by the
where nodes are randomly distributed over a rectangular
industry (e.g., OPNET, Tetcos NetSim, QualNet, and
area. The random waypoint mobility model was chosen to
EstiNet) and the Internet community (e.g., JiST/SWANS,
reflect the most general scenario of node movements. We
OMNeT++, ns-2, ns-3, GloMoSim, and NCTUns). Some
selected WiFi (Lemstra et al., 2013) (IEEE 802.11g)
comparative studies of these tools and environments are
for the wireless communication standard, with a bitrate of
presented in Gamess and Veracoechea (2010). For our
54 Mbps. It is worth mentioning that choosing WiFi does
research, we decided to focus on open-source network
not limit our algorithm to this technology, and it can be
simulators since they are free of charge and the source code
ported to other wireless technologies such as wireless access
is available, allowing users to change it when required. We
in vehicular environment (WAVE) (IEEE 1609.4, 2006;
determined not to use JiST/SWANS since it is a dead
Lee et al., 2014; Martinez, 2011; Durresi et al., 2007), since
project since 2005. GloMoSim has changed its license and
the algorithm does not rely on any particular properties of
nowadays, it is developed as a commercial product called
WiFi. The free space propagation model was chosen for
QualNet. NCTUns has moved also to a commercial license
path loss, which basically represents the communication in
called EstiNet. ns-2 has been widely used by the research
an open field, without obstacles, where the propagation
community, but has been superseded by ns-3. This
range can be represented as a circle around the transmitter.
narrowed us to two simulation environments (OMNeT++
If a receiver is within the circle, it receives the packets,
and ns-3), which are excellent development tools, both
otherwise, it loses all the packets (Rappaport, 2001).
suitable for our research.
OMNeT++ (http://www.omnetpp.org) (Chamberlan,
2013) is an open source, C++-based (Quintino and
5 Results of our simulations
Deconinck, 2009), multiplatform (Windows, MacOS, and
Unix), discrete event simulator for modelling any system In this section, we present and discuss some of the results of
composed of devices interacting with each other. our simulations that were executed in four types of
OMNeT++ is fully programmable and modular, and it was scenarios:
designed from the ground up to support modelling very
1 stationary scenarios, where nodes and the originator are
large networks built from reusable model components. One
immobile
of the main strengths of OMNeT++ is its graphical user
interface (GUI). Through the GUI, users can create NED 2 in scenarios with mobile nodes and stationary
files (a description language to define the structure of the originator
model) and inspect the state of each component during
3 in scenarios with stationary nodes and mobile
simulations.
originator
For simulations of data networks, OMNeT++ relies on
external extensions (e.g., MiXiM, Castalia, INET, and 4 in scenarios where both nodes and originator are
INETMANET). MiXiM is oriented to lower layers. Castalia mobile.
is more suitable for Wireless Sensor Networks (WSNs). The
We also have a fifth scenario, where we vary the size of the
INET Framework is an open-source communication
rectangular area where the nodes and the originator are
network simulation package for the OMNeT++ simulation
placed and can move. We propose this fifth scenario to
environment. It contains models for several wired and
study how the size of the area can affect the algorithm, and
wireless networking protocols, including UDP, TCP, SCTP,
see if it presents scalability issues.
IP, IPv6, Ethernet, PPP, 802.11, MPLS, OSPF, and many
others. INETMANET is an extension of INET that
additionally provides MANET protocols (AODV, OLSR, 5.1 Stationary nodes and originator scenarios
DSR, DSDV, DYMO, and BATMAN). We did several simulations for stationary scenarios, where
For this research, we decided to use OMNeT++ for two nodes and the originator are immobile. The goal of our
main reasons: first experiment is to show the importance of choosing
1 its powerful GUI which facilitates the traceability and appropriate values for RBCT_TIME, INT_BTW_REQ, and
debugging of simulation models, by displaying the DELAY. Therefore, we did simulations with 50 stationary
network graphics, animating the message flow and nodes, randomly positioned in a squared scenario of
letting users peek into objects and variables within the 800 m × 800 m, with a propagation range of 250 m, and an
model originator situated in the middle of the squared scenario,
starting the counting with a value of HopLimit equal to 3.
2 it is a very active project with many models that are Table 1 shows the results that we obtained when varying the
constantly updated. values of RBCT_TIME, INT_BTW_REQ, and DELAY, as
These features make OMNeT++ a good candidate for both specified in its first column. All the 50 nodes are reachable
research and educational purposes (Varga, 2001). from the originator using multihop routing, within three
hops, as stated in the second column. The third column
8 E. Gamess and M. Contreras

specifies the number of nodes that our algorithm could
count. In the last three columns, we put the associated
response time (total time required for the counting to
complete), the counting error in percent, and the total
messages sent (COUNT_REQUEST and COUNT_REPLY)
during the counting. As we can observe, lower values of
RBCT_TIME, INT_BTW_REQ, and DELAY have a
smaller response time, but the counting error is bigger. On
the other hand, higher values of RBCT_TIME,
INT_BTW_REQ, and DELAY have a bigger response time,
but a more accurate counting. Choosing the correct values
for these parameters is a trade-off between low response
time and high accuracy, and application developers will
have to select these parameters according to their needs.
Table 2 shows that choosing adequate values of
RBCT_TIME, INT_BTW_REQ, and DELAY can achieve
high counting accuracy. In these simulations, we vary the
total number of static nodes (10, 15, 20, 25, 30, 35, 40,
and 50) randomly placed in a squared scenario of
800 m × 800 m, and their propagation range (100 m, 150 m,
200 m, 250 m, and 300 m). The results are represented as
values a/b, where a denotes the number of nodes that are
within the scope of the originator using multihop routing
(i.e., nodes that should be counted), and b the number of
nodes actually counted by our algorithm. Based on the
results in Table 1, we choose the following values
for the parameters hopLimit = 3, RBCT_TIME = 0.2 s,
INT_BTW_REQ = 0.2 s, and DELAY = 0.4 s, with the
purpose of get a more accurate count.
Since there are nodes that are not reachable in these
scenarios, we can see that our algorithm is performing an
effective count. For example, Table 2 shows that for a
scenario of 25 nodes and a propagation range equal to
250 m, 23 nodes should be counted by the originator, i.e., in
this case 2 nodes are not reachable from the originator
because they are out of the counting range (farther away
than three hops or unreachable). Now, when we run the
simulation, our algorithm counted 22 nodes, instead of
23 nodes, which is a good approximation. Table 3 gives
additional information (response time, counting error, and
total messages sent) for the same experiments, in the case of
a propagation range of 250 m. As reported in Table 3, for a
total number of nodes equal to 25, and a propagation range
of 250 m, 22 out of 23 reachable nodes were counted by our
algorithm in 2.74 s, with a total number of sent messages
(COUNT_REQUEST and COUNT_REPLY) equal to 60.

Table 1 Importance of RBCT_TIME, INT_BTW_REQ, and DELAY

RBCT_TIME, Propagation range value = 250 m

INT_BTW_REQ, DELAY Reachable nodes Node count algorithm Response time Counting error Total messages sent
0.01 s, 0.01 s, 0.03 s 50 10 0.15 s 80.0% 155
0.05 s, 0.05 s, 0.10 s 50 15 0.63 s 70.0% 158
0.05 s, 0.05 s, 0.20 s 50 18 0.88 s 64.0% 158
0.10 s, 0.10 s, 0.20 s 50 23 1.26 s 54.0% 167
0.10 s, 0.10 s, 0.40 s 50 34 1.76 s 32.0% 167
0.20 s, 0.20 s, 0.30 s 50 43 2.28 s 14.0% 173
0.20 s, 0.20 s, 0.40 s 50 47 2.36 s 6.0% 173
0.25 s, 0.25 s, 0.30 s 50 48 2.66 s 4.0% 173
0.30 s, 0.30 s, 0.50 s 50 50 3.24 s 0.0% 173

Table 2 Nodes counted in different stationary scenarios

Propagation range values in metres

Total number of nodes
100 m 150 m 200 m 250 m 300 m
10 1/1 1/1 3/3 10/10 10/10
15 2/2 4/4 7/7 14/14 15/15
20 2/2 4/4 11/11 19/19 20/20
25 4/4 8/8 14/14 23/22 25/24
30 5/5 14/14 24/23 29/28 30/30
35 7/7 16/16 29/27 34/33 35/35
40 8/8 22/22 34/33 39/39 40/37
50 11/11 28/26 48/43 50/50 50/50
 A proposal for an algorithm to count nodes using wireless technologies 9

Table 3 Response time, counting error, and total number of sent messages in a specific stationary scenario

Total number of Propagation range value = 250 m

nodes Reachable nodes Node count algorithm Response time Counting error Total messages sent
10 10 10 2.61 s 0.0% 27
15 14 14 3.05 s 0.0% 33
20 19 19 2.95 s 0.0% 45
25 23 22 2.74 s 4.3% 60
30 29 28 3.32 s 3.4% 105
35 34 33 2.72 s 2.9% 124
40 39 39 2.73 s 0.0% 139
50 50 50 2.61 s 0.0% 148

5.2 Mobile nodes and stationary originator In Table 5, we chose a fixed propagation range of 250 m,
scenarios but we vary the speed of the nodes and the number of nodes.
Similarly to the previous experiment (see Table 4), we have
In this section, we look at the performance of our algorithm an effective counting for speeds up to 20 mps (72 km/h).
when nodes are mobile, but the originator is static and For highest speeds, the accuracy of the counting degrades.
placed in the centre of an 800 m x 800 m squared area. For
the movement of nodes, we used the random way point Table 5 Nodes counted when varying the speed of nodes and
mobility model (RandomWPMobility) where each node has the number of nodes
its own constant speed, and a wait time of 0 s (time interval
between reaching a target and choosing a new one). Nodes Total number of nodes
In Table 4, we varied the propagation range of the nodes speed
(mps) 10 15 20 25 30 35 40 50
and the originator. The third row, labelled with ‘0–5’,
indicates that each node chooses its speed randomly at the 0–5 9/9 11/11 19/19 25/25 30/29 35/34 40/39 50/49
beginning of the simulation, between 0 mps (0 metres per 0–10 10/10 15/14 18/18 25/25 30/29 35/33 40/38 50/48
second) and 5 mps (five metres per second), and maintains 0–15 8/8 14/14 20/20 25/24 30/30 35/34 40/39 50/48
this speed throughout the simulation. For all these scenarios, 0–20 8/7 11/11 19/19 25/23 30/29 35/34 40/38 50/47
we took 30 mobile nodes that are initially randomly placed
0–25 8/6 15/13 20/15 25/21 30/26 35/31 40/33 50/45
with values of RBCT_TIME = 0.2 s, INT_BTW_REQ = 0.2
s, and DELAY = 0.4 s. The originator starts the counting 0–30 9/6 15/11 19/15 24/20 30/25 35/30 40/32 50/43
process with hopLimit = 3. As expected, we can note that 0–35 6/3 15/10 19/13 24/20 30/23 35/28 40/31 50/41
we have a high counting accuracy for lower speeds, and as 0–40 8/5 15/10 19/12 25/19 30/22 35/26 40/30 50/39
the speeds increase, we lose precision in the node counting. 0–45 9/5 15/9 19/12 25/20 30/23 35/27 40/31 50/38
This is due to the frequent topological changes, which result
0–50 9/4 14/10 19/12 25/19 29/23 35/26 40/30 50/37
in breaking the path of the COUNT_REPLY message
toward the originator. We can see that the best results are
obtained when the speed varies up to 20 mps (72 km/h). 5.3 Stationary nodes and mobile originator
scenarios
Table 4 Nodes counted when varying the speed of nodes and
propagation range values In this section, we study the behaviour of the proposed
algorithm for stationary nodes and a mobile originator. At
Nodes Propagation range values in metres the beginning of the simulations, the static nodes are
speed
100 m 150 m 200 m 250 m 300 m randomly positioned in an 800 m × 800 m squared scenario.
(mps)
The originator is initially placed at the centre of the
0–5 3/2 16/15 27/27 30/29 30/29 scenario, and is moving according to the random way point
0–10 4/4 16/15 28/26 30/29 30/27 mobility model, without making stops at the visited
0–15 4/4 23/21 30/28 30/30 30/28 positions, i.e., with a wait time of 0 s. For both nodes and
0–20 15/15 23/19 30/27 30/28 30/29 originator, we chose values of RBCT_TIME = 0.2 s,
INT_BTW_REQ = 0.2 s, and DELAY = 0.4 s. The
0–25 6/4 27/22 30/26 30/26 30/25
originator starts the counting process with a hopLimit value
0–30 4/2 27/21 25/15 30/25 30/26 of 3.
0–35 15/9 25/21 30/19 30/24 30/25 Table 6 shows the results of the simulations for
0–40 15/7 25/19 30/19 30/24 30/24 scenarios with 30 nodes, where we vary the speed of the
0–45 21/10 26/20 29/17 30/23 30/22 originator as well as the propagation range of the originator
and the nodes. We can note that we have a high accuracy in
0–50 18/7 25/17 29/17 29/24 30/20
10 E. Gamess and M. Contreras

the counting for speeds up to 20 mps (72 km/h), and as the DELAY = 0.4 s. The originator starts the counting process
speeds increase, the accuracy of the counting degrades. with a hopLimit = 3.
Table 8 shows the results of the simulations for
Table 6 Nodes counted when varying the speed of the scenarios with 30 nodes, where we varied the speed of the
originator and the propagation range values nodes and the originator as well as their propagation range.
Originator Propagation range values in metres
Table 8 Nodes counted when varying the speed of nodes and
speed
100 m 150 m 200 m 250 m 300 m the originator as well as the propagation range values
(mps)
5 8/7 14/14 24/24 28/27 30/30 Speed Propagation range values in metres
10 4/4 9/9 21/21 28/27 30/30 (mps) 100 m 150 m 200 m 250 m 300 m
15 4/4 10/10 20/20 26/26 28/28 0–5 3/3 11/10 30/30 30/29 30/29
20 4/4 10/9 15/15 23/22 25/24 0–10 2/2 19/18 27/26 30/29 30/29
25 4/2 9/6 13/10 23/17 30/24 0–15 4/3 22/21 30/28 30/28 30/29
30 4/2 10/7 15/10 18/15 25/20 0–20 6/6 17/16 26/25 30/28 30/29
35 4/1 10/6 15/9 21/16 29/21 0–25 6/5 18/13 30/26 30/26 30/25
40 4/2 10/5 21/16 22/15 30/22 0–30 8/5 26/21 30/23 30/25 30/25
45 6/2 13/8 21/15 27/16 30/23 0–35 13/7 24/19 30/22 30/24 30/24
50 7/3 17/10 26/16 27/15 30/21 0–40 11/7 20/13 30/23 30/22 30/23
0–45 11/6 24/17 29/22 30/23 30/22
In Table 7, we chose a fixed propagation range of 250 m,
but we varied the speed of the originator as well as the 0–50 10/5 26/17 29/21 30/21 30/20
number of nodes. Once again, the obtained results evidence
In Table 9, we chose a fixed propagation range of 250 m,
that our algorithm effectively performs the node counting
but we varied the speed of the nodes and the originator as
when the speed of the originator is less than or equal to 20
well as the number of nodes. Similarly to the previous
mps (72 km/h).
experiment (see Table 8), we have an effective counting for
Table 7 Nodes counted when varying the speed of the speeds up to 20 mps (72 km/h).
originator and the number of nodes
Table 9 Nodes counted when varying the speed of nodes and
Originator Total number of nodes the originator as well as the number of nodes
speed
(mps) 10 15 20 25 30 35 40 50 Speed Total number of nodes
(mps) 10 15 20 25 30 35 40 50
5 7/7 14/14 17/17 23/23 28/27 33/32 40/39 50/48
10 7/7 12/12 17/17 23/23 28/27 33/32 40/38 50/48 0–5 4/4 15/15 20/20 25/24 30/29 35/34 40/39 50/49
15 8/8 11/11 17/16 23/22 26/25 31/30 40/38 47/45 0–10 5/5 12/12 20/20 25/24 30/29 35/34 40/39 50/48
20 7/7 12/12 16/16 23/22 23/22 30/29 40/37 47/44 0–15 3/3 3/3 20/20 25/25 30/28 35/33 40/38 50/47
25 7/4 12/10 15/12 23/19 23/16 30/24 40/30 50/36 0–20 3/3 3/3 20/19 25/24 30/28 35/33 40/38 50/47
30 6/3 12/9 15/11 23/18 22/16 31/25 34/25 49/36 0–25 4/3 15/13 20/16 25/20 30/26 35/30 40/32 50/39
35 7/3 12/7 16/11 23/17 22/15 31/24 34/24 49/35 0–30 6/5 15/11 20/15 25/18 30/24 35/29 39/30 50/37
40 5/2 12/7 16/11 23/16 24/15 31/22 34/23 47/33 0–35 8/6 15/10 20/15 25/18 30/22 35/27 35/28 50/34
45 5/2 12/7 17/11 23/15 27/16 31/21 40/24 46/32 0–40 9/4 13/6 20/12 24/16 30/19 35/25 38/27 50/32
50 5/2 12/6 17/10 23/15 27/15 31/20 40/24 46/29 0–45 10/5 14/8 20/11 22/12 30/20 35/23 38/25 50/30
0–50 10/5 10/5 20/11 22/11 30/19 35/20 40/26 50/28

5.4 Mobile nodes and originator scenarios

In this section, we report results relevant to the proposed
algorithm when both the nodes and the originator are
mobile. At the beginning of the simulations, the nodes are
randomly positioned in an 800 m × 800 m squared area,
while the originator is initially placed at its centre. Both, the
nodes and the originator are moving according to the
random way point mobility model, without making stops at
the visited positions, i.e., with a wait time of 0 s.
For both nodes and the originator, we chose values of
RBCT_TIME = 0.2 s, INT_BTW_REQ = 0.2 s, and
5.5 Changing the size of the simulation scenarios
We also performed some experiments by changing the size
of the rectangular area (see Table 10). At the beginning of
the simulations, the nodes are randomly positioned in a
rectangular area, while the originator is placed at its centre.
The number of nodes is selected to have a density of
100 nodes/km2. Both, the nodes and the originator are
stationary. We chose a fixed propagation range of 250 m.
For both nodes and originator, we selected values of
RBCT_TIME = 0.2 s, INT_BTW_REQ = 0.2 s, and
 A proposal for an algorithm to count nodes using wireless technologies 11

DELAY = 0.4 s. The originator starts the counting process
with a hopLimit = 3.
The experiments of Table 11 are similar to the ones of
Table 10, except that nodes and originator are mobile. Both,
nodes and originator are moving according to the random
way point mobility model, without making stops at the
visited positions, i.e., with a wait time of 0 s. At the
beginning of the simulation, each device (nodes and
originator) selects its own speed randomly between 0 mps
and 20 mps (0 km/h and 72 km/h) and maintains a constant
speed throughout the simulation, resulting in devices
moving at constant speeds, but having different speeds
between each others. In this case also, Tables 10 and 11
show that our algorithm is performing well, in different
sized areas, with moderate speeds.
6 Conclusions and future work
In this paper, we presented an algorithm to count nodes
using wireless technologies. To the best of our knowledge,
very few studies are based on wireless networks in this
direction. Broadly speaking, most of the work done has
been implemented using conventional ‘in-situ’ technologies
based on pictures, videos, sensors, etc.
To validate our algorithm, we made two types of
simulations:
1 when all devices are stationary
2 when mobility is involved in the experiments resulting
in changing the topology between devices.
These devices were distributed randomly on a rectangular
area. According to our simulations, with adequate values of
the parameters, we can conclude that our algorithm
successfully discloses the total number of nodes when all
the devices are static, with a small number of broadcast and
Table 10 Nodes counted when varying the size of the rectangular area (stationary nodes and originator)
unicast messages sent. Moreover, for the mobile scenarios,
the results of the simulations indicated that the algorithm
performs well for speed up to 20 mps (72 km/h). This speed
is high enough for many applications, and our algorithm can
be used to count people, animals, bicycles, etc., even when
they move at their highest speeds.
Additionally, we also performed some experiments
where we varied the size of the rectangular area where
nodes and the originator are placed and moved, with the aim
of evaluating how the size of the area can affect the
algorithm, and test it for scalability issues. In this case also,
simulation results indicate that our algorithm also performs
an adequate counting, in different sized areas, with
moderate speeds.
As future work, we plan to improve our algorithm to get
a more effective counting when nodes are moving at higher
speeds, based on their actual position and their possible
position when the COUNT_REPLY is sent (i.e., we will
equip our devices with a GPS receiver), and where nodes
will adapt their propagation range for a more efficient
energy consumption and a reduction of frame collisions
(Ghada et al., 2010). We also plan to adapt our algorithm to
wireless networks with multichannels with the intention of
reducing the collisions that occur between the counting
PDUs (COUNT_REQUEST and COUNT_REPLY) and
users’ traffic, and thus, possibly improve the accuracy of the
counting in scenarios with high density of nodes. Finally,
we are interested in studying the application of our
algorithm in the vehicular context (motorways, urban roads,
rural roads, parkings, etc.) using WAVE (IEEE 1609.4,
2006; Lee et al., 2014; Martinez, 2011; Durresi et al., 2007)
standards such as IEEE 802.11p, to discuss its possible
implementation for improving the safety and comfort of
drivers and passengers.

Size of the area Total number of nodes Reachable nodes Node count algorithm Response time Total messages sent
500 m × 500 m 25 25 23 2.69 s 100
500 m × 750 m 38 38 36 2.72 s 140
500 m × 1,000 m 50 50 46 2.57 s 164
500 m × 1,250 m 63 61 54 2.76 s 165
500 m × 1,500 m 75 60 52 2.56 s 169
700 m × 800 m 56 56 53 2.62 s 179
700 m × 1,000 m 70 70 63 2.70 s 205
700 × 1,250 m 90 89 79 2.76 s 257
800 m × 800 m 64 64 53 2.66 s 223
800 m × 1,000 m 80 79 67 2.58 s 235
1,000 m × 1,000 m 100 95 82 2.67 s 263
1000 m x 1250 m 125 112 94 2.81s 280
1250 m x 1250 m 156 117 95 2.70 s 300
1500 m x 1500 m 225 127 108 2.86 s 351
2000 m x 2000 m 400 130 110 2.65 s 305
12 E. Gamess and M. Contreras

Table 11 Nodes counted when varying the size of the rectangular area (mobil nodes and originator)

Size of the area Total number of nodes Reachable nodes Node count algorithm Response time Total messages sent
500 m × 500 m 25 25 25 2.75 s 100
500 m × 750 m 38 38 36 2.74 s 154
500 m × 1,000 m 50 50 45 2.62 s 194
500 m × 1,250 m 63 63 57 2.72 s 210
500 m × 1,500 m 75 72 63 2.58 s 222
700 m × 800 m 56 56 52 2.78 s 206
700 m × 1,000 m 70 70 63 2.78 s 274
700 m × 1,250 m 90 90 77 2.62 s 315
800 m × 800 m 64 64 59 2.75 s 256
800 m × 1,000 m 80 79 71 2.82 s 256
1,000 m × 1,000 m 100 100 85 2.69 s 343
1,000 m × 1,250 m 125 125 109 2.59 s 410
1,250 m × 1,250 m 156 146 128 2.73 s 414
1,500 m × 1,500 m 225 172 158 2.76 s 416
2,000 m × 2,000 m 400 166 149 2.59 s 395

Acknowledgements Gamess, E. and Mahgoub, I. (2011) ‘A novel VANET-based

We thank the Consejo de Desarrollo Científico y
Humanístico (CDCH-UCV) which partially supported this
research under grant number: PG 03-8066-2011/1.
References
Bescos, J., Menendez, J. and Garcia, N. (2003) ‘DCT based
segmentation applied to a scalable zenithal people counter’,
in Proceedings of the International Conference on Image
Processing (ICIP), Madrid, Spain, September.
Bu, F. and Chan, C. (2005) ‘Pedestrian detection in transit bus
application: sensing technologies and safety solutions’,
in Proceedings of the IEEE Intelligent Vehicles Symposium,
pp.100–105, June.
Chamberlan, T. (2013) Learning OMNeT++, September, Packt
Publishing, Birmingham, UK.
Chen, Q., Gao, M., Ma, J., Zhang, D., Ni, L. and Liu, Y. (2008)
‘MOCUS: moving object counting using ultrasonic sensor
networks’, International Journal of Sensor Networks, Vol. 3,
No. 1, pp.55–65.
Daigavane, P. and Bajaj, P. (2010) ‘Real time vehicle detection
and counting method for unsupervised traffic video on
highways’, International Journal of Computer Science and
Network Security, August, Vol. 10, No. 8, pp.112–117.
Durresi, A., Durresi, M., Bulusu, V. and Barolli, L. (2007) ‘Secure
broadcast for inter vehicle communications’, International
Journal of High Performance Computing and Networking,
Vol. 5, Nos. 1/2, pp.54–61.
Evers, J., Kiss, D. and Kowalczyk, W. (2011) ‘Node counting in
wireless ad-hoc networks’, in Proceedings of the 79th
European Study Group Mathematics with Industry,
Amsterdam, Netherlands, January.
approach to determine the position of the last vehicle waiting
at a traffic light’, in Proceedings of the International
Conference on Wireless Networks (ICWN ‘11), Las Vegas,
Nevada, USA, July.
Gamess, E. and Veracoechea, C. (2010) ‘A comparative analysis
of network simulation tools’, in Proceedings of the
International Conference on Modeling, Simulation and
Visualization Methods (MSV ‘10), Las Vegas, Nevada, USA,
July.
Ghada, K., Li, J. and Ji, Y. (2010) ‘Energy and mobility-aware
topology control in heterogeneous mobile ad hoc networks’,
International Journal of Computational Science and
Engineering, Vol. 5, No. 2, pp.147–153.
IEEE 1609.4 (2006) IEEE Trial-Use Standard for Wireless Access
in Vehicular Environments (WAVE) – Multi-Channel
Operation, November.
Kettnaker, V. and Zabih, R. (1999) ‘Counting people from
multiple cameras’, in Proceedings of the International
Conference on Multimedia Computing and Systems, Florence,
Italy, June.
Khoudour, L., Deparis, J.P. and Duvieubourg, L. (1996) ‘Linear
image sequence analysis for passengers counting in public
transport’, in Proceedings of the IEEE International
Conference on Public Transport Electronic Systems, London,
UK, January.
Leduc, G. (2008) Road Traffic Data: Collection Methods and
Applications, European Commision, Joint Research Center,
Institute for Prospective Technological Studies, Seville,
Spain.
Lee, S., Lim, A. and Yang, Q. (2014) ‘An empirical study of
reliable networking for vehicular networks using IEEE
802.11n’, International Journal of Vehicle Autonomous
Systems, Vol. 12, No. 2, pp.141–157.
Lemstra, W., Hayes, V. and Groenewegen, J. (2013) The
Innovation Journey of Wi-Fi: The Road to Global Success,
Cambridge University Press, October.
 A proposal for an algorithm to count nodes using wireless technologies
Litzenberger, M., Kohn, B., Gritsch, G., Donath, N., Posch, C.,
Belbachir, N. and Garn, H. (2007) ‘Vehicle counting with an
embedded traffic data system using an optical transient
sensor’, in Proceedings of the 10th International IEEE
Conference on Intelligent Transportation Systems (ITSC ‘07),
Seattle, Washington, USA, September.
Martinez, F. (2011) Vehicular Ad Hoc Networks in Intelligent
Transportation Systems: Improving VANET Protocols to
Support Safety Applications in Realistic Scenarios, February,
LAP LAMBERT Academic Publishing, Saarbrücken,
Germany.
Pornpanomchai, C., Liamsanguan, T. and Vannakosit, V. (2008)
‘Vehicle detection and counting from a video frame’,
International Conference on Wavelet Analysis and Pattern
Recognition (ICWAPR ‘08), Hong Kong, September.
Quintino, T. and Deconinck, H. (2009) ‘Run-time automatic
instantiation of algorithms using c++ templates’,
International Journal of Computational Science and
Engineering, Vol. 4, No. 4, pp.314–324.
13
Rappaport, T. (2001) Wireless Communications: Principles and
Practice, Prentice Hall PTR, Upper Saddle River, New
Jersey, USA.
Schweizer, T. (2005) ‘Methods for counting pedestrians’,
in Proceedings of the 6th International Conference on
Walking in the 21st Century (Walk21-VI), ‘Everyday walking
culture’, Zurich, Switzerland, September.
Schwerdel, D., Priebe, M. and Müller, P. (2011) ‘A distributed
algorithm to estimate node counts in self-organizing ring
topologies’, in Proceedings of the IEEE Consumer
Communications and Networking Conference (CCNC),
pp.187–191, Las Vegas, Nevada, USA, January.
Varga, A. (2001) ‘The OMNeT++ discrete event simulation
system’, in Proceedings of the 15th European Simulation
Multiconference (ESM), Prague, Czech Republic, June.
Wu, J. and Gu, C. (2009) ‘The design and implementation of
real-time automatic vehicle detection and counting system’,
in Proceedings of the International Conference on
Information Engineering and Computer Science (ICIECS),
Wuhan City, China, December.