implementation of a network of mobile sensors for air...
TRANSCRIPT
Implementation of a Network of Mobile Sensors for AirQuality Monitoring
Fábio GameiroInstitute for Systems and Robotics
Instituto Superior TécnicoTechnical University of Lisbon (UTL), Portugal
João GomesInstitute for Systems and Robotics
Instituto Superior TécnicoTechnical University of Lisbon (UTL), Portugal
ABSTRACTAir quality is one of the crucial parameters affecting the per-ceived quality of life, particularly in urban centers, and itis increasingly becoming a concern for public health officialsand the citizens themselves. Currently, air-quality monitor-ing in cities is done mostly through measurement stationslocated at a small number of fixed data collection points.The use of mobile monitoring stations integrated on a net-work of public buses creates the possibility of monitoring airquality at many more points in a city, thereby producing amore faithful picture of the spatial distribution of pollutants.One of the technical challenges that this type of monitoringraises is the communication between the atmospheric data-gathering stations and the central server that stores thatinformation in a database. This paper describes part of theinfrastructure that is being developed for such a mobile air-quality monitoring system in Lisbon, Portugal. We proposea communication structure based on mobile operator net-works to provide monitoring and configuring operations forthe measurement stations and a vehicular network based onWi-Fi ad-hoc communication between stations and a set ofInternet access points to provide a way for the atmosphericsamples reach the server. A web platform to view the sam-ples collected by the stations and provide remote monitoringand configuring operations is also described.
Categories and Subject DescriptorsC.2.1 [Computer-Communication Networks]: NetworkArchitecture and Design—wireless communication
KeywordsMobile Sensor Network, Vehicular Network, Machine ToMachine Communication, Atmospheric Monitoring
1. INTRODUCTIONAir quality is a subject of raising concern for public health
authorities and populations. The World Health Organiza-
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.HP-MOSys’12,October 25, 2012, Paphos, Cyprus.Copyright 2012 ACM 978-1-4503-1629-3/12/10 ...$15.00.
tion (WHO) estimates that 3.3 million deaths occur everyyear related to air pollution, both indoors and outdoors [?].Governments create legislation and policies aimed at reduc-ing air pollution levels, thus contributing to reduce the ex-penses related with public health and increase the quality oflife for its citizens. Air quality measuring systems are neededto assess the exposure of populations to airborne pollutantsand keep track of gains stemming from these policies.
The most common systems used for monitoring pollutantgases have large dimensions and are installed in fixed loca-tions, with special concentration in cities. In Lisbon, for ex-ample, the national environmental protection agency (APA)operates 6 fixed station within the urban perimeter, 3 ofwhich are located in areas of high traffic intensity, while 3others are more secluded and measure background levels ofseveral airborne pollutants (including gases and particulatematter). A few comparable mobile measurement modulesare regularly deployed in Lisbon, but they have considerabledimensions (truck- or trailer-size) and cannot be operatedwhile in transit. Their large size and high installation andmaintenance costs are some of the main drawbacks of thesestations.
The ongoing URBISNET project aims to demonstratetechnologies for mobile collection of air-quality data in thecity of Lisbon, estimation of pollution fields, and creationof online air-quality maps. Small mobile stations equippedwith atmospheric sensors, and developed by the project team,are used for this propose. They have the ability to measurethe concentrations of several atmospheric gases (includingcarbon monoxide, nitrogen dioxide, and ozone), georeferencethe collected samples, and communicate them to a centralserver. These features make this system for atmosphericdata collection complementary to the fixed/transportablestations. The small form factor and wireless communica-tion capabilities of these mobile stations make it possible toinstall them in public buses and collect atmospheric datathroughout their daily runs, generating samples with higherspatial density when compared with fixed stations, and withmoderate operating costs. However, the quality of thosemeasurements will inevitably be lower, and only a small sub-set of relevant airborne pollutants will be monitored.
We present a solution for the communications infrastruc-ture based on General Packet Radio Service (GPRS) andWi-Fi (IEEE 802.11b/g), which has been devised and im-plemented in URBISNET to send samples to a central serverand also to support remote monitoring and configuring oper-ations. These communications can be thought of as Machineto Machine (M2M) communications [?], as there will be no
Figure 1: Interconnections between components ofthe URBISNET air-quality monitoring system.
human intervention during normal operation. Mobile op-erators charge for GPRS access to their networks, whetherbased on the volume of transmitted data or some kind ofmonthly fee, thus contributing to the operational costs ofURBISNET. To keep these costs at manageable levels evenwhen our network is scaled up after the pilot phase, we de-veloped a peer-to-peer multihop opportunistic communica-tion scheme between mobile stations, using their Wi-Fi in-terfaces, to convey the collected samples to a set of fixedInternet access points (gateways) installed in selected busstops throughout the city, which will then forward those tothe central server. Using Wi-Fi to send the samples doesnot invalidate the need for GPRS communications, as theimplemented monitoring and configuring operations requirethat a network connection with high availability and lowlatency exist between the central server and the mobile sta-tions. Our peer-to-peer (vehicular) network can’t satisfythis requirement, as it will be very sparse during the pi-lot phase, resulting in intermittent connectivity and largeend-to-end delays of up to several tens of minutes. Besidesaddressing communications-related aspects, this paper alsogives an overview of the server-side web interface that wedeveloped for carrying out remote monitoring and config-uring operations on mobile stations and to view the storedatmospheric samples on a map.
This document is organized as follows. Section 2 intro-duces the general architecture of URBISNET. Section 3 cov-ers the implementation and hardware choices for this work.Section 4 presents results for the tests that were conductedto evaluate the functionality and performance of the solu-tion. Finally, Section 5 summarizes the document and high-lights the main results.
2. ARCHITECTURE
2.1 OverviewThe implemented system is based on three main compo-
nents: Mobile stations, gateways and a central server. Eachcomponent has its own role in the system, described furtherahead, and they are connected as exemplified in Figure 1.
Mobile Stations (MS)The main goal of mobile stations is to acquire atmospheric
samples and send them to the central server. To accomplishthat, they are endowed with communication capabilities us-
Figure 2: Hardware diagram for a mobile station.
ing GPRS and Wi-Fi, location capabilities using a GlobalPositioning System (GPS) receiver, and atmospheric sensingcapabilities using carbon dioxide (CO
2), carbon monoxide
(CO), ozone (O3) and nitrogen dioxide (NO
2) sensors, as
well as temperature and relative humidity sensors [?]. Thehardware block diagram for one mobile station is shown inFigure 2.
Atmospheric samples can be regularly collected in time(e.g. once every minute) or in space (e.g. once every 500meters). For the latter mode, the Haversine formula is usedto compute distances between two points on the surface ofthe earth given their GPS coordinates [?]. Specifically, de-note by (lat1, lng1) the coordinates for the previous acquiredsample, and by (lat2, lng2) the GPS coordinates at the cur-rent location. Also, let ∆lat and ∆lng be the differencesbetween the two latitude and longitude values, respectively,and R be the radius of the earth (R = 6371 km). Thedistance d between the two points is then related to theirGPS coordinates through (2), where the Haversine functionis given by (3). Finally, d can be obtained using the inverseHaversine function or using the arcsin function, as in (4).
Γ = cos(lat1)× cos(lat2)× haversin(∆lng) (1)
haversin(d
R) = haversin(∆lat) + Γ (2)
haversin(δ) = sin2(δ
2) (3)
d = R× haversin−1(h) = 2R× arcsin(√h) (4)
For each acquired sample a record is created containingtime-stamp, GPS coordinates, mobile station unique iden-tifier, and the values from each sensor, as exemplified below.timestamp, station identifier, latitude, longitude,
CO2, CO, O3, NO2, temperature, humidity;
Gateways (GW)Gateways are simple and small desktop computers with
a single major goal: To receive data sent from mobile sta-tions, via their Wi-Fi interfaces, and route it to the cen-tral server. As mobile stations are mounted on buses, and
Figure 3: Gateway interactions with mobile stationsand the central server.
therefore have high mobility, the ideal locations for thesegateways are (busy) bus stops. Naturally, they require anInternet connection to communicate with the central server.Figure 3 illustrates how samples are routed from mobile sta-tions to the central server through gateways.
An analysis of the current network of public buses in Lis-bon, operated by “Carris”, revealed that six gateway nodesplaced strategically in some of busiest stops could directlyreach 73% of bus routes. Each route in the remaining 27%was found to partially overlap with at least one route fromthe previous group, making it likely that any single bus intransit will either come within range of a gateway, or willcross other buses that eventually will have direct gatewayconnectivity. This supported the design option for an oppor-tunistic communication model, further discussed in Section2.2.2, where buses merge their sample sets whenever theycross. In a large-scale deployment involving multiple buseson each route this should allow any sample to reach a gate-way in at most one hop1, and with acceptable latency (upto several tens of minutes) for the time scale of atmosphericdispersion phenomena. As fewer mobile stations (less than10) and gateways will be deployed during the pilot phase,routes will be selected such that every bus involved will havedirect gateway connectivity at least once in each run, thusbounding the maximum latency of atmospheric samples re-ceived at the central server.
Central Server (CS)The central server has three main purposes: Storing the
atmospheric samples, remote monitoring and configuring ofmobile stations, and providing a web interface (website) ca-pable of visualizing air-quality data. To offer these function-alities, the central server runs a database, a web server, andis connected to the Internet (see Figure 4). The website isstructured in three main sections: Visualize, Monitor andConfigure.
Visualize:.This section unveils a Google Map where the stored sam-
ples in the database are shown. Each sample is representedby an icon located on the sample coordinates and clickingon that icon will pop up a window with all the informationfrom that sample (all sensor values as well date and time ofgathering). It is possible to choose some visualization op-tions like showing only samples originated from a specifiedmobile station and/or show only samples gathered betweentwo specified dates.
1Samples sent over multiple hops may actually be receivedat a gateway earlier than this. That situation is less likelythan direct or single-hop connectivity, but is in no way prob-lematic.
Figure 4: Central Server components and interac-tion with other agents.
Monitor:.Monitoring of mobile stations can be done in active or
passive mode. In passive mode the server displays a tableshowing the last activity reported by each known mobile sta-tion. It uses the time-stamp in the received samples, as wellas the GPRS IP address information messages sent by themobile stations. In active monitoring mode mobile stationscan be remotely queried for their list of configuration pa-rameters and other statistics, or the for the last log entriessaved locally.
It is also possible to passively monitor the activity of gate-ways. To enable this, each gateway periodically sends an“I’m Alive” message to the central server that includes therepetition period. In the website it is possible to see whenthe last such message was received from each gateway, andknow when the next one is expected. If the next message isnot received by then, the gateway is marked as “offline”.
Configure:.In a highly mobile environment the ability to remotely
configure mobile stations is very useful. In the URBISNETwebsite it is possible to do so, choosing from three types ofconfiguration: Change a station’s configuration parameters,send a new version of the operating software (or any otherkind of file), or reboot the station. All these operationscan be applied to multiple selected stations at once using aparallel communication scheme. Configuration parametersinclude the sampling interval (sampling period or distancebetween samples), transmit mode used to convey samples tothe server (Wi-Fi or GPRS), or transmit buffer size, amongothers. Received files are checked against their MD5 hashto ensure integrity.
2.2 CommunicationsCommunications based on GPRS and Wi-Fi are used for
different purposes in URBISNET.
2.2.1 GPRSThe main need for GPRS communications is to support
remote monitoring and configuration of mobile stations from
the central server, as this operation requires a stable con-nection with low latency. One challenge during implemen-tation was the need to have a public IP address for a mo-bile station when using GPRS, so that the server couldreach it for monitoring or configuring proposes. The IPaddress can be fixed or dynamically assigned [?], depend-ing on which Access Point Name (APN) and credentials areused when creating the GPRS connection. The most com-mon policy of mobile operators is to dynamically assign IPaddresses, which could have local meaning (private IP ad-dress) or global meaning (public IP), depending on the op-erator or even for different APNs inside the same operatornetwork. Using Vodafone Portugal Internet APN we wereable to obtain global IP addresses, dynamically assigned toeach station upon demand. Every time a station initializes,it also starts its GPRS connection and sends its IP addressto the central server via HTTP POST, which can then per-form monitoring and configuring operations for that station.The GPRS connection can also be used to send atmosphericsamples to the central server (also using HTTP POST), butthe Wi-Fi connection is preferable for that purpose to reducetraffic costs associated with GPRS. The logical topology ofGPRS communication is a star topology since the centralserver can directly address each mobile station and eachmobile station can reach the central server.
2.2.2 Wi-FiTo support the routing of samples to their final destina-
tion (the central server), a Wi-Fi communication protocolwas developed for mobile stations to communicate with eachother and with gateways. Some relevant characteristics wereidentified that helped to develop and define the communi-cation protocol:
• High mobility of mobile stations with periodic routes(preassigned bus routes);
• Very sparse network;
• Very limited connectivity between mobile nodes, avail-able only locally when buses cross or drive close to eachother;
• Gateway nodes placed on some of the busiest bus stops;
• The information routed on this network has only onedestination, the central server;
These features led to the development of an ad-hoc net-work that can be classified as a Vehicular ad-hoc network(VANET) [?] since mobile stations will be placed on buses.As the network is very sparse, the communication protocolis opportunistic and routing is based on a “store and for-ward” model that has similiarities with dissemination rout-ing [?]. The basic unit of information exchanged betweennodes in this protocol is a sample, and multiple samples canbe exchanged simultaneously. A record is created for eachsample (payload) containing associated parameters: ID oforiginating station (MS_ID), time to live (TTL), payload sizein bytes (payload_size), and the payload itself (payload).The structure sent is organized as follows:[MS_ID]#[TTL]#[payload_size]#[payload]#
In addition to these parameters, sent alongside each sam-ple, there is a parameter called max_times_sent that con-trols the maximum number of times that each sample is
Figure 5: Example of “store and forward” data dis-semination.
Figure 6: Broadcast message from a gateway.
sent to other nodes before being discarded. This parameterwas introduced to avoid discarding samples after forwardingthem only once, thus making them less volatile and morelikely to reach a gateway node. Making an analogy with atree data structure, the dissemination of data in this pro-tocol is controlled by max_times_sent and TTL, where theformer controls the number of child nodes that each nodehas, while the latter defines the depth of the tree. An ex-ample is given in Figure 5.
A node announces itself to surrounding nodes by period-ically broadcasting a message containing its identificationand type of node. The type of node can assume one oftwo values, ”gw” for gateway nodes and ”node1” for mo-bile stations. Figure 6 represents an example of a broadcastmessage.
Two mobile stations exchange data after each has receivedthe broadcast message sent by its counterpart (Figure 7).The station with lower ID first transmits its samples, fol-lowed by the station with higher ID (thereby implicitly ac-knowledging the first transmission). Samples are never sentback to its originating station, and samples whose TTLreaches 1 or are forwarded max_times_sent are discarded.After a station successfully exchanges data, it inserts thecounterpart station ID and IP address into an exclusionhost_list with a time-stamp that defines the end of theexclusion interval during which communication with thatstation is inhibited. This mechanism avoids repeated ex-changes between two nearby mobile stations, which other-wise would eventually reach max_times_sent and lead tothe samples being inadvertently discarded after insufficientdissemination.
Communications between a mobile station and a gateway,
Figure 7: Communication diagram between two mo-bile stations.
Figure 8: Communication diagram between a mobilestation and gateway.
represented in Figure 8, are simpler. Upon detecting thegateway’s broadcast message, a mobile station sends all itssamples and deletes them after receiving an acknowledge-ment from the gateway. It is assumed that the gatewaywill always succeed in forwarding the samples to the centralserver, so no further handshaking is required.
3. IMPLEMENTATION
Mobile StationsThe mobile station hardware, depicted in Figure 2, in-
cludes an embedded system C10/3 AarLogic from Round-Solutions. Its main module is the GE863-PRO3 from Telit,which combines an ARM-based processing unit with GSM/GPRScommunications.
Processor Atmel ARM9 200 MIPS 180MHzRAM 64 MBROM 4 MBMemory Extension SD and MMC CardsGPS AarLogic GPS 3M (SiRF 3/LP)SIM Card SIM Card HolderGSM/GPRS Integrated in the GE863-PRO3Operative System LinuxConnections GSM/GPRS and GPS antennas
Table 1: C10/3 RoundSolutions’ AarLogic modulecharacteristics.
Another key component in the mobile station is the AsusWL-330gE access point, which works as bridge between theEthernet and Wi-Fi interfaces. A version of OpenWRT wasinstalled on that component for easier replication of config-uration and also for remote configuration using SSH.
Software development for mobile stations was mostly donein C, using the Eclipse IDE with plug-ins from Telit as a
Figure 9: Gateway based on Asus EeeBox EB1007
cross-compiling platform. GSM/GPRS libraries from Telitwere also used, and complemented by direct interaction withthe GPRS modem using Attention (AT) commands for someof the more specialized functionalities. Data for georeferenc-ing of samples was read from the serial interface of the GPSmodule in raw NMEA-0183 format and parsed to obtain thegeographical coordinates and time-stamp. Latitude and lon-gitude were converted to decimal degrees to simplify storageand computation of distances according to (1)–(4).
GatewaysThe following requirements were identified for gateways:
• Small dimensions: For easy deployment on bus stops;
• Wifi 802.11 b/g interface: To communicate with mo-bile station nodes;
• LAN Interface: To connect to the Internet;
• Linux-enabled: Free and open source system that mayrun a ported version of the Wi-Fi protocol used inmobile stations.
The hardware selected for the gateway was the Asus desk-top EEEBox EB1007 (Figure 9), which provides a versatile,moderate-cost, and self-hosting platform that is very usefulfor the pilot phase of this project. However, gateways basedon Wi-Fi access points running OpenWRT or DDWRT mayprove more convenient once the communication protocolsbecome stable, as they have lower cost, are more compact,and the burden of cross compilation becomes negligible.
EeeBox EB1007Processor Intel Atom D410 1.66 GHzMemory 1GB DDR2 800 MHzHard Drive SATA 2.5" 160 GBLAN 10/100/1000MbpsWi-Fi WLAN 802.11b/g/n @2.4GHzVideo VGADimensions 223mm x 178mm x 27mmPrice 200e
Table 2: EeeBox EB1007 main specs
As in mobile stations, most of the software developmentwas done in C using the Eclipse IDE. The gateway is con-figured for unattended startup whenever power is available.The startup routines configure both the LAN and Wi-Fi
interfaces and also start the main program. The main pro-gram implements the Wi-Fi peer-to-peer exchange protocoldescribed in Section 2.2, sends the received samples to thecentral server, and also periodically sends “I’m Alive” mes-sages for passive monitoring of the status of gateways at theURBISNET website (Section 2.1).
Central ServerAs discussed in Section 2.1, the main required components
for the central server are the web server and database. Thefollowing additional requirements were identified:
• Free and open source software;
• Registered web domain: To access the URBISNETwebsite from the web;
• Fixed IP address: Mobile stations use a GPRS connec-tion firewall in drop mode to avoid receiving unwantedconnections. The IP address is used to white list thecentral server.
A MySQL database was used to create three tables: Onefor sensor samples, one for mobile stations data, and anotherone for gateways data. As for sensor samples data, the tableprimary keys are the temporal time-stamp and the mobilestation ID. This automatically avoids data replication in thedatabase when multiple copies of each sample are receivedat the server as a result of the epidemic-like routing pro-tocol adopted for URBISNET in Wi-Fi mode. Databaseoperations are relatively simple, using INSERT instructionsto store data (DELETE instructions if needed to avoid dataduplication) and SELECT queries to retrieve data for theURBISNET website.
The URBISNET website is hosted in an Apache HTTPserver and it was created mainly using HTML and CSS forthe visual interface, and PHP and JavaScript for the logicalbackbone.
To provide an efficient and simple way to view stored sam-ples, Google Maps is used in the visualization part of thewebsite. Samples are submitted to the server by mobile sta-tions or gateways using HTTP POST messages, and parsedat server by a PHP script that stores the information inMySQL tables as appropriate. More sophisticated utilitiesfor visualization of pollution maps are currently under de-velopment.
4. TESTING AND EVALUATIONTwo sets of tests were conducted in order to validate the
various components in the system. Firstly, web-based re-mote monitoring, configuration, and reprogramming/rebootingof mobile stations were tested under static conditions usingGPRS communications2 (Figure 10). All these tests, as wellas passive monitoring of gateways, were successful; furtherdetails may be found in [?]. Field tests were then conductedusing mobile stations placed inside cars to evaluate the com-munications performance in the presence of mobility.
4.1 Sample Gathering in a Mobile Environ-ment
The main objectives of this field test were to (i) validatethe sample gathering process with a sample being collected
2Results are likely to be similar with moving stations dueto the robustness of GPRS to mobility.
Figure 10: Test configuration for server-side func-tionality testing.
Figure 11: Vehicle route and gateway position forthe data collection field test.
every 100 meters, (ii) test Wi-Fi communication betweenone station and a gateway, and finally (iii) test the visual-ization of collected samples in the URBISNET website.
For this test a mobile station was mounted on a car’sdashboard, which followed a predefined route (Figure 11)to collect samples and then passed near a gateway node toconvey those samples. The test was conducted outside theIST-Taguspark building. The gateway was installed outsidean office window in the building to provide a direct viewof the test site and take advantage of an existing Internetconnection.
After the conclusion of the test it was possible to use theURBISNET website to visualize the collected samples (Fig-ure 12). As revealed by the correct reconstruction of thevehicle trajectory in the website, all the objectives for thistest were met.
Comparing the station’s communication log with the gath-ered samples’ time-stamps and coordinates stored in thecentral database it was possible to conclude that the firstsuccessful communication between the mobile station andthe gateway occurred approximately at 140 meters distance(with line of sight communication). This result is consideredvery good since the gateway is meant to be placed in busstops, and in this test the mobile station could communicatewith it at a much longer distance than needed, and while thevehicle was still moving.
4.2 Wi-Fi Communication PerformanceThe objectives of this field test were to evaluate the perfor-
mance of Wi-Fi communications between two mobile station
Figure 12: Visualizing the gathered samples in theURBISNET website after the data collection fieldtest.
Figure 13: Mobile stations’ routes and gateway po-sition for the Wi-Fi communications field test.
nodes in various scenarios. The test was performed with dif-ferent configurations such as different number of samples ex-changed between stations (5, 20 or 40 samples), and differentspeeds (20 and 40 km/h). Four scenarios were considered:Small load (5 samples) at 20 km/h, average load (20 sam-ples) at 20 km/h, large load (40 samples) at 20 km/h, andaverage load at 40 km/h. After an initial exchange betweentwo mobile stations, one of them later comes within rangeof the gateway and conveys both stations’ samples. Per-formance was assessed with respect to latency through theRound Trip Time (RTT) of the samples sent between mobilestations and between one of the stations and the gateway.
This test uses two mobile stations (MS1 and MS2) anda gateway (GW). Similarly to the previous test, the mo-bile stations were placed inside cars that followed predefinedroutes near the building of the IST-Taguspark (Figure 13).
For each scenario described above 6 trials were conducted.The results are shown in Table 3. The registered values forRTT are satisfactory, and should be amply sufficient to com-plete all handshaking and (re)transmission of realistic sam-ple blocks while two stations remain within communicationrange. The fact that the error rate on the first transmissionattempt is significant for the first three lines of Table 3 high-lights the need for adequate positioning of nodes on vehicles;in those trials one of the mobile stations was placed on one of
the car seats, not on the dashboard, hence there was no lineof sight between stations. That station was moved to thedashboard for the last trial reported in the table, leadingto a clear improvement in communications reliability thatshould carry over to the planned rooftop mounting of sta-tions on urban buses. Even with favorable antenna configu-rations these results suggest that Wi-Fi transmissions mightfail relatively often, and it is therefore necessary to have inplace a handshaking and retransmission protocol that willensure reliable delivery of data blocks during pairwise ex-changes. This might be accomplished by using the TCPprotocol, but the associated transmission overhead to reg-ulate flow/congestion in the connection is hardly justifiablefor the intended application. A better-suited option mightbe to add a lightweight data link protocol on top of UDP toacknowledge correct reception of packets and manage repe-titions whenever needed.
5. CONCLUSIONThis paper describes the functionalities and communica-
tions infrastructure of a vehicular data collection networkthat supports an air-quality monitoring system for Lisbon,Portugal, that is being developed under project URBISNET.The URBISNET website is part of that solution and al-lows users to visualize the gathered samples, while provid-ing monitoring and configuring operations for mobile sta-tion nodes. GPRS communications were implemented inthe mobile stations for direct interaction with the centralserver, and complemented by a Wi-Fi ad-hoc protocol thatprovides a cost-effective solution to convey samples to theserver through multihop peer-to-peer exchanges.
The high-level functionality based on GPRS for monitor-ing, configuring, and reprogramming mobile stations fromthe central server through a web interface was fully imple-mented and successfully tested. Field testing of the vehic-ular network highlighted the importance of ensuring a widefield of view for Wi-Fi antennas, as would be the case in theenvisaged rooftop installation of mobile stations on urbanbuses. Wi-Fi ranges were found to be on the order of 100meters, ensuring that crossing buses at normal speeds havean ample temporal window for sharing data that can easilyencompass the typical volumes of data involved in pairwiseexchanges between mobile stations (or mobile stations andgateways). Under line of sight conditions the error rates forWi-Fi transmission should be sufficiently small for a sim-ple handshaking protocol on top of UDP to provide reliabletransmission through acknowledgement/retransmission.
6. ACKNOWLEDGMENTSThis research was partially supported by Fundação para a
Ciência e a Tecnologia (FCT) through projects PEst-OE/EEI/LA0009/2011 and PTDC/EEA-CRO/104243/2008.
Data Velocity Mean RTT between Mean RTT between Success rateload stations (MS1 and MS2) station MS2 and gateway (1st attempt)small 20 km/h 440.8 ms 380.6 ms 83%
average 20 km/h 586.75 ms 338.75 ms 67%large 20 km/h 1083.8 ms 847.4 ms 83%
average 40 km/h 744 ms N/A 100%
Table 3: Summary of results for performance assessment of Wi-Fi communications.