2007 Calabrese Colonna Lovisolo Parata Ratti Senselab

This paper might be a pre-copy-editing or a post-print author-produced .pdf of an article accepted for publication. For the definitive publisher-authenticated version, please refer directly to publishing house’s archive system.

keywords Intelligent transportation system (ITS), location-based services (LBS), wireless locationing, cellphone network, GSM, GPS, real time control systems

Real-Time Urban Monitoring Using Cellular Phones: a Case-Study in Rome

Francesco CalabreseMassimo ColonnaPiero LovisoloDario ParataCarlo Ratti

SENSEable Working Paper, 2007

© SENSEable City, 2007

1

Real-Time Urban Monitoring Using Cellular Phones: a Case-Study in Rome

Francesco Calabrese (1), Massimo Colonna (2), Piero Lovisolo (2), Dario Parata (2), Carlo Ratti (1) (1) SENSEable City Laboratory, Massachusetts Institute of Technology, Cambridge, MA, USA

(2) TILAB, Telecom Italia, Turin, Italy

Address for correspondence:

Francesco Calabrese, SENSEable City Laboratory, Massachusetts Institute of Technology, 77,

Massachusetts Avenue, Cambridge, MA, 02139, USA, e-mail: [email protected]

Abstract — This paper reports on the Real Time Rome project, exhibited at the 10th International Architecture Exhibition of the Venice Biennale during Fall 2006. The project used the LocHNESs platform developed by Telecom Italia for the real time evaluation of urban dynamics based on the anonymous monitoring of cellphone networks. In addition, data were supplemented based on the instantaneous locationing of buses and taxis using GPS. All data were then processed and updated to provide information about urban mobility in real time, from the condition of vehicular traffic to the movements of pedestrians and foreigners in the city. For the first time a large urban area, which covered most of the city of Rome, was monitored in real time using a variety of sensing systems - hopefully opening the way to a new paradigm to understand and optimize urban dynamics.

Index Terms — Intelligent transportation system (ITS), location-based services (LBS), wireless locationing, cellphone network, GSM, GPS, real time control systems.

1. Introduction Intelligent Transportation Systems (ITS) are transportation systems which use Information and

Communication Technologies (ICT) to address and alleviate transportation and congestion problems. In

general, an ITS relies on location-based information: it monitors the location of a certain number of

vehicles (used as probes) and processes it in order to obtain traffic information such as travel time

estimation, congestion or incident situations, etc. Using a relatively large amount of probes, the early

stages of bottlenecks can be detected early and traffic can be directed to other routes to mitigate

congestion and to provide faster and more efficient itineraries for travellers.

Various kinds of sensors can be used to obtain traffic information. Traditionally, two main

categories have been identified: fixed sensors on the road and GPS receivers located in vehicles.

Fixed sensors on the road provide information about vehicles’ speed and road capacity.

Moreover, they can provide additional information such as vehicles’ category, distance between



2

vehicles, pollution condition (in a direct or indirect manner), pavement deterioration, etc. They can be

placed under the road (inductive, piezoelectric, magnetic) or beside it (radar, ultrasound, infrared with

pyroelectric effect, video camera) and they are equipped with sensors, control unit, battery system,

solar panel, transmission system. Unfortunately, they provide just punctual information about traffic

condition. It is then necessary to install a large amount of them in order to have a realistic view of the

automobile traffic in a certain area. For these reasons, fixed sensors systems are most appropriate for

the monitoring of highways.

GPS receivers located in vehicles transmit with a certain frequency the vehicle’s actual location,

its speed (and eventually the sequence of the last locations and the covered distance from the previous

transmission to the actual one) to a central system. Units are composed of a GPS receiver, a control

unit and a transmission system (based on text messages and/or data packets transmission). If the

number of vehicles in a specific area is quite high, a processing algorithm in the central system can

provide a very good estimation of automobile traffic.

Both systems described above have limitations. Fixed sensors are expensive to install and

