Telecommunication Systems Enabling Real Time Navigation

Alessandro Bazzi, Barbara M. Masini, Gianni Pasolini, Paolomaria Torreggiani

WiLab, IEIIT-BO/CNR, DEIS-University of Bologna,

V.le Risorgimento 2, 40136 Bologna, Italy.

Email: {alessandro.bazzi, barbara.masini, gianni.pasolini, paolomar.torreggiani}@unibo.it

Abstract— Traffic is one of the most important problemsin industrialized countries: roads are getting more and morecrowded, especially during rush hours, with heavy consequenceson people’s quality of life, accidents, pollution, and fuel con-sumption. The transmission of up-to-date traffic information toon-board navigators would allow the redistribution of trafficflows over alternative routes, thus reducing road congestionsand slowdowns. In this paper we investigate the possibilityto send the information on the average-speed in any road ofinterest to on-board navigators by means of current broadcastand unicast communication technologies. A discussion on themost convenient transmission strategy will also be given withreference to real scenarios.

I. INTRODUCTION

The impact of road traffic on both the health of citizens

and the economy of industrial countries is becoming almost

unsustainable: the mix of private and commercial vehicles

that everyday jams urban and suburban roads reduces the

transportation efficiency and increases the travel times as

well as the number of accidents, the fuel consumption and

the air pollution. The road transport system of modern cities

is, in particular, very fragile and prone to collapse when

unpredictable events (such as car accidents) or deterministic

yet disruptive ones (such as rush-hour periods) occur.

Several approaches have been adopted in order to coun-

teract traffic congestions and improve vehicular mobility.

Intelligent traffic lights, for instance, are able to adaptively

modify their timing, travel time. Unfortunately they cannot

suggest alternative routes and their effectiveness is reduced

when a large amount of cars choose the same path.

More effective solutions are based on the provision of real-

time traffic information by means of variable message panels.

Also this solution, however, has a limited effectiveness, since

only few main roads are monitored and the information is

very localized, thus useless for optimal long-distance routing.

It is evident that the real breakthrough for services aimed

at supporting the vehicular mobility is the adoption of a

suitable communication technology transmitting up-to-date

traffic information directly to in-vehicle navigators.

This kind of service, aimed at supporting users’ mobility

by means of information and communication technologies,

falls within the framework of “infomobility” services, deeply

investigated by both the researchers’ community and car

manufacturers [1], [2], [3], and is gaining an increasing

interest. Some solutions are, in fact, becoming available.

Work performed in the framework of the national project Pegasus, fundedby the Italian Ministry for the Economical Development

In several Countries, for instance, on-board navigation

devices receive updated traffic information by means of the

general packet radio service (GPRS) technology [4]. Another

example is represented by the traffic message channel (TMC)

[5], [6], aimed at delivering traffic and travel information

using the radio data system (RDS) on conventional frequency

modulation (FM) radio broadcasts. These technologies and

applications have however some severe limitations:

• the data rate reserved for these services is very limited,

thus allowing the traffic conditions update for a very

limited number of roads;

• only the main events are described, with few approxi-

mate descriptions. We are informed, for instance, that a

given road segment is congested due to road-works and

that the consequent car queue is increasing. We are not

given, however, the average-speed in the nearby roads,

which is crucial to trigger a possible path re-routing.

Indeed, the knowledge of the average-speed of vehicles in

a given road is already a matter of fact: let us consider, for

instance, that at the present time about one million vehicles

in Italy are equipped with an on board unit (OBU) integrating

both a global positioning system (GPS) receiver and a GPRS

transceiver. The main task of this device, which is fostered by

insurance companies, is to continuously collect and locally

store information about the vehicle status (position, speed,

acceleration, etc.), to be examined in case of accident. In

addition, however, this device periodically sends both its

position and speed to a control center, which can therefore

derive the average vehicular speed in any given road travelled

by equipped cars. Providing this information back to the

vehicles (including those without the OBU) would allow the

on-board navigators to always choose the optimal route to

the destination, thus minimizing inconveniences.

In this paper we aim at investigating the possibility to

send the information on the average-speed in any road of

interest to on-board navigation systems by means of current

broadcast and unicast communication technologies; as far

as broadcast systems are concerned, in the following we

will investigate multimedia broadcast and multicast services

(MBMS) over GPRS, MBMS over universal mobile telecom-

munication system (UMTS), digital video broadcasting-

terrestrial (DVB-T), and digital video broadcasting-handheld

(DVB-H). Actual cellular systems (both GPRS and UMTS)

will be investigated as unicast solutions.

2010 13th International IEEEAnnual Conference on Intelligent Transportation SystemsMadeira Island, Portugal, September 19-22, 2010

