(IJCNS) International Journal of Computer and Network Security, 65

Vol. 2, No. 4, April 2010

Analysis and Proposal of a Geocast Routing

Algorithm Intended For Street Lighting System
Based On Wireless Sensor Networks
Rodrigo Palucci Pantoni1 and Dennis Brandão1
1
Eng. School of São Carlos of University of São Paulo,
São Carlos, Brazil
rodrigoppantoni@yahoo.com.br and dennis@sc.usp.br

distributed routing for retransmitting information to the

Abstract: This work is part of research project where are
studied and developed efficient technologies highlighted by the
ReLuz (Brazilian National Program of Public Lightning and
Efficient Light Signalization) program. It is proposed, in that
context, the development of remote command and monitoring
infrastructure for management purposes for large areas.
Specifically, it refers the research and analysis of efficient
routing algorithms in terms of energy consumption, guarantee
of package delivery and good performance (minimum delay).
Two new geocast routing algorithms are implemented and
compared with other candidates applied to street lighting system.
Such algorithms refer to wireless sensor networks IEEE
802.15.4 through multi-hop and low reach communication, and
low cost. The results show that the proposed algorithm GGPSRII
saves more energy, presents a good percentage of delivery
guarantee, good performance than compared ones.
Keywords: Lighting system, Geocast routing algorithm, IEEE
802.15.4, Wireless sensor network.
1. Introduction
Improvements in the quality of public lighting systems have
a direct impact in the quality of life for a large part of the
population as well as in the efficiency and rationality of
using electric power. This work is part of the research
project that intends to integrate the study and development
of efficient technologies in the scope of the Brazilian federal
government program ReLuz (National Program of Efficient
Public Lighting and Traffic Lights) [1]: a telecommand
system for managing public lighting in large areas. The
expected result is the economic operation of a public
lighting system with an economy index superior to the
indexes currently registered in the mentioned program, due
to the efficiency provided by the use of high performance
electronic systems together with a telecommand system.
The telecommand system is composed by devices attached to
the points of light, which are interconnected via network,
and software tools used for monitoring and control.
This work refers to the research and analysis for choosing
and implementing efficient network routing algorithms in
terms of electric power consumption, that is, besides the
rational use of the electric power, there is also the concern
about saving energy in terms of network communication.
The routing algorithm refers to IEEE 802.15.4 mesh-based
wireless sensor networks (WSN) through multi-hop
communication based on low range communication, low
cost and minimum electric power consumption, with
final destination. The IEEE 802.15.4 standard was chosen
because of its minimum consumption, low cost and protocol
simplicity.
The main challenge for this work is handling the limitations
of the IEEE 802.15.4 with the characteristics of dense
networks, trying to reach a balance among guarantee of
delivery, performance (minimum delay) and electric power
efficiency for the specific purpose of public lighting.
2. Correlated works of public lighting system
Several proposals found in the literature related to public
lighting use PLC technology (Power Line Communication)
[2, 3, 4]. However, there are a few limitations from this
technology when it is applied in public lighting [3, 5], such
as noise and impedance variations. Furthermore, Brazilian
infrastructure would have to be in perfect state to achieve a
good operation, but in reality the infrastructure is old and
would have to be rebuilt.
A company [6] applied the physical and data link layer
standard of the model ISO/OSI IEEE 802.11 to the wireless
network protocol, which has higher electric power
consumption and high communication rates. In this
solution, each point of light has a network point that
communicates and sends information to an Internet point.
In [7], it was proposed the use of ZigBee [8] as the protocol
for the lighting system. [9] mentioned that the use of ZigBee
is not suitable for public lighting systems, although it has
not been quantitatively proved. They suggested the use of
the network protocol 6LoWPAN [10] for devices IEEE
802.15.4 [11] and a GPS. 6LoWPAN is destined to devices
with low cost, low electric power waste and low
communication rates, and the main goal is to integrate the
Internet with WSN naturally. However, the use of
6LoWPAN over the layers defined in IEEE 802.15.4 does
not define a routing algorithm by itself. Nevertheless, such
proposal naturally matches the work hereby proposed.
3. Proposed public lighting system
To create the routing algorithm, it is necessary to visualize
the entire architecture, in brief, where the requirements are
displayed superficially. The requirements are: points
supervision (device status, whether it is connected to the
network or not; battery power; life time estimation for
66
battery and lamp; and LEDs luminosity level), control
(switch the luminosity level lamp on or off; switch on/off a
lamp post, a selected segment, a street, neighbourhood, city,
etc; automatic programmed actions and freedom to actuate
the devices through a remote tool) and diagnostic and
alarms (trigger an event when a network, hardware or lamp
failure occurs).
During each device’s initialization, a GPS set attributes the
geographic coordinates of their positions.
The user would be able to select a specific area on the map
besides the previously programmed area (for example,
selecting a segment from a street) to actuate (switch the
lights on or off). Figure 1 shows the area selected by the user
through the system supervision and control tool.
Figure 1. System Supervision and Control Screen
Mechanisms to automatize input information process in the
public lighting system must be applied, in order to become
the process simplest and fast. Such mechanisms are not in
the scope of this paper.
4. Correlated works of routing algorithms for
WSN
This section intends to review researches found in the
literature related to routing algorithms for WSN in general,
independent of the application.
Routing algorithms for mesh-based networks, such as
AODV (Ad-Hoc On Demand Distance Vector) [12], DSR
(Dynamic Source Routing) [13], and DREAM (Distance
Routing Effect Algorithm for Mobility) [13] were developed
to provide mobility. These algorithms are reactive, that is,
routes are determined by flooding through nodes searching
the addressee node when a flow of information (triggered by
the upper layer) occurs. When the route is determined, it is
stored in the memory of the participant nodes. This
mechanism causes high energy costs, performance costs and
guarantee of delivery costs. Besides, devices would have to
keep large routing tables in dense networks, which would be
impossible considering that such devices have low memory
available. It is also interesting to keep the minimum possible
overhead in the network package, because it is limited at
127 Kb by the IEEE 802.15.4 specification on the data link
(IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 4, April 2010
layer level.
In contrast to reactive algorithms, there are proactive
algorithms, such as DSDV (Dynamic Destination Sequenced
Distance-Vector) [14] and OLSR (Optimized Link State
Routing) [15]. Instead of building optimized routes only
when they are necessary, proactive algorithms keep a matrix
of connections always updated, which reflects the current
network status and channels available for data transfer.
From the computational and electric power consumption
point of view, these algorithms are too costly, especially
when providing mobility or when a fail occurs.
Geographic routing algorithms use the geographic location
of the devices as a reference, and the location can be
obtained from a GPS. The great advantage for this type of
routing is that routing tables are not necessary because the
devices decide where to forward the package according to
the smallest Euclidean distance of the destination
coordinate, for example.
Since those algorithms were designed for mobile devices,
one of the steps for this type of routing is transmitting
“hello” messages to all neighbouring devices (in radio
range), that periodically send packages with the
identification (such as the network address) of the device
and its position. So, the devices store the location of their
neighbours. They apply the greedy routing [16] by
transmitting a message to their neighbours that are
relatively closer in distance to the final destination. For any
variation of the greedy algorithm, it is important to define a
discard criterion to prevent the message from being
transmitted uninterruptedly over the network in case the
specified destination is not located. However, in cases where
it is necessary to find a balance between performance and
guarantee of delivery, the discard criterion must be defined
even if there is a path to the final addressee.
To assure package delivery, greedy algorithms are
frequently used combined with recovering strategies,
providing two operation modes. Such strategies are used
when a package is discarded in “pure” greedy mode, in case
there is an obstacle or a non-operating network device, for
example.
The most prominent recovering strategy uses planar graphs.
Basically, the idea is to draw the network as a unique graph
on a plane and forward the message in the direction of the
adjacent faces, which consequently forward the package to
the final destination. Those strategies are extensively
studied, as in GFG (Greedy-Face-Greedy) [17], GPVFR
(Greedy Path Vector Face Routing) [18], GPSR (Greedy
Perimeter Stateless Routing) [19] and GOAFR++ (Greedy
Other Adaptive Face Routing plus plus) [20].
In the GPSR algorithm, the recovering strategy is named
perimeter mode and uses the right hand rule to direct the
flow of network packages through the devices. In case the
distance from the device to the destination is smaller than
the distance to its neighbours, the algorithm returns to the
greedy mode.
The term unicast means a point-to-point connection where
data is sent from a sender to a receiver. The most
 (IJCNS) International Journal of Computer and Network Security, 67
appropriate type of routing in our context, however, is the
so-called geocast, that also requires the devices to know
their geographic positions via GPS. The algorithms deliver
network messages to the devices in a specific geographic
area, delivering a message from one device to many devices.
There are several routing algorithms developed for that
purpose, some based on flooding messages, directed
flooding messages, and without flooding. Flooding messages
algorithms find the path to the destination area the same
way AODV does. The first package arriving at the
destination area broadcasts to all nodes in the area. On the
other hand, directed flooding messages algorithms define
two types of areas, the destination and the routing area. An
example of directed flooding is the LBM (Location Based
Multicast) algorithm [21] that is executed as follows: the
routing area is defined as an area in the direction of the
destination area, and packages forwarded outside these two
areas are discarded.
5. Proposed Routing Algorithms
The algorithms proposed in this study, without flooding, are
named GGPSR (Geocast Greedy Perimeter Stateless Routing
Protocol) and GGPSR II (Geocast Greedy Perimeter
Stateless Routing Protocol II). They consist of two parts:
modified GPSR to find the destination area and geocast to
broadcast the message to all addressee devices.
Instead of using the specific coordinate of a device as the
destination, the central point of the destination area is
calculated. The package is then forwarded to this point and,
when it gets to the destination area, the first device
receiving the message broadcasts it to all devices in the area.
As soon as a device receives the broadcasted message, the
device checks if it has already received this message,
checking a sequential number and therefore avoiding
unnecessary retransmissions. In case the device has not
received the message yet but it is in the destination area, the
device receives and rebroadcasts the message to the network.
Table I shows the pseudo-algorithm GGPSR in a simplified
way.
Considering the GPSR part of the proposed algorithm
GGPSR (only), this work suggests some modifications for
lighting systems applications. The first modification is
related to the “hello” messages. For the discussed
application, devices are fixed. Initially, it was assumed that
only one “hello” message when the device is initialized
would be enough. However, it is interesting to keep this
functionality but with a periodicity much longer than what it
is used in mobile devices. The reason to still keep this
periodicity is that the device can simply stop operating
because of a permanent or temporary failure caused by an
obstruction. Information about the neighbors from the
devices can affect the network reliability because each
device is also a message router.
The second modification is related to storing geographic
positions for the neighbors (applied to GGPSR and
GGPSRII). Originally, GPSR has three types of messages:
“hello” messages, consultation to destination locations and
data messages [19]. “Hello” messages are responsible to
inform the new device’s location to its neighbors; data
Vol. 2, No. 4, April 2010
messages are responsible to forward the packages; and,
finally, consultation messages are responsible to obtain the
location of the addressees from one or more location
databases for a certain unique device’s identification (for
example, the network address). Once the scenario does not
have mobility, consultation messages and location servers
can be removed. Such functionality was implemented
through “hello” messages that send the unique identification
and the location. Besides, the supervision and control
software requires the location of all devices on the network.
Thus, the package would be sent by the system with the
geographic coordinate of the destination, instead of having
only the network address and requiring the current device to
obtain its location through the location server.
The difference between GGPSR and GGPSRII consists only
in the trigger condition of “hello” messages. In GGPSR, the
trigger is invocated according to a pre-determinated
frequency (period). On the other hand, in GGPSRII, the
trigger is invocated if only the data message does not reach
the destination (geocast region).Thus, it is necessary to
implement a confirmation message to inform the data
message forwarding failure. Table II show the GGPSRII
simplified pseudo-algorithm.
Table 1: GGPSR simplified pseudo-algorithm
// Initialization
For all devices
Send_Broadcast_Hello_Neighbors ();
Start Hello_Timer (period);
If Hello_Timer_Expire
Send_Broadcast_Hello_Neighbors ();
//Send
If (Packet.Destination_Position != myPosition &&
myPosition = = UNICAST)
ModifiedGPSR_Forward (Packet);
Else If (Packet.Destination_Position = = myPosition
&& myPosition = = GEOCAST){
If (Packet.seqN_ < ReceivedSeqNo){
Broadcast_Neighborhood_Geocast_Region(Packet);
}
}
//Receive
If (Packet.Destination_Position = = myPosition &&
myPosition = = UNICAST)
ModifiedGPSR_Receive (Packet);
Else If (Packet.Destination_Position = = myPosition
&& myPosition = = GEOCAST){
If (Packet.seqNo¬ _ < ReceivedSeqNo){
ModifiedGPSR_Receive (Packet);
}
}
Regarding the destination area, it can have the shape of a
four-vertex polygon, circle and point (in this last case, the
communication is unicast).
The geographic position is represented through geodesic
coordinates (latitude and longitude). Each coordinate is
allocated as floating types, which in language C has 4 bytes
and precision of seven decimal places. In relation to the
value ranges, this size is more than enough: the field
"hours" of the latitude coordinate varies between -180 and
180, whereas longitude varies between -90 and 90.
Table III shows the header struct in C language of the
packet types, including “hello” messages (hdr_gpsr_hello),
and data messages (hdr_gpsr_data) of the proposed protocol.
68 (IJCNS) International Journal of Computer and Network Security,
Vol. 2, No. 4, April 2010

Table 2: GGPSRII simplified pseudo-algorithm 6. Simulation and results

// Initialization
For all devices The simulation was analyzed to obtain quantitative data in
Send_Broadcast_Hello_Neighbors ();
order to decide which routing algorithm would be more
//Send appropriate to the problem in discussion. First, the ZigBee
If (Packet.Source_Position = = myPosition &&
myPosition = = UNICAST){ protocol (which uses AODV routing algorithm) was
ModifiedGPSR_Forward (Packet); evaluated because it is a consolidated standard that provides
Start Confirmation_Timer (period);
} interoperability among several manufacturers and reduced
Else If (Packet.Destination_Position != myPosition costs for production. For this reason, the AODV protocol is
&& myPosition = = UNICAST)
ModifiedGPSR_Forward (Packet); simulated and compared to the GPSR, GGSR, GGPSRII and
Else If (Packet.Destination_Position = = LBM protocols.
myPosition && myPosition = = GEOCAST){
If (Packet.seqNo_ < ReceivedSeqNo){ Simulations were performed on a largely used simulator for
Broadcast_Neighborhood_Geocast_Region(Packet) the academic area, the ns-2.33 [22]. Originally, in relation
;
} to routing algorithms, ns-2.33 only implemented the AODV
} algorithm. Hence, the authors implemented GPSR, LBM,
//Receive GGPSR and GGPSRII protocols. Configurations for
If (Packet.Destination_Position = = myPosition && simulating all routing protocols are presented in Table IV.
myPosition = = UNICAST)
ModifiedGPSR_Receive (Packet); Devices are equally distributed vertically and horizontally
Else If (Packet.Destination_Position = = along 50 meters to simulate lamp posts in a simplified way.
myPosition && myPosition = = GEOCAST){
If (Packet.seqNo_ < ReceivedSeqNo){ Figure 2 shows the location of the devices. Data always
ModifiedGPSR_Receive (Packet);
} flows from device 98 to all nodes on the “last line” (devices
} 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9). So, device 98 is the network
//Any Time coordinator. In addition, the ns2 oTcl code was
If Confirmation _Timer_Expire implemented to keep the energy of device 98 always as its
Send_Broadcast_Hello_Neighbors ();
initial energy.

Related to the “hello” packet, the field “type_” refers to the Table 4: Configurations for simulation
packet type (whether it is “hello” or data packet). The field Network Interface Phy/WirelessPhy/802_15_4
“x_” and “y_” are the source device geodesic coordinates. MAC Mac/802_15_4
The field “seqNo” is used to control the receiving and IFQ Queue/DropTail/PriQueue
rebroadcast actions, i. e., a device must have to broadcast Link Layer LL
just a once “hello” messages to its neighbours. Antena Antenna/OmniAntenna
Dimension X 170
Related to the data packet, the fields “sx_” and “sy_” are
Dimension Y 270
the source device geodesic coordinates. The field “ts_” is the
IFQLEN 50
timestamp, used for calculate latency. The fields
Propagation Propagation/TwoRayGround
“sx_GF_Failed” and “sy_GF_Failed_” correspond to the Phy/WirelessPhy Pt_ 7.214e-3 (100m)
coordinates where the greedy mode have failed, that are Number of Devices 100
used for the packet whether it can be return to that mode in Duration 1000 simulation time
case it is in the perimeter mode. The field “seqNo” is used Transmission Power 0.3 mW
for control the receiving and rebroadcast actions on the Reception Power 0.28 mW
geocast region. The rest of variables are the polygon Initial Energy 1 Joule
coordinates’. Packet size (less 64 bytes
header)
Table 3: GGPSR and GGPSRII header packets Flow CBR (Constant Bit Rate)
struct hdr_gpsr_hello {
u_int8_t type_;
float x_; Simulation foresees the basic operation situation: network
float y_; traffic is requested every twelve hours (assuming that the
int seqNo_;
}; unit of simulation is in hours), that is, switch the lights on
struct hdr_gpsr_data { and off for a street segment, for example.
u_int8_t type_;
u_int8_t mode_; GPSR and GGPSR “Hello” messages periodicity were
float sx_;
float sy_; configured to 12 hours, that is the time to send data.
float ts_; It is important to emphasize that in case of unicast
float sx_GF_Failed_;
float sy_GF_Failed_; algorithms, ten messages are sent from device 98 to all
float dst_x1; devices in the “last line”, as mentioned before. In case of
float dst_y1;
float dst_x2; geocast algorithms, only one message is sent to all
float dst_y2; addressees.
float dst_x3;
float dst_y3; Figure 3 shows a comparison of the electric power of all
float dst_x4; devices in the network summed during the time interval. It
float dst_y4;
int seqNo_; was verified that the AODV protocol is the least efficient,
}; and GGPSRII is the most efficient. It can be concluded that
the use of ZigBee protocol is strongly not recommended.
 (IJCNS) International Journal of Computer and Network Security, 69
Vol. 2, No. 4, April 2010

Figure 5. Delay average (performance)

Table V shows the packet header comparison. GGPSRII

presents lesser size of bytes then “LBM – request”, which is
the largest header in terms of bytes.

TABLE 5: Packet header Comparison

Figure 2. Simulated scenario
Packet Header Size (bytes)
AODV - request 28
Figure 4 shows the rate in percentage of throughput to each
AODV - response 26
evaluated protocol. For the AODV traffic, it was necessary AODV - error 14
to configure the beginning of the information flow in a non- AODV - confirmation 4
simultaneous way, with a short period of time between LBM - request 62
transmissions. If all messages were sent to the ten devices LBM - response 52
simultaneously, no message would be successfully received. LBM - error 14
The scheduling configuration was also applied to the GPSR LBM - confirmation 4
routing for comparison, even though GPSR does not need GPSR – hello 12
this artifice. GPSR - data 34
Observe that because of the AODV flooding characteristic, GGPSRII - hello 12
there is a very significant lost of messages that reassures GGPSRII - data 58
discredit on the ZigBee protocol. For this same reason, it
can be verified in Figure 5 that there is a delay average 7. Conclusions and future works
much higher than the AODV algorithm.
The proposed GGPSRII routing algorithm proved to be
efficient in terms of energy, and provides a good balance in
terms of performance and guarantee of delivery.
Quantitative results showed that the research has a solid
base, that is, resources can be invested in hardware
prototypes for devices (an alternative to ZigBee) and in
implementing the supervision and control software.
Later on, this algorithm will be implemented to transmit a
message to multiple areas, using the Fermat point concept
proposed by [23].
Final validation tests for the protocol will be simulated in
real scenarios obtained from lamp posts mapping, usually
archived in city halls.
The authors will also develop an alarm and network
diagnostic mechanism for the lighting system based on the
Figure 3. Comparing the network total energy
protocol of the proposed routing. Further on, application
layer services will be included to switch the lights, trigger
alarms, provide diagnostics, etc.

Figure 4. Delivery rate
Acknowledgment
The authors gratefully acknowledge the academic support
and research structure from the Engineering School of São
Carlos - University of São Paulo. The authors also
acknowledge the important technical contributions from
Smar International Corporation and the Prof. Tracy Camp
for helping in provide an implementation of LBM
algorithm, which was very helpful for an implementation of
the LBM implementation of this work.
70 (IJCNS) International Journal of Computer and Network Security,
References
[1] Reluz Program (Jan. 2010). “National Program of
Efficient Public Lighting and Traffic Lights”. Available:
http://www.eletrobras.gov.br/ EM_Programas_Reluz
[2] Ei-Shirbeeny, E.H.T.; Bakka, M.E.. “Experimental
pilot project for automating street lighting system in Abu
Dhabi using powerline communication”. Proceedings of
the 10th IEEE International Conference on Electronics,
Circuits and Systems. Vol. 2, p.743 – 746, Dec. 2003
[3] Chueiri, I.J.; Bianchim, C.G. “Sistema de Comando e
Controle de Potência em Grupo para Iluminação
Pública”. BR n.PI0201334-7, 2002.
[4] Sungkwan C.; Dhingra, V. “Street lighting control
based on LonWorks power line communication Power
Line Communications and Its Applications”. IEEE
Symposium, 2008.
[5] Sutterlin, P.; Downey, W. (1999). “A power line
communication tutorial – challenges and technologies”,
Technical Report, Echelon Corporation, 1999.
[6] Streetlight Intelligence (Jan. 2010). Available:
http://www.streetlightiq.com
[7] Barriquello, C.H. ; Garcia, J.M. ; Corrêa, C. ; Menezes,
C.V. ; Campos, A. ; Do Prado, R.N. “Sistema Inteligente
Baseado em Zigbee para Iluminação Pública com
Lâmpadas de LEDS”. In: XVII Congresso Brasileiro de
Automática. Anais do XVII CBA. Juiz de Fora, 2008.
[8] Zigbee. ZigBee PRO Specification, ZigBee Alliance.
2007.
[9] Denardin, G.W.; Barriquello, C.H.; Campos, A. Do
Prado, R.N. “An Intelligent System for Street Lighting
Monitoring and Control”. 10° Congresso Brasileiro de
Eletrônica de Potência. Brasil, Bonito, 2009.
[10] Kushalnagar, N.; Montenegro, G.; Schumacher, C..
“IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs): Overview, Assumptions, Problem
Statement, and Goals”. Request for Comments: 4919,
2007.
[11] IEEE 802.15.4. “Wireless Medium Access Control
(MAC) and Physical Layer (PHY) Specifications for Low-
Rate Wireless Personal Area Networks”, IEEE Computer
Society, 2006.
[12] Perkins, C. E.; Belding-Royer, E. M.; Das, S. R.. “Ad
Hoc On-Demand Distance Vector Routing”, Request for
Comments: 3561, 2003.
[13] Basagni, S.; Chlamtac, I.; Syrotiuk, V.R.; Woodward,
B.A. “A distance routing effect algorithm for mobility
(dream)”. In Proceedings of ACM/IEEE MobiCom ’98,
1998.
[14] Perkins, C.; Bhagwat, P. “Highly Dynamic Destination
Sequenced Distance-Vector Routing for Mobile
Computers”. Comp. Commun. 1994.
[15] Clausen, T.; Jacquet, P. “Optimized Link State
Routing Protocol”. Request for Comments: 3626, 2003.
[16] Finn, G.G. “Routing and addressing problems in large
metropolitan scale internetworks”. Technical Report
ISI/RR-87-180, ISI, 1987.
[17] Bose, P.; Morin, P., Stojmenovic, I.; Urrutia,
J.”Routing with guaranteed delivery in ad hoc wireless
networks”. In: Proceedings of the 3rd International
Workshop on Discrete algorithms and methods for mobile
Vol. 2, No. 4, April 2010
computing and communications. 1999, ACM Press.
[18] Leong, B.; Mitra, S.; Liskov. B. “Path vector face
routing: Geographic routing with local face information”.
In Proceedings of the IEEE Conference on Network
Protocols, 2005.
[19] Karp, B; Kung, H. T. (2000) GPSR: greedy perimeter
stateless routing for wireless networks. in Proceedings of
the 6th ACM/IEEE MobiCom. 2000, pp. 243-254, ACM
Press.
[20] Kuhn,F.;Wattenhofer,R.;Zhang,Y.;Zollinger, A.
“Geometric ad-hoc routing: of theory and practice”. in
Proceedings of the 22nd annual symposium on principles
of distributed computing, 2003.
[21] Ko, Y.; Vaidya, N.H.”Geocasting in mobile ahoc
networks: Location-based multicast algnrithms” .In
Proceedings of WMCSA, pages 101-110, 1999.
[22] Network Simulator NS2 (Jan. 2010). Available:
http://www.isi.edu/nsnam/ns
[23] Lee,S.;Ko,Y. “Geometry-driven Scheme for Geocast
Routing in Mobile Ad Hoc Networks”. The 2006 IEEE
63rd Vehicular Technology Conference (VTC),
Melbourne, Australia, 2006.
Authors Profile
Rodrigo Palucci Pantoni R&D Systems
Analyst, received the Computer Science
degree in 2000 and subsequently received
the M.S. in 2006 at the University of São
Paulo (USP). He's attending the Ph.D
course, in the same university, as part of his
job at the Smar R&D department in the area
of software development for automation
control and fieldbuses. He joined Smar in
2000, working
in the Smar R&D department where he conducts research and
development of host systems, including a Fieldbus Foundation
Asset Management and a Configurator system. He now teaches
computer networks at Information Systems course at University
Dr. Francisco Maeda.
Dennis Brandão He received his Ph.D.
degree in mechanical engineering at the
University of São Paulo in 2005. He now
teaches “Industrial Automation” at the
Department of Electrical Engineering of the
same university. His research activities are
mainly in the area of fieldbus technology
and application, with a particular interest for
distributed systems and continuous process
control.