Francesco Calabrese Real-Time Urban Monitoring Using Cellular

Massimo Colonna
Piero Lovisolo
Phones: a Case-Study in Rome
Dario Parata
Carlo Ratti

keywords  Intelligent transportation system (ITS), location-based services

(LBS), wireless locationing, cellphone network, GSM, GPS, real time control
systems

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.
SENSEable Working Paper, 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: fcalabre@mit.edu

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

© SENSEable City, 2007

SENSEable Working Paper, 2007 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

© SENSEable City, 2007

SENSEable Working Paper, 2007 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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 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).

© SENSEable City, 2007

SENSEable Working Paper, 2007 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 ( Pc i (p )) 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
ei ( p ) = Pmi ! Pci ( p ) , where Pmi 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
e(p) = " (Pmi ! Pci ( p )) .
i
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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 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 vav in the
time interval Tw (said evaluation window) and compares this speed with a reference threshold vt : the
ME is evaluated as “moving” if vav ! vt . The evaluation window Tw and the threshold speed v have
t
been obtained through an empirical analysis with the following considerations:
1. Tw has been obtained minimizing P (N M ), that is the probability of considering as “not moving” a
ME who is “moving”, whatever is the threshold speed vt ;
2. given Tw , vt is obtained minimizing a linear combination of P (N M ) and P (M N ), this last being
the probability of estimating as “moving ME” a ME who is “not moving ME”, i.e. minimising the
function w P (N M )+ (1 ! w ) P (M N ), w! ]0,1[ .
The minimization of this combination is needed due to the trade-off between these two probabilities,
i.e. as vt increases, P (N M ) increases consequently whereas P (M N ) 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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 7

Finally, calls lasting less than Tw are discarded, whereas calls lasting more than n Tw (with
n ! 2 ) 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
1
trajectory is located; vij = " vijm
card I ij m!Iij
2. It calculates the average ME speed for each share of the trajectory, i.e. , where i
I ij
identifies the i-th pixel, j identifies the j-th ME and represents the set of different MEj speed
estimations in the i-th pixel;
1
3. It calculates the total average speed value for the i-th pixel, i.e. vi = "v ij , where the set Ii
card I i j!I i
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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 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 di , j between the pixel
z j , j = 1, K , n _ pixels and the surrounding antennas ai , i = 1, K , n _ cells , 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
attraction _ traffick = " pixel _ traffic j , where the set I k denotes all the indexes j
card I k j!I k

© SENSEable City, 2007

SENSEable Working Paper, 2007 10

of the pixels z j located in correspondence of the attraction site k . Clearly the cardinality of the set
I k ( card I k ) 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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 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.

© SENSEable City, 2007

SENSEable Working Paper, 2007 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 City, 2007

SENSEable Working Paper, 2007 18

Mobility
From Localization Tracking Traffic map To applications
state
probes engine filter calculator and services
estimator
LocHNESs

Fig. 1. Functional structure of the LocHNESs platform

SENSEable Working Paper, 2007 19

Network Antennas
database database

Measurements DFL MS position

collected from MS algorithm estimate

Propagation
model
Localization engine
Fig. 2. (a) Localization engine

Latitude
estimator

DFL position MS trajectory

Sampler Combiner
estimate estimate

Longitude
estimator

Tracking filter

Fig. 2. (b) Tracking filter

SENSEable Working Paper, 2007 20

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

Erlang Bus
Cell
T imestamp Time stamp
CellId CellId Veh icleId
Latitude ErlangValue Stat us
Longitude Latit ude
Lon gitude
Voice and data traffic
Atac buses
Pedestrians Vehicle
Timestamp Timestamp
PixelXComponent PixelXCompon ent Taxi
PixelYComponent PixelYCompon ent
Number Number Time stamp
A verageSpeed Veh icleId
Sp eedNW Stat us
Foreig ners Sp eedNE Latit ude
Sp eedSE Lon gitude
Timestamp
Sp eedSW
PixelXComponent
PixelYComponent Samarcanda taxis
Number

LocHNESs
Fig. 3(b). Schematic of the database tables
SENSEable Working Paper, 2007 21

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

Fig. 4 (b). Gatherings: What does Rome look like during special events?
SENSEable Working Paper, 2007 22

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

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

SENSEable Working Paper, 2007 23

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

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