TB4.2

978-1-4244-7658-9/10/$26.00 ©2010 IEEE 1057

Fig. 1. Example scenario: the best route with real time traffic conditions.

II. THE ENVISIONED SERVICE

Let us clarify the infomobility service envisioned in this

paper, that will be hereafter denoted as “smart navigation”,

discussing its effect from the final user’s point of view.

Suppose the driver enters his car and turns on his smart

navigator. Then, he selects his home as the final destination;

his problem is not how to get there, he perfectly knows the

possible routes; his problem is how to minimize the time

spent in his car.

Once turned on, the smart navigator receives information

on the average-speed in each road segment from its current

position to the destination and calculates the optimal route;

on a real time basis, the smart navigator updates its data and,

in case, modifies the route in order to avoid any slowdown.

A representation of the expected benefit is given in Fig.

1: the navigation system must select the best route to the

destination; although under normal conditions the route A

is the shortest, both in terms of distance and time, the

route B may be preferred taking into account the actual

traffic conditions (that is, the average-speeds of cars already

travelling along route A and route B).

To investigate how communication systems can support

this service is the very objective of this paper.

III. THE TPEG STANDARD

Independently on the communication technology, we as-

sume the adoption of the transport protocol experts group

(TPEG) technology [7], [8] at the highest layers of the

protocol pillar.

TPEG has been developed by a number of broadcasters

and consumer industries to overcome the limitations of the

RDS-TMC technology, allowing to provide a wider range of

services to a wider range of users and devices.

TPEG specifications define in details few main applica-

tions but do not limit the use of TPEG to them; among

these it defines the road traffic message (RTM) application

to transmit updated traffic information.

Particular attention is given to localization. RDS-TMC, in

fact, is based on a static road-list defined by national trans-

port ministries, that includes only a small fraction of the

road network. Although it seems possible to overcome the

Fig. 2. TPEG frame structure.

limited extension of the road-list by simply identifying any

road segment of interest with the coordinates of its starting

and ending points, in practice this is not so easy due to

possible mismatch among different digital maps [9].

TPEG specifications provide a method to solve this prob-

lem (which is called TPEG-loc) but it also allows the

adoption of any other localization method chosen by the

service provider (e.g., TMC or AGORA-C).

TPEG RTM data organization is shown in Fig. 2. The

highest level structure is the TPEG transport frame, which

carries a 7 bytes header and a service frame. The service

frame includes 4 overhead bytes and a variable number of

component frames. Each component frame includes one mes-

sage (Component Data) preceded by 5 bytes of component

header. Each message is finally divided into three parts:

the message management container, which includes general

information, such as the message identifier and the instant

of generation, the event container, which includes the event

to be communicated, and the localization container, which

determines the position of the event.

The size of the message is not fixed: it depends on the

content of the message management container, on the specific

event description in the event container, and on the way

the position is indicated in the localization container. In an

experimental implementation performed in the Korean city

of Daejeon by Sammo Cho et al. [10], an average value of

60 bytes was observed for TPEG RTM messages. Hence a

component frame of 60 bytes plus 5 overhead bytes for each

travelling direction will be considered henceforth. Note that

a high number of messages should be multiplexed into one

service frame, so that the transport frame and service frame

overheads would be negligible with respect to the useful data.

In the following we will show that for the envisioned

service this size requires a significant resource utilization

for most of actual transmission technologies. For this reason

we also considered, for comparison purposes, a different

solution, denoted as short messages, that requires a less

redundant container.

We will show, therefore, the performance that would be

achieved if 8 bytes messages were used for both directions of

any road segment. This would be possible, for example, using

a predefined table to univocally determine a single link, such

1058

Fig. 3. The number of road segments in a city is evaluated considering acircle centered in the middle of the city with an increasing radius.

as in RDS-TMC (as will be discussed in the following); in

this case, 4 bytes would be enough for link identification, 2

bytes could indicate the average speed for both directions and

2 bytes could be left for message control and error check.

If a large amount of short messages are grouped into the

event container of a single component message, all TPEG

overhead will be negligible.

Although the definition of a new application is required,

the service still remains TPEG compliant. The main draw-

back of this solution is the need for tables updating: Some-

how, an update of the table must be communicated to all

smart navigators anytime a new road segment is created.

IV. AMOUNT OF DATA TO BE TRANSMITTED

Our investigation on the suitability of current broad-

cast and unicast communication technologies to support

the downlink (that is, from the control center to vehicles)

transmission of the average-speeds requires, first of all, the

assessment of the amount of data to be transmitted. Once

the size of each packet related to a road segment has been