provide only localised information. GPS receivers can theoretically provide better data, but in practice

they also pose problems, such as the following: a good percentage of vehicles should carry GPS devices

if enough sensing capability needs to be present in each street; mass deployment can easily become

very expensive; transmission cost to the central system can become onerous if frequency is high; GPS

systems do not work well in urban areas, because of signal multipath and urban canyon obstructions;

finally, careful contractual work is needed because of privacy legislation, as vehicle’s owners must

explicitly agree to share their location for automobile traffic estimation purpose.

All of the above problems have so far limited the implementation of good monitoring systems,

especially in wide urban areas, composed of many streets. New approaches have emerged in the past

years based on the use of data obtained from cellphone networks. Cellphone positioning techniques

generally provides less accuracy than GPS, but the wide diffusion of mobile equipments (ME) and a

widespread installation of radio transmitters, or base transceiver stations (BTS), both in urban and in

rural areas, makes such positioning techniques very interesting. ME location data can flow in large

numbers; opportunely aggregated and processed, it can effectively be used to identify driving

behaviours, locations of congestions and so on, even in areas where other measuring devices have

problems.

Some projects regarding feasibility and field-tests of ME location-based ITSs have been

developed in Europe (e.g. France [1], UK [2] and Finland [3]) and North America (e.g. California [4],

Washington, D.C. [5], Virginia, [6]-[7] and Maryland [8]). Commercial applications are also starting to

be developed by companies such as the British ITIS Holdings [9], the Canadian Delcan [10], the

americans AirSage [11] and IntelliOne Technologies [12]. Most projects, however, have focussed and

proven the feasibility of a ME location-based monitoring system along highways, where the



3

implementation is simpler because of well-defined traffic patterns. The error in location becomes less

important when traffic is constrained by the highway network; even very simple location systems based

on the position of the closest cell (so-called cell-ID locationing) can be used.

In this paper we present the Real Time Rome project, which aims to extend ME location-based

monitoring to a whole city – in this case Rome, Italy. Developed by the MIT SENSEable City Laboratory

for the 10th International Architecture Exhibition of the Venice Biennale in collaboration with the

Italian cellphone carrier Telecom Italia, the project aims to create an integrated approach to urban

monitoring. In particular:

• It uses high resolution and high definition data over extensive urban areas, whose collection has been

made possible by Telecom Italia’s innovative LocHNESs (Localizing & Handling Network Event Systems)

software platform;

• It monitors very large portion of the city of Rome over a very complex street network;

• It integrates the cellular phone data with other type of real time information, such as the position of

taxis and buses.

The initial aim of the project was to make a proof of concept for the Venice Biennale and as

such focussed more on artistic visualization than on the use of this information in real time in the city.

However, this integrated approach seems to open a new way to monitor urban traffic in real time and,

more generally, to develop a real-time control system for cities.

The paper is organized as follows. In section II we describe the LocHNESs platform developed by

Telecom Italia and the data it provides. The other locational data acquired for the Real Time Rome

project are described in Section III, whereas Section IV describes the Real Time Rome system

architecture. Section V provides a detailed description of the developed processing and visual software

and Section VI gives some conclusions.

2. Locational Data from the Telecom Italia Platform

2.1. LocHNESs platform LocHNESs (Localizing & Handling Network Event Systems) is a software platform developed by

Telecom Italia for the evaluation of statistics, such as real time road traffic estimation, based on the

anonymous monitoring of the ME movements. The functional elements that constitute the LocHNESs are

presented in Fig. 1 and will be described in more detail in the following paragraphs.

The LocHNESs platform is based on the localization of events that occur on the mobile network

(call in progress, SMS sending, handover, etc.) thanks to the use of external probes. These probes are

installed on the Abis interfaces, i.e. the interfaces that link the BTS to the Base Station Controller

(BSC). These probes analyze all the signalling messages and send a notification of the detected events.



4

