ICT-MobileSummit 2009 Conference Proceedings Paul Cunningham and Miriam Cunningham (Eds) IIMC International Information Management Corporation, 2009 ISBN: 978-1-905824-12-0
Poster Paper
Opportunistic Networking for Sensor Data Collection in Urban Environment 2 2 ¨ ¨ ONEN ¨ Flavio FABBRI1 , Janne RIIHIJARVI , Roberto VERDONE1 , Petri MAH 1 WiLAB, CNIT, University of Bologna, V.le Risorgimento, 2, Bologna, I-40136, Italy Tel: +39 051 2093549, Fax: +39 051 93540, Email: {flavio.fabbri, roberto.verdone}@unibo.it 2 Department of Wireless Networks, RWTH Aachen University, Kackertstrasse 9, Aachen, D-52072, Germany Tel: +49 2407 575 7032, Fax: +49 2407 575 7050, Email:{jar, pma}@mobnets.rwth-aachen.de
Abstract: In this paper we present the preliminary results from a work dealing with opportunistic networking in urban context. In particular we consider a set of sensors deployed in a city center, aimed at sampling e.g. environmental parameters. Such sensors then opportunistically exploit the urban vehicular mobility to transfer their measurements to one of data fusion centers, located at chosen points in the city. Both the sensor nodes and the vehicles are equipped with radio transceivers having a fixed transmission range and data storage capability (which is assumed to be limited). Here we present simulations based study conducted in the particular case of the city of Seattle, WA, since we had access to the actual mobility traces of the city bus fleet, collected by [1]. Some of the performance metrics that can be evaluated in our simulator environment are the delivery rate of packets originated from each sensor node, the statistics of the transport delay and the fraction of packet drops due to limited storage buffer capability. We also highlight the role played by the number of sensors and fusion centers, and the effect of transmitting power. Possible extensions of this preliminary work include comparison to the results obtained when using (theoretical and measured) mobility traces. Keywords: Opportunistic Networks; Vehicular Networks; Delay Tolerant Networks.
1.
Introduction
Wireless sensor networks are a promising technology for environmental monitoring, offering potentially high spatial and temporal resolution by means of inexpensive networked embedded devices. Classically fixed gateways connected at all times to the sensor network have been used to gather measurement results and report them to the backend systems reachable through the Internet [2]. More recently especially in the context of wildlife monitoring mobility of the sensor nodes has been exploited to transmit data towards gateways [3]. In this paper we study the use of vehicles to carry measurement readings from a potentially disconnected collection of sensor nodes to gateways for further processing in an opportunistic manner. In particular, we discuss our work towards creating a simulation environment where the impact of sensor and gateway node deployment strategies and of vehicular mobility on the spatiotemporal resolution of the harvested sensor data can be easily evaluated. We focus on the use of realistic vehicular mobility patterns, our examples being based on measured traffic patterns of busses in the public transport system of Seattle. We believe that such a fleet of vehicles owned and administered by a single entity with highly predictable traffic patterns makes for a natural candidate in c The authors Copyright
www.ICT-MobileSummit.eu/2009
1 of 8
applying opportunistic communications for data harvesting in the real world. The rest of the paper is now structured as follows. In Section II we discuss some of the related work that can be found in the literature. In Section III we explain the design of our simulation environment, including the various data sources that can be integrated into the framework. We give a short overview of some initial results we have obtained in Section IV, before concluding the paper and outlining plans for future work in Section V.
2.
Related work
The use of opportunistic communication has recently attracted a lot of research interest, and it is beyond the scope of the present paper to give a comprehensive review of the various activities taking place in this domain. Instead, we shall point out some of the key references, and highlight the differences in our approach. Earlier work in opportunistic communication took place in the context of delay tolerant networking [4, 5, 6]. Substantial effort has been directed to design scalable and well-performing routing algorithms for networks that could suffer from frequent partitions and occasional disconnectedness, and very high transmission delays. Soon thereafter the focus on the store-carry-forward paradigm and opportunistic communication emerged [7, 8]. Recently the focus of the research work has been on evaluating the impact of mobility patterns on the performance of networks, especially in terms of delay, and on attempting to reduce the routing overhead [9, 10]. In most of the existing work, network is assumed to be homogeneous, meaning the data sources, sinks and forwarders behave in the same way. We on the other hand explicitly consider opportunistic communication in a more complex but realistic three-tier system with sensors originating the data, and only vehicles being responsible for carrying and forwarding the data into the fusion centers.
3.
Simulator Environment
The performance simulator that we have developed takes as an input a mobility trace description from an external file. In principle, any kind of data may be used, such as real life mobility patterns, traces generated by a synthetic model and outputs of micro-mobility simulator environments. After the preprocessing stage where data is read and conveniently sorted, variables are initialized. In the following, we report the description of the three main data structures employed in the simulator, while we assume its time resolution (which will be an input parameter in the future) is fixed to one minute. Sensor. Sensor nodes are modeled as data structures having the following fields: ID, which uniquely identifies the node, Position, Time2sens and Memory. The position field is automatically generated by the software according to a specific deployment pattern defined by the user (e.g., grid, uniform random, etc...). Time2sens is an internal time counter decremented every minute. Every time it reaches zero, the sensor is required to take a sample, generate a new data packet and store it into its buffer. The Memory field points to a buffer containing the generated packets. Each record has two properties, namely Size and OriginTime. The former is the packet size, while the latter is a time stamp of the instant when the packet was generated. The sensor node is assumed to be memory constrained even though in this preliminary stage we shall not use this c The authors Copyright
www.ICT-MobileSummit.eu/2009
2 of 8
functionality of the framework. Bus. The bus data structure contains the following fields: ID, routeID, Position and Memory. The field routeID identifies a particular route of the bus fleet: there might be several busses running on the same route as the same bus might be employed on different routes at different times. The Position field represents the current position of the bus and it is updated every minute. The Memory field points to a buffer containing the packets collected from the sensor encountered on the way. With respect to the memory of sensors, it contains two more properties: PickUpTime, a time stamp which keeps track of the instant when the packet was collected by the bus and OriginatingSensorID, the identification of the sensor node by which the packet was originated. Fusion. This data structure models the fusion center(s) where all the packets from all the busses shall be uploaded. Along with the ID and Position information, it features a buffer where all new packets are saved minute by minute and multiple copies are discarded. Each packet downloaded from the busses is further tagged with DeliveryTime and DeliveringBusID labels, which indicate the time the packet is delivered to the fusion center and from which bus, respectively. The main input data to be provided by the user to the simulator environment concerns the sensors deployment (i.e., number of sensors, domain area, distribution), the sensing rate (i.e., the rate at which sensors take samples and generate packets), the transmission range (i.e., the maximum distance at which packets can be exchanged among sensors, busses and fusion centers), the location and number of fusion centers and the duration of the simulation. After objects creation has been completed, mobility traces are read and the position of vehicles updated every minute. Every time a bus is in the vicinity of a sensor (i.e., its distance is less than the transmission range) whose buffer is non-empty, it downloads all its content into its memory. If other sensors are encountered, their packets are also stacked into memory. Finally, when the bus discovers a fusion center in its proximity it uploads everything and erases its memory. One important remark is that the same packet originated by a sensor can be collected by several busses and thus can reach the fusion center at different times. Even though this is desirable because there are better chances for a packet to reach its destination, multiple copies are generated. However, this event is easily recognizable by comparison of the OriginatingSensorID and OriginTime fields and the delayed copies of the original packets can be identified and discarded when they arrive at the fusion center. We first tested the simulator by using as input the mobility traces of Seattle bus fleet made available through Crawdad [1]. They come as a collection of several files, each one containing a list of mobility events recorded in a period of time ranging from 1 to 4 days. The measurements were taken in 2001. Each file is structured as a sequence of rows including the following fields: date-time, bus ID, route ID, position. The inter-event time is random and may range from less that one second to minutes. The preamble of the simulator code preprocesses the input data and sorts the event in time order. They are also grouped in blocks of one minute length and that implicitly sets the time resolution of the simulator to one minute. Finally, the main issue the user should be aware of, is the granularity of time events as reported in the trace files, which may limit the time resolution. As a consequence, when we set the transmission range, we need to make sure that the value is greater than the approximate distance a bus can travel in one minute. This choice will avoid those c The authors Copyright
www.ICT-MobileSummit.eu/2009
3 of 8
situations where the presence of a nearby bus is erroneously undetected by sensors.
4.
Numerical Results
In this section we present first results from the simulator work. We consider a reference scenario that is shown in Figure 1. We can observe sensors (represented by crosses) distributed on a regular grid and occupying a rectangular region approximately 30 Km× 36.5 Km wide located in downtown Seattle. Busses are represented as diamonds (points) when they have their buffer non-empty (empty). Moreover, different colors represent different bus routes. A fusion center (red square) is in charge of collecting data coming from the busses. We now show the results obtained from such a scenario when three different values of sensor density, ρ, are used. Other parameters given as input are the inter-sensing time, which is set to 15 min., the transmission range, set to approximately 1 km. The simulation is run for the period of two days (2880 min.). The Figure 1 reports the overall number of packets received by the fusion center for sensor deployment densities ρ = 0.013, 0.083, 0.250 km−2 . As expected, the increased sensor density leads to a greater number of received packets. However, a certain percentage of them are marked as copies and thus discarded. This occurs because some locations in the city (e.g., train station, etc. . . ) are reachable by a large number of busses. Therefore if a sensor is located there, each packet it generates will be collected (and possibly delivered) several times. In Figure 3 we show the delivery rate of only useful packets. On the x-axis the time of the day is reported and by observing all the three plots one can locate different periods of time where changes in slope occur. For instance, all the curves appear flat between approximately 2:30 and 5 a.m. At that time, indeed, bus service is suspended, so no delivery is possible. Conversely, 7 a.m. is the rush hour: the public transportation activity reaches its maximum and, as a consequence, the number of delivered packets increases dramatically. Finally, a minor evening rush can be seen between 5 and 6:30 p.m. In Figure 4 we consider the c.d.f of the overall and transport delay. The latter is the period of time between packet collection and delivery. With overall delay, instead, we mean the amount of time since packet origination (i.e., when sensor took its measurement) to delivery. Since the two curves are very tight, we can state that packets are in general collected right after they have been generated and that the critical delay comes from their transportation.
5.
Conclusions
In this paper we presented the first steps toward the construction of a reliable and realistic simulator environment for the study of opportunistic sensor networks where mobile entities are in charge of collecting samples and deliver them to gateways. The availability of actual mobility traces has made it possible to address the case study of Seattle public transportation and to test our simulator. A limited number of numerical results have been shown and discussed, and the role of sensor density highlighted. As future work, we intend to further investigate such a scenario by exploiting different sensor deployments, the presence of several fusion centers/gateways and by setting memory constraints on sensor nodes. Moreover, the same analysis will be conducted on c The authors Copyright
www.ICT-MobileSummit.eu/2009
4 of 8
time 11:58
gateway TR sensor w/empty buffer sensor w/non−empty buffer bus w/non−empty buffer bus w/empty buffer
15 km
Figure 1: A snapshot from the simulator environment. mobility traces obtained from a synthetic mathematical model (e.g. Random Waypoint) as well as on patterns output of a micro-mobility generator (such as VanetMobiSim [11]). Finally, we plan to use our framework for studying the impact of sensor deployment models and mobility patterns on the accuracy of various WSN applications, especially focussing on different flavors of environmental monitoring.
Acknowledgment This work was supported by the European Commission in the framework of the FP7 Network of Excellence in Wireless Communications NEWCOM++ (contract no. 216715).
References [1] J. G. Jetcheva, Y.-C. Hu, S. PalChaudhuri, A. K. Saha, and D. B. Johnson, “CRAWDAD data set rice /ad hoc city (v. 2003-09-11).” Downloaded from http://crawdad.cs.dartmouth.edu/rice/ad_hoc_city, Sept. 2003. [2] A. Mainwaring, D. Culler, J. Polastre, R. Szewczyk, and J. Anderson, “Wireless sensor networks for habitat monitoring,” in Proceedings of the 1st ACM international workshop on Wireless sensor networks and applications, pp. 88–97, ACM New York, NY, USA, 2002. c The authors Copyright
www.ICT-MobileSummit.eu/2009
5 of 8
12000 received packets useful packets 10000
no. of packets
8000
6000
4000
2000
0
0.013
0.083
0.250
ρ [Km−2]
Figure 2: Number of overall received packets and useful packets as functions of the density of sensor nodes. 2500
ρ = 0.083 Km−2 ρ = 0.013 Km−2 ρ = 0.250 Km−2
no. of delivered packets
2000
1500
1000
500
0 10:30
18:30
2:30
10:30 time
18:30
2:30
10:30
Figure 3: Number of delivered packets (only useful) as a function of time, for different values of sensor nodes density. [3] P. Zhang, C. Sadler, S. Lyon, and M. Martonosi, “Hardware design experiences in ZebraNet,” in Proceedings of the 2nd international conference on Embedded networked sensor systems, pp. 227–238, ACM New York, NY, USA, 2004.
c The authors Copyright
www.ICT-MobileSummit.eu/2009
6 of 8
1 0.9 0.8 ρ = 0.250 Km−2
0.7
CDF
0.6 ρ = 0.083 Km−2 0.5 0.4
ρ = 0.013 Km−2
0.3 0.2 0.1
overall delay transport delay
0 0
500
1000
1500 delay [min]
2000
2500
Figure 4: CDF of overall and transport delay in the three cases considered. [4] K. Fall, “A delay-tolerant network architecture for challenged internets,” in Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pp. 27–34, ACM Press New York, NY, USA, 2003. [5] M. Ho and K. Fall, “Poster: Delay tolerant networking for sensor networks,” in Proc. of IEEE Conference on Sensor and Ad Hoc Communications and Networks, 2004. [6] K. Harras, K. Almeroth, and E. Belding-Royer, “Delay tolerant mobile networks (dtmns): Controlled flooding in sparse mobile networks,” in IFIP Networking, Springer, 2005. [7] Z. Jing and G. Cao, “VADD: Vehicle-Assisted Data Delivery in Vehicular Ad Hoc Networks,” in Proc. of INFOCOM, pp. 1–12, April 2006. [8] P. Hui, A. Chaintreau, J. Scott, R. Gass, J. Crowcroft, and C. Diot, “Pocket switched networks and human mobility in conference environments,” in Proceedings of the 2005 ACM SIGCOMM workshop on Delay-tolerant networking, pp. 244–251, ACM New York, NY, USA, 2005. [9] R. Ramanathan, R. Hansen, P. Basu, R. Rosales-Hain, and R. Krishnan, “Prioritized epidemic routing for opportunistic networks,” in MobiOpp ’07: Proceedings of the 1st international MobiSys workshop on Mobile opportunistic networking, (New York, NY, USA), pp. 62–66, ACM, 2007. [10] A. Chaintreau, P. Hui, J. Crowcroft, C. Diot, R. Gass, and J. Scott, “Impact of Human Mobility on Opportunistic Forwarding Algorithms,” IEEE TRANSACTIONS ON MOBILE COMPUTING, pp. 606–620, 2007. c The authors Copyright
www.ICT-MobileSummit.eu/2009
7 of 8
[11] J. H¨arri, F. Filali, C. Bonnet, and M. Fiore, “Vanetmobisim: generating realistic mobility patterns for vanets,” in VANET ’06: Proceedings of the 3rd international workshop on Vehicular ad hoc networks, (New York, NY, USA), pp. 96–97, ACM, 2006.
c The authors Copyright
www.ICT-MobileSummit.eu/2009
8 of 8