defined (in the previous section), it is still not known how

many roads must be updated. Let us assume, to this purpose,

an urban scenario, which is the most challenging since it is

characterized by a high road density. The question is: How

many road segments are present in an urban area?

The answer to this question has been obtained through a

query campaign carried out on the digital-maps of the Italian

road network provided by Tele Atlas1.

The number of roads encompassed in a circle centered in

the middle of the city was evaluated varying its radius (as

represented in Fig. 3). In particular, we considered two

metropolitan Italian cities:

• Rome (2700000 inhabitants, 1285 Km2)

• Milan (1300000 inhabitants, 183 Km2)

and two middle sized cities

• Bologna (377000 inhabitants, 140 Km2)

• Florence (370000 inhabitants, 102 Km2).

1Tele Atlas is the licensing business unit of TomTom N.V., the world’sprovider of location and navigation solutions.

0 2000 4000 6000 8000 100000

1

2

3

4

5

6

7x 10

4

Radius [m]

Ro

ad

se

gm

en

ts

Florence

Bologna

Milan

Rome

Fig. 4. Number of road segments within a circle of variable radius.Comparison among four Italian cities (all FRCs are considered).

The outcomes of this investigation are reported in Fig. 4,

that shows that even considering a small radius (with respect

to the city extension) the number of road segments is very

high; in a circle with a radius of five kilometers (78.5 Km2),

for instance, the number of road segments goes from about

13000 to about 25000, depending on the city.

Of course there is no need to transmit the average speeds

related to roads not affected by any slowdown: the amount of

road segments to be updated is, indeed, only a fraction of the

total. Nonetheless, depending on the adopted communication

technology, the amount of data to be transmitted could still

be unaffordable, especially considering that the time that

elapses between the on-board navigator switching-on and the

completion of the roads’ conditions update (latency time)

should be kept as small as possible, so that to avoid any

waste of time waiting the navigator’s “ready to go”.

Let us observe, however, that within the digital map

database each road segment is given an attribute, denoted

as functional road class (FRC), which is related to the im-

portance of the segment (see the first two columns, topmost

part, of Tab. I).

In order to reduce the latency time we should ask whether

an update of all FRCs within the area of interest is strictly

needed or not. To this end, we focused our attention on the

city of Florence, assumed as case study, and we subdivided

the road segments falling within a circle of a given radius

on the basis of their FRC. Results are shown in Fig. 5.

As we can see, in an urban scenario most of road segments

belong to FRC 6 (local roads) and FRC 7 (local roads of

minor importance). It is easy to understand, however, that,

while FRC 6 is of great importance for the assessment of

local traffic conditions, as it includes road used to travel

within a part of a settlement, FRC 7 is, on the contrary,

substantially useless, since it includes roads that only have a

destination function, such as dead-end roads, alleys, narrow

roads between buildings or in a park/garden, etc.

1059

TABLE I

NUMBER OF SEGMENTS IN TELE ATLAS DATABASE PER EACH FUNCTIONAL ROAD CLASS (FRC) CONSIDERING THREE AREAS OF DECREASING

EXTENSION: ITALY, THE TUSCANY REGION, AND THE FLORENCE PROVINCE.

Italy Tuscany Florence Province

FRC FRC description 301336 km2 22994 km2 3514 km2

60.0 millions inhabitants 3.71 millions inhabitants 0.98 millions inhabitant

0 Motorways 27.979 1.705 587

1 Major National Roads not Motorways 48.731 2.411 0

2 Other Roads of National Importance 124.701 7.106 2.220

3 Main Regional Roads 217.970 16.411 3.776

4 Regional Connecting Roads 1.044.349 57.108 11.519

5 Local Roads of High Importance 126.312 6.662 2.209

6 Local Roads 1.113.647 39.710 8.304

7 Local Roads of Minor Importance 4.826.062 203.052 43.310

Tot 7.529.751 334.165 71.925

0-2 201.411 11.222 2.807

3-5 1.388.631 80.181 17.504

6 1.113.647 39.710 8.304

All roads in Italy from FRC 1 to FRC 6: 2.703.689

All roads in Italy from FRC 0 to FRC 2: 201.411

Progressive coverage (0-2 Italy, 3-5 Tuscany, and 6 Florence Province): 289.896

It follows that, even considering a high road density

scenario, traffic updates related to roads belonging to FRC

7 can definitely be avoided, while traffic updates related to

FRC 6 must be transmitted, at least in a small geographical

scale (the urban area or the province, for instance).

When planning, on the other hand, a long distance trip,

the on-board navigator is mainly interested in the information