The key data detected by LocHNESs through the Abis interface are MEASurement RESult [13]

messages, which are used to report the results of radio channel measurements made by the BTS (uplink

measurements) and the measurement reports received by the BTS from the ME (downlink

measurements)1 to the BSC. The MEASurement RESult message contains GSM parameters such as the

average signal quality (RXQUAL) as measured by both ME and BTS, the received signal strength (RXLEV)

as measured by the BTS (uplink measurement), the received signal strength on the serving BTS and on

the neighbouring BTSs as measured by the ME (downlink measurement) and the actual Timing Advance

(TA). The MEASurement RESult message related to each active connection (ME in the state “connected”)

is sent to the BSC every 480 ms, allowing LocHNESs to determine the complete trajectory of the call

with the same time resolution. To reduce the computational load of the platform, however, the number

of events notified to LocHNESs for each call is reduced by the probes according to a fixed sampling

ratio (for example 1:10, i.e. with a time resolution of 4.8 s).

Using the above data, the LocHNESs platform produces aggregated traffic maps in raster form:

the area under analysis is split into a number of contiguous square pixels of varying size (typically

250x250 m in urban areas and 500x500 m in extra-urban areas2). For each pixel the platform estimates

a number of parameters, such as the average speed in the four quadrants (North West, North East,

South East and South West) of a Cartesian reference system centred in the centre of the pixel, the total

average speed, the number of moving users, etc. In order to have real time applications for vehicular

traffic these traffic maps are constantly updated with a given periodicity (for instance, every 5

minutes).

It is important to note that the LocHNESs platform complies with the 2002 Directive by the

European Parliament and Council on privacy.3 At no time could individual users be identified based on

the collected and analyzed data. In this sense, we hope that this project might stimulate a dialogue on

the responsible access to locational data and on how it could provide value-added services, such as

traffic monitoring, to local and regional communities.

2.2. Localization engine The Localization engine estimates the instantaneous position of each ME involved in a call

using the data extracted from the MEASurement RESult messages, received from the probes. Location is

calculated using an Enhanced Cell Id with Timing Advance algorithm (E-CI+TA) [14], named DFL (Data

Fit Location); its principal components are the following (Fig. 2a):

1 These measurements form the basic raw data for the handover algorithms in BSC/MSC. 2 This length depends on the accuracy of the localization algorithm and can be modified accordingly. 3 Directive 2002/58/EC of the European Parliament and of the Council of 12 July 2002 concerning the processing of personal data

and the protection of privacy in the electronic communication sector (Directive on privacy and electronic communications).



5

• Network database – it is a database that contains all the parameters coming from the planning and

dimensioning process of the entire mobile network (Cell identifiers, i.e. CGI, BSIC and number of BCCH

carrier, BTSs latitude, longitude and height, BTS antennas azimuth and tilt, BTS transmission power and

losses, etc.);

• Antennas database – it is a database that contains the complete radiation patterns (both in the H and

V plane) of all the antennas mounted on the BTSs;

• Propagation model – it allows to calculate the mean received power as a function of different

parameters such as the operating frequency, the ME-BTS distance, the ME and BTS heights above the

ground, the building density and typology, etc.. The Localization engine, in particular, uses the COST-

Hata propagation model, described in [15], which does not require the knowledge of the area

morphology and of the building typology with obvious advantages for computational speed.

For each call, the Localization engine, through the probes, receives the signal strength level

(RXLEV) measured by the ME on the serving BTS and on a maximum of six adjacent BTSs, the cell

identifiers (LAC and CI) of the received BTSs and the actual TA. The DFL algorithm works as follows:

1. through the identifiers received and using the Network database, it obtains the geographic position of

the BTSs involved in the measurement;

2. starting from these positions and using the antenna beam widths extracted from the Antennas

database, it defines an area in which the ME is supposed to be located with high probability based on

simple geometric considerations;

3. it further bounds the search area using the intersection with the TA ring;

4. it identifies a grid in this new search area4;