related to the most important roads at national level (from

FRC 0 to FRC 2) and regional level (from FRC 3 to FRC

5). Moreover, in this case the updates must consider a large

geographical scale. It follows that a convenient transmission

strategy must be conceived in order to meet the requirements

of both short and long distance planning.

Of course the choice of a particular transmission strat-

egy depends also on the adopted transmission technology.

Focusing our attention on some of the major current com-

munication infrastructures allowing full coverage in mobility

conditions, two alternatives will be discussed in the following

sections:

1) Broadcast technologies, with particular reference to

RDS-TMC, MBMS over GPRS, MBMS over UMTS,

DVB-T, and DVB-H;

2) Unicast technologies, with particular reference to

GPRS and UMTS.

V. BROADCAST TRANSMISSION

Broadcast transmission allows to send the same data

stream to all receivers avoiding useless duplicates. For the

smart navigation service, a broadcast approach may represent

a suitable solution, allowing to efficiently exploit radio

resources by cyclically transmitting traffic data to many users

over a common radio channel.

Many telecommunication technologies allowing to broad-

cast information to mobile terminals are available nowadays;

among them, RDS-TMC, MBMS over GPRS, MBMS over

UMTS, DVB-T, and DVB-H will be considered throughout

this work. In the following a brief description of their ad-

vantages and drawbacks will be given and their performance

will be shown in terms of refresh time, defined as the time

to transmit a complete update of the road network situation.

To this purpose, a convenient transmission strategy should

be defined. Henceforth the following cases will be investi-

gated:

1) transmission of updates related to all roads (except

FRC 7) at national level (Italy in the case study);

2) transmission of updates related to all roads at national

level belonging to FRCs from 0 to 2 (major roads);

3) transmission of updates related to all roads from FRC

0 to FRC 2 at national level, to all roads from FRC 3

to FRC 5 at regional level (Tuscany in the case study)

and to all FRC 6 at local level (Florence Province in

the case study). This strategy, denoted in the following

as progressive coverage, follows the remark, reported

in Sec. IV, that users are interested on all roads on a

small geographical scale and on the major roads on a

larger scale.

The number of road segments that correspond to these

solutions in the specific case study under investigation is

highlighted in the bottommost part of Tab. I.

In the numerical results, 10% of road segments are as-

sumed interested by slowdowns (thus 10% of road segments

will be updated); although in a real application this per-

centage strongly varies during time, we think it represents

a reasonable value for a busy hour; in any case, results

corresponding to a higher or lower percentage can be easily

derived from those presented with a simple scaling operation.

Please note that in the case of “progressive coverage” we

are assuming that transmitters located in different provinces

of the same region convey different FRC 6 updates, while

transmitters placed in different regions convey different up-

dates related to FRCs from 3 to 6.

A. RDS-TMC

RDS-TMC is a specific application of the FM-RDS used

for broadcasting real-time traffic and weather information.

It was developed to offer dynamic route guidance, thus

it broadcasts messages alerting the drivers of obstacles or

1060

0 2000 4000 6000 8000 100000

2000

4000

6000

8000

10000

12000

14000

Radius [m]

Road s

egm

ents

FRC 0

FRC 1

FRC 2

FRC 3

FRC 4

FRC 5

FRC 6

FRC 7

Fig. 5. City of Florence: number of road segments for each FRC as afunction of the circle radius.

slow downs all over a nation. Data related to traffic flows,

accidents, weather, etc. are gathered from traffic monitoring

systems, motorists’ calls, and collected at a central traffic

information center. They are then passed to the TMC traffic

information service provider, who generates TMC messages

according to the ALERT-C coding protocol [6].

RDS-TMC carries digital data at 1187.5 bps with an

overall bandwidth of approximately 5 KHz inside one FM

radio channel. The RDS-TMC data stream is partitioned into

packets and blocks. A packet consists of four blocks, each

being 26 bits long (i.e., 104 bits per packet); only 16 bits

are for information while the remaining 10 bits convey the

overhead (including the cyclic-redundancy-check sequence).

Considering that each TMC packet carries the information

of a single event (an accident, a congested road, etc.), it

is clear that the data rate is fairly low for the envisioned

service. Furthermore, the high error-rate that occurs in RDS-

TMC data received in areas where FM signal propagation

is impaired, requires a robust system with ample repetition

to ensure that the messages are delivered reliably. However,

the low-price of RDS broadcast stations and the widespread

diffusion of RDS receivers contributed to the adoption of

RDS-TMC for cars navigation systems in recent years, and

must be thus considered, at least for comparison purposes.

In the case of RDS-TMC we did not consider the TPEG

structure discussed in Sec. III; in order to not further reduce

RDS-TMC capacity, its standard use will be supposed.

To have a fair comparison with other communication

technologies, a road table including all roads belonging to

FRCs from 0 to 2 will be assumed, which is the one of the

cases (the least loaded one) considered for more performing

technologies.

The refresh time obtained with RDS-TMC is shown in Fig.

6. From this analysis it is clear that the TMC-RDS is not a

suitable solution for the envisioned service; even neglecting

all roads with an FRC higher than two, the update of 10%

of the road table requires about 1 hour.

RDS−TMC(*) MBMS−2G MBMS−3G 64k MBMS−3G 128k DVB−T DVB−H10

−1

100

101

102

103

104

105

Re

fre

sh

tim

e [

s]

FRC 0−2 Italy

Progressive coverage

All FRC Italy but 7

Progressive coverage, short messages

5 minutes

1 minute

Fig. 6. Refresh time adopting TMC-RDS, MBMS over GPRS, MBMSover UMTS at 64 kbps, MBMS over UMTS at 128 kbps, DVB-H, andDVB-T. Four cases are compared, varying the considered road segments(one case with short messages is depicted for comparison). 10% of roadsare supposed congested. (*) The standard TMC message is used for theperformance evaluation of RDS-TMC.

B. MBMS

Given the success of high bandwidth applications in third

generation cellular systems, especially with a large number of

users receiving the same high data rate services, efficient in-

formation distribution is essential. For this reason 3GPP pro-

vided (from the release 6) the MBMS technology, allowing

multicast and broadcast packet delivery in GPRS and UMTS

networks [11]. Adopting MBMS packets can be forwarded

from one source to many receivers without overloading the

network and wasting the scarce radio resources.

1) MBMS over GPRS: GPRS is the evolution of the

global system for mobile communication (GSM), the second

generation (2G) cellular technology, and represents the first

packet-switched communication technology for mobile users.

GSM and GPRS adopt the time division multiple access

(TDMA), with eight time slots per TDMA frame. While one

time slot per direction per user is reserved and used for each

voice call (silent suppression techniques allow to statistically

half this value), GPRS allows a single mobile station to

transmit on multiple time slots following the effective need.

Different coding schemes (CS) are provided in order to

allow different trade-offs between reliability and data rate.

With 3GPP release 6, GPRS also becomes the first cellular

systems allowing to transmit both in unicast and multicast

mode, implementing MBMS. With MBMS, up to 6 time slots

can be assigned in the downlink to a multicast/broadcast

session or up to 4 if feedback is used in the uplink, thus

consuming part of the available cell resources dedicated to

unicast transmissions.

As discussed in [12], even adopting the most robust CS it

is not possible to achieve a sufficient QoS without adopting

some additional technique; the full coverage with a net data

rate of 45 kbps is thus obtained through a single repetition

of all transmitted packets.

In Fig. 6, the refresh time related to MBMS over GPRS

at 45 kbps (denoted as MBMS-2G) is reported. Numerical

1061

results show that adopting TPEG RTM this technology does

not even allow to update the road classes from FRC 0

to FRC2 without exceeding the 5 minutes threshold. On

the contrary, if the short messages solution is adopted, the

“progressive coverage” of road segments can be completed

in less than 1 minute.

Note that the adoption of GPRS has the advantage to exploit

a deeply developed network, which guarantees a full cover-

age in any mobility condition; however, the transmission of

the smart navigator service occupies the resources of 6 to 12

voice calls (depending on the silence suppression efficiency).

2) MBMS over UMTS: UMTS represents the third gener-

ation (3G) of cellular systems. It is based on wideband-code

division multiple access (W-CDMA) and was conceived for

the transmission of both circuit and packet switched services

with QoS provision. From the release 6 UMTS also allows

to transmit data in broadcast and multicast modes adopting

the MBMS technology, with a bit-rate ranging from 64 kbps

up to a maximum of 384 kbps. MBMS consumes in this case

part of the available cell capacity, thus limiting the number of

available dedicated channels that can be established, that is

the number of resources dedicated to voice calls and unicast

data sessions. In particular, the base station is required to

pre-assign a certain amount of power to the MBMS services

depending on the coverage planning and the desired bit rate.

The assessment of the required power level is not an

easy task, since it depends on various aspects, including the

considered scenario, the base stations density, and the vehicle

mobility conditions. As an example, in [13] a minimum of

20.9% of the total power is needed to gain a 95% coverage

with QoS for a 64 kbps transmission in a vehicular environ-

ment where cars move at 3 km/h (higher speed allow better

performance due to higher diversity gain); a lower percentage

(4.8%) is needed if all terminals allow soft combining of up