5. for each point p of the grid, it calculates the mean power received by the ME from every BTS involved

in the measurement ( ( )pPci ) using the proper parameters of the Network database, the radiation

patterns contained in the Antennas database and the propagation model;

6. for each point p of the grid and considering the i-th BTS, it calculates the error function

( ) ( )i i ie p Pm Pc p= ! , where

iPm is the power measured by the ME on the i-th BTS;

7. it estimates the ME position *p , finding the point p that minimizes the mean square error

( ) ( )( )2 2

i i

i

e p Pm Pc p= !" .

2.3. Tracking filter

The Tracking filter estimates the complete trajectory of the MEs, and the related speed, starting

from a sequence of punctual localizations received, with the associated timestamps, from the

Localization engine. It consists of the following blocks (Fig. 2b):

4 The step of this grid has to be accurately chosen because on one hand it can affect the localization error if it is chosen too high

and on the other hand, it can increase the computation time if it is chosen too low; in urban areas, for example, a reasonable

value is of 50 meters.



6

• Sampler - it receives the sequence of ME position estimates, then removes the incorrect localizations

(according to an associated numeric code set by the DFL algorithm) and finally resamples the remaining

ones with a fixed step;

• Latitude and Longitude Estimators - they are two ad-hoc designed processing systems able to estimate

the covered position (and speed) trajectories along the two directions, attenuating the measurement

noises. Regarding the position estimation, the processing algorithm used is a combination of two low-

pass filters working off-line. One filter works from the first to the last sample of the locations sequence,

and gives a time-delayed estimation of the position trajectory, in order to take into account the delays

occurring in the data acquisition, processing and filtering. The other filter works in an analogue way

but in the opposite direction (from the last to the first sample of the sequence). A combination

algorithms is used to correctly merge the filtered sequences in order to obtain an estimation of the

position trajectory which is homogenous along the whole observation window. Regarding speed

estimation, a similar processing algorithm is used, but it utilizes a filter composed by an ideal-derivator

and a second-order law-pass filter. This filter allows to both attenuate the noise and derivate the

locations sequence in order to extract the speed trajectory.

• Combiner - it merges the two components to give an estimation on the complete trajectory. As regards

the speed trajectory estimation, the result is also combined with the output of a first-order low-pass

filter which gives another speed estimation, starting from the instantaneous displacements between

subsequent samples of the estimated position trajectory.

2.4. Mobility state estimator

The Mobility state estimator separates the set of calls made by “moving ME” from the set of

calls made by “not moving ME”.5 The adopted algorithm calculates the average ME speed avv in the

time interval wT (said evaluation window) and compares this speed with a reference threshold

tv : the

ME is evaluated as “moving” if av tv v! . The evaluation window

wT and the threshold speed

tv have

been obtained through an empirical analysis with the following considerations:

1. wT has been obtained minimizing ( )MNP , that is the probability of considering as “not moving” a

ME who is “moving”, whatever is the threshold speed tv ;

2. given wT ,

tv is obtained minimizing a linear combination of ( )MNP and ( )NMP , this last being

the probability of estimating as “moving ME” a ME who is “not moving ME”, i.e. minimising the