to three radio links. In general, simulation results shows that

a 64 kbps transmission is practically feasible without exploit-

ing some transmission diversity, although it heavily impacts

on the system capacity, while a 128 kbps transmission is

feasible only if diversity techniques are adopted.

In Fig. 6, the refresh time for the envisioned service is

shown adopting MBMS over UMTS at 64 and 128 kbps (de-

noted as MBMS-3G 64k and MBMS-3G 128k, respectively).

Only the 128 kbps data rate allows a full refresh in less than

five minutes adopting TPEG RTM, while both solutions are

able to guarantee a refresh time lower than one minute if the

short message solution is adopted.

C. DVB-T

DVB-T is the transmission technology developed for the

digital terrestrial television by the DVB Project [14]. It

envisions a single-frequency network (SFN) consisting of

neighboring transmitters synchronized to each other, that

transmit identical moving picture experts group (MPEG)

transport streams with digital audio, video and data. To

guarantee a correct reception also in the presence of fre-

quency selective fading, DVB-T adopts the coded orthogonal

frequency division multiplexing (COFDM) [15], with either

6817 carriers, in the so-called 8K mode, or 1705 carriers in

the 2K mode. Several combinations of modulation schemes

and coding rates are allowed, with data-rates ranging from

4.98 to 31.67 Mbps. One of the mostly adopted DVB-

T configurations allows an useful bit rate of 24.13 Mbps,

which is shared among different television channels whose

bit rate ranges from 2 to 5 Mbps. For this reason, in the

numerical results we considered an useful bit rate of 2 Mbps,

which corresponds to the satisfactory (yet not excellent)

transmission of one television channel.

In Fig. 6, the refresh time for DVB-T is shown: it can be

observed that a refresh time lower than one minute can be

achieved adopting the “progressive coverage” strategy also

with the resource eager TPEG RTM. If all roads from FRC

1 to FRC 6 in the whole nation are considered, more than

two minutes are necessary.

Although the DVB-T technology has not been conceived

for an in-car usage, recent advances in the receiver design

[16] showed that it can work with a good performance also

at a vehicular speed of 180 Km/h. Nonetheless, in a dense

urban environment it can suffer a poor received power at the

street-level, especially in the presence of urban canyons. For

this reason in the following paragraph we also investigate

the DVB-H technology, which is, in some way, a version of

DVB-T designed for mobile usage.

D. DVB-H

The DVB-H standard has been developed in order to

broadcast MPEG streams also to mobile terminals. The

physical layer transmission is performed according to the

DVB-T standard, with the introduction of the 4K mode

with 4096 OFDM subcarriers; this allows for a doubled

transmitter distance in SFNs compared to the 2K mode, and

makes DVB-H less susceptible to Doppler frequencies in

case of mobile reception compared to the 8K mode. Also

for DVB-H, depending on the modulation and coding rate,

different data rates can be achieved, ranging from 4.98 to

31.67 Mbps. In the numerical results we considered an useful

bit rate of 384 Kbps, which corresponds to a H.264 video

stream used for deploying the mobile TV service to DVB-H

terminals.

The refresh time that can be achieved with DVB-H is

shown in Fig. 6: a refresh time of 80 seconds is obtained

adopting the “progressive coverage” strategy and the TPEG

RTM packet structure. A reduction of the number of updated

roads or a reduction of the packet length (8 bytes, for

instance) is needed if one minute maximum is targeted.

E. Broadcast systems comparison

So far we have considered “pure” broadcasting systems

(RDS-TMC, DVB-T, DVB-H) and “hybrid” broadcasting

systems (MBMS over cellular systems). Numerical results

show that, due to its scarce resource and consequent high re-

fresh time, RDS-TMC does not represent a suitable solution

for the envisioned service. In contrast, DVB-T and DVB-H

could be considered as candidate for the broadcasting of a

certain percentage of roads condition updates.

1062

MBMS over cellular systems has performance in between

RDS-TMC and DVB. It represents a valid solution for

the real-time broadcasting of information considering one

minute as the target refresh time only if short messages are

transmitted.

Let us observe, however, that the envisioned service is

based on the real-time collection of information from ve-

hicles, allowed by on-board cellular systems. This reason,

together with their widespread diffusion and their good per-

formance in high mobility scenarios, makes cellular systems

a valid solutions to support smart navigation.

VI. UNICAST TRANSMISSION

With unicast transmission technologies each driver could

receive personalized information, related to the average-

speeds of all road segments (except FRC 7) interested by

slowdowns along his way to the destination. In this case

the on-board navigator should previously inform the control

center about its route or at least its destination.

Although this solution allows to update only the interested

users, it also entails some drawbacks that would increase with

a higher penetration of the service: firstly, a dedicated unicast

communication is required also in the uplink direction;

secondly, the same information will be often sent to a not

negligible number of vehicles, wasting useful resources.

The strategy adopted to identify the roads of interest for

each vehicle must thus be carefully designed, since it sets

the trade-off between a sufficient picture of the road traffic

conditions and an oversized amount of transferred data both

in the downlink and the uplink directions.

In this paper we suppose to update the road segments

encompassed by an ellipse (as shown in Fig. 7) whose

focuses are the actual vehicle position and either the next

intermediate point or the final destination. In particular,

the final destination will be directly targeted only in the

case of a short travel, for instance shorter than 30 Km.

When, on the contrary, a long travel has to be planned,

the on-board navigator evaluates, first of all, the best route

according to the static information stored in its memory, then

it detects a number of intermediate points along the way

and, finally, it informs the control center about the next-to-

come intermediate point. According to the user preferences,

periodic updates can also be sent during the trip.

This strategy avoids the transmission of information re-

lated to road segments too far from the actual vehicle

position, which would be out of date when the vehicle

will get there. Moreover, since only the transmission of the

coordinates of two points is needed from the navigation

system to the control center, the amount of data transmitted

in the uplink is very small, thus limiting costs and resource

occupation.

The suitability of unicast technologies to support the above

described service is investigated hereafter, with particular

reference to GPRS and UMTS, which are actually the

most widespread technologies to guarantee full coverage in

mobility.

Fig. 7. The area considered for unicast updating varying the distancefrom the actual vehicle position and the targeted point (destination or nextintermediate point).

Numerical results will be provided in terms of the time

needed to complete the updates transmission, varying the

distance between the ellipse’s focuses (thus increasing the

number of interested road segments), with one focus always

taken in the city center of Florence (refer to Fig. 7). A ratio

of 1/2 is considered between the minor and the major radii

of the ellipse.

Similarly to the broadcast case, TPEG RTM is adopted for

the average-speeds update and 10% of the road segments un-

der investigation (those from FRC 1 to FRC 6 encompassed

by the ellipses) are supposed to suffer of some slowdowns.

A. GPRS

As recalled in Sec. V-B, GPRS represents the evolution

of GSM toward packet switched networks. As far as unicast

transmissions are concerned, GPRS allows a mobile station

to transmit on one to eight time slots per TDMA frame.

Channels are allocated only when data packets are sent

or received, then released after the transmission. For bursty

traffic this results in an efficient usage of radio resources

as multiple users can share one physical channel. GPRS

theoretically allows data rate up to 170 Kbit/s, depending

on the adopted code rate and the number of used time slots.

In Fig. 8 the time needed for an update of the 10% of road

segments from FRC 1 to FRC 6 inside the discussed ellipse

is given as a function of the distance between the focuses,

considering a data rate of 32 kbps. Such speed follows the

use of 4 time slots (i.e., of half the capacity of a carrier)

with the most robust coding scheme.

Numerical results show that the GPRS performance is

borderline with respect to the acceptable one: on one hand,

it provides sufficiently low latencies after the connection

setup (50 seconds are needed to complete the update for

a distance of 30 km between focuses); on the other hand,

however, a maximum of 2.3 or 19.8 requests can be served

per minute adopting an entire carrier (2 groups of 4 time

slots each) if the distance between the focuses is 30 or 5

km, respectively. It follows that depending on the amount

1063

5 10 15 20 25 3010

−2

10−1

100

101

102

Focuses distance [km]

Update

dura

tion [s]

GPRS 32 kbps

UMTS 64 kbps

HSDPA 7.2 Mbps

Fig. 8. Time needed to complete the update of 10% of roads adoptingeither GPRS at 32 kbps, UMTS at 64 kbps or UMTS-HSDPA at 7.2 Mbps,as a function of the focuses distance.

of users and the ellipse dimension the connection-setup time

could be annoying.

B. UMTS

UMTS represents the most performing cellular system

actually deployed, allowing unicast bit-rates beyond 10 Mbps

with the introduction of high speed downlink packet access

(HSDPA) in 3GPP Releases 5 [17]. Due to the adoption

of CDMA, the number of active channels in UMTS is a

consequence of the trade-off between coverage and capacity,

and the amount of resources occupied by each transmission

is given in terms of used power: On one hand, a higher

data rate as well as a higher distance from the base require

a higher power for a sufficient QoS; on the other hand, a

higher power reduces the cell capacity. The power is, in

fact, a limited resource at the base station (in downlink) and

each transmission turns into an interference to all other active

communications (in both directions).