function ( ) ( ) ( )1w P N M w P M N+ ! , ] [0,1w! .

The minimization of this combination is needed due to the trade-off between these two probabilities,

i.e. as tv increases, ( )MNP increases consequently whereas ( )NMP decreases and vice versa.

5 In the following, we will define “moving ME” a ME located in a car or on a fast mean of transport and “not moving ME” a ME used

by a still user or by a pedestrian.



7

Finally, calls lasting less than wT are discarded, whereas calls lasting more than

wn T (with

2n ! ) are considered as they are n different calls making it possible to correctly estimate the

mobility state even if it changes during the same call.

2.5. Traffic map calculator

The Traffic map calculator produces the traffic maps for the entire area monitored by the

platform. This is accomplished using the set of calls considered by the Mobility state estimator as made

by “moving ME” in the time interval T! that ends when these maps are produced; the value for this

interval determines the confidence of the calculated statistics and consequently has to be accurately

chosen. Practically it depends on the number of calls it includes and finally on all the parameters linked

to the telephone traffic density such as the area type, the time of the day, etc. As previously said,

these traffic maps are periodically updated in order to have real time estimations.

As an example, we describe the algorithm used by this module to produce the traffic maps for

the average speed:

1. It splits the trajectory of the calls made in the time interval T! among the different pixels where the

trajectory is located;

2. It calculates the average ME speed for each share of the trajectory, i.e.

1

ij

ij ijm

m Iij

v vcard I !

= ", where i

identifies the i-th pixel, j identifies the j-th ME and ijI

represents the set of different MEj speed

estimations in the i-th pixel;

3. It calculates the total average speed value for the i-th pixel, i.e. 1

i

i ij

j Ii

v vcard I !

= " , where the set iI

represents the indexes of the MEj located in the i-th pixel.

Similarly, the Traffic map calculator obtains the maps of the average speed in each of the four

quadrants (North West, North East, South East and South West) of a Cartesian reference system centred

in the centre of the pixel and the analogous maps of the maximum speeds.

2.6. LocHNESs data in Rome Telecom Italia installed the platform LocHNESs and the related probes on a group of BSC located

in Rome, covering an area of approximately 100km2 in the north-east of the city. The area was divided

into a grid of 250 x 250 m squares and the traffic maps were produced every 5 minutes, as described in

paragraph II E. Moreover, some ad-hoc algorithms were added to obtain maps related to the number of

pedestrians and the number of foreigners. The former was calculated summing the number of MEs

estimated to be in each pixel of the grid and considered “not moving MEs” by the Mobility state

estimator; the latter was calculated considering the trajectories of those MEs whose IMSI (International

Mobile Subscriber Identity) numbers were related to foreigners Mobile Network Operators6.

6 The first three digits of the IMSI are the Mobile Country Code (MCC) and identify the nationality of the Mobile Network Operator.



8

2.7. Voice and data traffic in Rome A further Telecom Italia server provided the voice and data traffic (expressed in Erlang) served

by each of the BTSs located in the urban area of Rome (about 450 directional antennas covering about

47km2). This data was localized and collected with a sampling period of 15 minutes.

3. Other Locational Data Used in The Project The Real Time Rome project also processed data coming from the following sources.

3.1. Location of Atac buses The buses run by Atac (the transport company of the City of Rome) carried GPS devices which

calculated each vehicle’s location based on GPS satellite triangulation and reported this data to an Atac

server in real time, using UDP datagrams sent through a GPRS connection.

3.2. Location of Samarcanda taxis The taxis run by Samarcanda (a taxis cooperative working in Rome) carried GPS devices and

reported each vehicle’s location to a Samarcanda server in real time, using a radio transmission. Such

data was then collected and stored with a sampling period of 5 minutes.

3.3. Localized traffic noise A wireless sensor network was developed and implemented to acquire real-time traffic noise

from different spots in Rome to be played at the Venice Biennale exhibition.

Three Via EPIA boards were located in three different locations in Rome to acquire real time

traffic noise through capacitor microphones. An audio streaming technology, based on MP3 audio

content encoding and HTTP/TCP transport protocol, was used to send such noises to Venice.

Incidentally, the noise was reproduced punctually using Audio Spotlight [16].

4. System Architecture In this section a description of the system architecture, the data collection, transfer and

processing is presented (see Fig. 3a). Three servers were set up by Telecom Italia7, Atac and Samarcanda

to provide locational data, both using SFTP transfer and UDP datagrams transfer. A database was

designed and ran on MySQL in the SENSEable City Lab server at MIT, both with some Java applications

which collected the data from the externals servers, pre-processed them providing the results to an

internal SFTP server. The database was composed of several tables whose structures are shown in Fig.

3b.

7 This server provides both the traffic maps of LocHNESs and the served traffic.



9

Six computers at the Venice Biennale exhibit continuously accessed the SENSEable City Lab FTP

server and ran Java software (developed using Processing, and OpenGL) to visualize the different

dynamic maps of the city in real-time, using Google maps as background.

Furthermore, three computers connected to three audio streaming sources (coming from the

three audio sensors installed in Rome) played locational traffic noise in time-synchronization with the

visual software.

5. Processing and Visual Software In the following subsections, detailed description of the six processing and visual software is

given, starting form the questions they address.

5.1. Pulse: Where in Rome are people converging over the course of a day? (see Fig. 4a). This software visualized the intensity of mobile phone calls in Rome at the present moment and

compared it to the previous day’s data.

It is based on a geographic interpolation of the served traffic intensity provided by each

monitored antenna. To this end, the Rome urban area was divided in 40 x 40 m pixels and the traffic

intensity was assigned at each pixel considering the distance ,i jd between the pixel

, 1, , _jz j n pixels= K and the surrounding antennas , 1, , _ia i n cells= K , the cell type, the

location of the pixel in the city and an exponential distribution function. The software showed the real time data (updated every 15 minutes) on the left side, and a loop

of the previous day’s data, constituted by 96 different images, on the right side.

5.2. Gatherings: How do people occupy and move through certain areas of the city during special events? (see Fig. 4b).

This software showed the pre-recorded intensity of mobile phone usages during important

events in Rome:

• viewing the World Cup final match between Italy and France on July 9, 2006 and celebrating the arrival

in Rome of the winning Italy national team on July 10;

• Madonna’s concert in Rome on August 6, 2006.

The software was realized by concatenating 3D visualizations of the served traffic in specific

areas of Rome and at different times of the selected days.

5.3. Icons: Which landmarks in Rome attract more people? (see Fig. 5a). This software showed the density of people using mobile phones at different historic attractions

in Rome. To this end, the served traffic intensity data was processed using the following function 1

_ _k

k j

j Ik

attraction traffic pixel trafficcard I !

= " , where the set kI denotes all the indexes j



10

of the pixels jz located in correspondence of the attraction site k . Clearly the cardinality of the set

kI (

kcard I ) depended on the planar extension of the site.

A bar on the top of each attraction showed the relative traffic intensity, while at the bottom of

the screen a week-long data comparison between the most popular site and the least popular site was

shown. Every 15 minutes, when the new data was available, both the top and the bottom of the screen

were updated based on the new ranking.

5.4. Visitors: Where are the concentrations of foreigners in Rome? (see Fig. 5b). This 3-D software highlighted a 24 hours loop of the locations around the Stazione Termini

neighbourhood of Rome where foreigners were speaking on mobile phones. An algorithm created a 48-

length data queue where, with a sampling rate of 1/30minutes, the newest foreigners locational data

was added (deleting the oldest one).

For the 3D visualization purpose, an algorithm was also used to spatially-interpolate the

foreigners’ locational data in order to create a 10 x 10 m pixels matrix (based on a 2D smoothing

technique) and a loop function was used to recursively read the queue and graph the related 3D image.

5.5. Connectivity: Is public transportation where the people are? How do the movement patterns of buses and taxis and pedestrians overlap in the Stazione Termini neighbourhood of Rome? (see Fig. 6a).

This software showed the changing positions of Atac buses and Samarcanda taxis indicated by

yellow points, and the relative densities of mobile phone users, represented by the red areas.

An algorithm was used to acquire and update the buses and taxis location in real time (based

on a hash table). It also estimated buses and taxis paths based on the previous three locations,

drawing a yellow tail on the map. If the tail was long, this meant that a bus or a taxi was moving fast.

The algorithm acquired the pedestrian locational data every 5 minutes, showing a red layer on

the top of the map (areas coloured by a deeper red had a higher density of pedestrians).

5.6. Flow: Where is traffic moving? (see Fig. 6b). This software visualized the locational data of mobile phone callers travelling in vehicles. It

focused on the area around the Stazione Termini and the Grande Raccordo Anulare (Rome’s ring road).

The software crated a layer on the top of the map, showing 250 x 250 m pixels whose colours were

related to vehicle speeds. Red indicated areas where traffic was moving slowly, green showed areas

where vehicles were moving quickly.

If the average speed associated to the pixel was higher that 40km/h, the software also showed

an arrow in the centre of the pixel whose direction was the dominant direction of travel and magnitude

was proportional to the related speed.



11

A note should be made as regards the real time constraint needed by the realized application.

The overall time elapsed from data acquisition to processed information visualization in Venice was

decided to be less then one minute. To this end, an ad-hoc software platform was developed. It allowed

the data processing to be split between various stages, based on the amount of data managed by the

nodes (providers’ servers, SENSEable server at MIT, laptops at the Venice Biennale exhibit) and their

processing powers.

6. Conclusion In this paper a detailed description of the Real Time Rome project, developed for the 10th

International Architecture Exhibition in Venice has been presented.

The project used the Telecom Italia LocHNESs platform for the real time evaluation of statistical

indexes based on the anonymous monitoring of the ME movements; in particular this platform was used

to obtain a set of maps describing the vehicular traffic status and the movements of pedestrians and

foreigners. Moreover, the system developed for the project acquired the instantaneous location of buses

and taxis and the voice and data traffic served by all the BTSs of the network. All these data were

opportunely combined and updated in real time to realize several information layers. The case study

regarded the monitoring of the city of Rome, considering both urban and sub urban areas.

This project aimed to show how modern digital technologies and their applications could give

city dwellers a deeper knowledge of urban dynamics and more control over their environment by

allowing them to make decisions that are more informed about their surroundings, reducing the

inefficiencies of present day urban systems.

Acknowledgements The Real Time Rome exhibit at the 10th International Architecture Exhibition at Venice, Italy

was sponsored by Telecom Italia, with technical partners: Biennale di Venezia, City of Rome, Google,

Atac-Rome buses, Samarcanda Taxi and Microtek. We acknowledge the significant contributions of

Andres Sevtsuk, Burak Arikan, Assaf Biderman, Filippo Dal Fiore, Saba Ghole, Daniel Gutierrez, Sonya

Huang, Sriram Krishnan, Justin Moe, Francisca Rojas and Najib Marc Terazi, in implementing the Real

Time Rome exhibit. We also would like to thank Giovanni Celentano, professor at the University of

Naples, Italy, and Lucio Pinto, President of the Silvio Tronchetti Provera Foundation, for their generous

suggestions and feedback.



12

References [1] J.L. Ygnace, J.G. Remy, J.L. Bosseboeuf and V. Da Fonseca, Travel Time Estimates on Rhone Corridor

Network Using Cellular Phones as Probes: Phase 1 Technology Assessment and Preliminary Results.

French Department of Transportation, Arceuil, France, 2000.

[2] J. White, J. Quick, P. Philippou, “The use of Mobile Phone Location Data for Traffic Information,” in

Proc. 12th IEE International Conference on Road Transport Information and Control, 2004.

[3] T. Roos, P. Myllymaki and H. Tirri, “A Statistical Modelling Approach to Location Estimation,” IEEE

Transactions on Mobile Computing, vol. 1, n. 1, pp. 59-69, January-March 2002.

[4] Y.B.Y. Yim and R. Cayford, Investigation of Vehicles as Probes Using Global Positioning System and

Cellular Phone Tracking: Field Operational Test. Report UCB-ITS-PWP-2001- 9. California PATH Program,

Institute of Transportation Studies, University of California, Berkeley, 2001.

[5] B.L. Smith, M.L. Pack, D.J. Lovell and M.W. Sermons, “Transportation Management Applications of

Anonymous Mobile Call Sampling,” On 80th Annual Meeting Preprint CDROM, Transportation Research

Board, Washington, D.C., 2001.

[6] R. Cayford and T. Johnson, “Operational Parameters Affecting the Use of Anonymous Cell Phone

Tracking for Generating Traffic Information,” On Transportation Research Board 82nd Annual Meeting

CD-ROM. Transportation Research Board, Washington, D.C., 2003.

[7] M.D. Fontane and B.L. Smith, Improving The Effectiveness Of Traffic Monitoring Based On Wireless

Location Technology, Final Report. Virginia Transportation Research Council. December 2004.

[8] University of Maryland Transportation Studies Centre. Final Evaluation Report for the CAPITAL-ITS

Operational Test and Demonstration Program. University of Maryland, College Park, 1997.

[9] ITIS Holdings, http//www.itisholdings.com/.

[10] Delcan, http://www.delcan.ca/.

[11] AirSage, http://www.airsage.com/.

[12] IntelliOne Technologies, http://www.intellione.com/.

[13] 3GPP TS 08.58, “3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio

Access Network; Base Station Controller - Base Transceiver Station (BSC - BTS) interface; Layer 3

specification (Release 1999)”.

[14] A. Kupper, Location-based Services - Fundamentals and Operation, John Wiley & Sons Ltd, 2005.

[15] E. Damosso, Digital Mobile Radio Towards Future Generation Systems, COST 231 Final Report, 1998.

[16] Holosonics Research Labs, Audio Spotlight, http://www.holosonics.com/

SENSEable Working Paper, 2007 18

Localizationengine

Trackingfilter

Mobilitystate

estimator

Traffic mapcalculator

To applicationsand services

Fromprobes

LocHNESs

Localizationengine

Trackingfilter

Mobilitystate

estimator

Traffic mapcalculator

To applicationsand services

Fromprobes

LocHNESs Fig. 1. Functional structure of the LocHNESs platform


DFLalgorithm

Networkdatabase

Antennasdatabase

Propagationmodel

MS positionestimate

Measurementscollected from MS

Localization engine

DFLalgorithm

DFLalgorithm

Networkdatabase

Antennasdatabase

Propagationmodel

Propagationmodel

MS positionestimate

MS positionestimate



Localization engine

Fig. 2. (a) Localization engine

Sampler MS trajectoryestimate

DFL positionestimate

Tracking filter

Latitudeestimator

Longitudeestimator

CombinerSampler MS trajectoryestimate

DFL positionestimate

Tracking filter

Latitudeestimator

Longitudeestimator

Combiner

Fig. 2. (b) Tracking filter


Fig. 3(a). Schematic of the data collection, transfer and processing

CellCellIdLatitudeLongitude

ErlangTimestampCellIdErlangValue

PedestriansTimestampPixelXComponentPixelYComponentNumber

BusTimestampVeh icleIdStatusLatit udeLon gitude

TaxiTimestampVeh icleIdStatusLatit udeLon gitude

ForeignersTimestampPixelXComponentPixelYComponentNumber

VehicleTimestampPixelXCompon entPixelYCompon entNumberA verageSpeedSp eedNWSp eedNESp eedSESp eedSW

LocHNESs

Voice and data traffic

Atac buses

Samarcanda taxis

Fig. 3(b). Schematic of the database tables


Fig. 4 (a). Pulse: What are the patterns of use in Rome?

Fig. 4 (b). Gatherings: What does Rome look like during special events?


Fig. 5 (a). Icons: Which landmarks in Rome attract more people?

Fig. 5 (b). Visitors: Where are tourists congregating?


Fig. 6 (a). Connectivity: Is public transportation where the people are?

Fig. 6 (b). Flow: Where is traffic moving?

2007 Calabrese Colonna Lovisolo Parata Ratti Senselab

Documents

Transcript of 2007 Calabrese Colonna Lovisolo Parata Ratti Senselab