In Fig. 8, the time required for an update of the 10%

of the road links inside the ellipse is shown, considering

UMTS data rates of 64 kbps and 7.2 Mbps. The former value

corresponds to the minimum data rate for an unicast data

transmission allowing full coverage and minimum resource

occupation, while the latter corresponds to the maximum

achievable data rate with HSDPA for the majority of ter-

minals actually available (it corresponds to users equipment

belonging to category 8 [18]).

With reference to the 64 kbps connection, we can observe

that differently from GPRS the delay never exceeds 30

seconds; the maximum number of users that can be served

per physical channel per minute in each cell is 2.3 or

19.8 if the distance between the focuses is 30 or 5 km,

respectively; the number of channels simultaneously active is

highly variable, depending on the network planning, the users

position, the resources exploited by the other common and

dedicated channels. In any case the adoption of the 64 kbps

channel would become critical with an increasing penetration

of the smart navigation service.

In contrast, the full usage of a 7.2 Mbps channel allows

negligible delays and up to 258.4 and 2227.3 requests per

minute for distances between the focuses of 30 and 5 km,

respectively. Note that these values represent upper bounds,

since such a high data-rate is possible only near the base

station, where the channel is highly reliable.

VII. CONCLUSIONS

In this paper we investigated the feasibility of frequent

(say real-time) traffic condition updates through broadcast

and unicast transmission technologies. Attention has been

focused on the amount of data to be transmitted and their re-

fresh time in order to allow smart navigation. Results showed

that only some technologies can guarantee the envisioned

service depending on the target refresh time. Moreover,

broadcast has to be preferred for high densities of vehicles,

whereas unicast UMTS transmission can be considered for

dedicated information at the expense of a capacity reduction

for other UMTS services.

ACKNOWLEDGMENTS

The authors would like to thank Prof. O. Andrisano for

motivating this work, G. Leonardi and T. Pavani for their

valuable support with the Tele Atlas data base.

REFERENCES

[1] “Cvis project,” Website, http://www.cvisproject.org/.[2] Website, www.car-to-car.org/.[3] Website, http://pegasus.octotelematics.com.[4] Website, www.tomtom.com/.[5] Website, http://www.tmcforum.com/.[6] Traffic and Traveller Information (TTI) TTI messages via traffic mes-

sage coding Part 1: Coding protocol for Radio Data System Traffic

Message Channel (RDS-TMC) using ALERT-C, ISO Std. 14 819-1.[7] Traffic and Travel Information (TTI) via Transport Protocol Expert

Group (TPEG) data-streams: Parts 1 to 6, ETSI Std. ISO 18 234.[8] Website, http://www.tpeg.org/.[9] V. Hiestermann, “Map-independent location matching certi-

fied by the AGORA-C standard,” Transportation Research

Part C: Emerging Technologies, vol. 16, no. 3, pp.307 – 319, 2008, emerging Commercial Technologies.[Online]. Available: http://www.sciencedirect.com/science/article/B6VGJ-4S0280N-1/2/b64ec2e00c364e0488866db160182047

[10] S. Cho, K. Geon, Y. Jeong, C.-H. Ahn, S. I. Lee, and H. Lee, “Realtime traffic information service using terrestrial digital multimediabroadcasting system,” Broadcasting, IEEE Transactions on, vol. 52,no. 4, pp. 550 –556, dec. 2006.

[11] Introduction of the Multimedia Broadcast/Multicast Service (MBMS)

in the Radio Access Network (RAN), ETSI Std. 3GPP TS 25.346.[12] L. Provvedi, C. Rattray, J. Hofmann, and S. Parolari, “Provision

of MBMS over the GERAN: technical solutions and performance,”in 3G Mobile Communication Technologies, Fifth IEE International

Conference on, 2004, pp. 494 – 498.[13] S-CCPCH performance for Multimedia Broadcast/Multicast Service

(MBMS), ETSI Std. 3GPP TR 25.803 v.60.0, 2005.[14] Website, http://www.dvb.org/.[15] ETSI EN 300 744 V1.6.1 (2009-01), ETSI Std., 2009.[16] C.-C. Wang, T.-J. Lee, H. K. Lo, S.-P. Lin, and R. Hu, “High-

sensitivity and high-mobility compact DVB-T receiver for in-carentertainment,” Consumer Electronics, IEEE Transactions on, vol. 52,no. 1, pp. 21 – 25, feb. 2006.

[17] H. Holma and A. Toskala, WCDMA for UMTS, 3rd Ed. Wiley, 2005.[18] UE Radio Access capabilities, ETSI Std. 3GPP TS 25.306 V9.1.0.

1064