An Anonymous Geocast Scheme for ITS Applications

Carsten B

uttner

1,2

and Sorin A. Huss

Advanced Technology, Adam Opel AG, R

usselsheim, Germany

Integrated Circuits and Systems Lab, Technische Universit

at Darmstadt, Darmstadt, Germany

Keywords:

Geocast, Vehicular Ad-hoc NETworks, Intelligent Transportation Systems, Anonymity, Location Privacy.

Abstract:

We propose a novel anonymous geocast scheme for Intelligent Transportation System (ITS) applications. The

main advantage of this scheme is that it allows an ITS Central Station (ICS) located in the Internet to send

messages to all ITS Vehicle Stations (IVSs) subscribed to a speciﬁc ITS application and located in a certain

geographic area. Thus, the messages are only distributed in the speciﬁed geographic area and not in a greater

region. Furthermore, it preserves in comparison to the state of the art the privacy of the IVSs by minimizing

the information about application subscriptions stored inside the network. When applying this scheme, no

entity is able to exploit the ITS applications of an IVS. Moreover, no entity except the ICS provisioning the

ITS application is able to exploit the IVSs subscribed to this service. We show how the proposed scheme can

be integrated in mobile networks like Long Term Evolution (LTE) and networks consisting of ITS Roadside

Stations (IRSs). Moreover, we compare it with the state of the art regarding the privacy of the IVSs, complexity

of the scheme, scalability, supported networks, and whether the common requirements for ITS applications

are fulﬁlled. In addition, a prototype applying the scheme for IRS networks is detailed. We demonstrate

the feasibility of the proposed scheme by evaluating the implemented prototype in the context of real-world

scenarios and hardware.

1 INTRODUCTION

Intelligent Transportation System (ITS) applications

like a weather hazard warning, wrong way driver

warning, trafﬁc jam ahead warning, or road works

warning require that the corresponding messages are

distributed in a speciﬁc geographic region, called dis-

semination area, where the message is of interest for

the present ITS Vehicle Stations (IVSs). The mecha-

nism where messages are distributed in a certain ge-

ographic region is called geocast (Navas and Imielin-

ski, 1997).

Given an IVS as the origin of such a message,

it is typically already located within the dissemina-

tion area. Therefore, it simply distributes the mes-

sage to all IVSs in communication range which are

part of the Vehicular Ad-hoc NETwork (VANET) us-

ing Dedicated Short Range Communication (DSRC).

These IVSs then further distribute the message in the

dissemination area by means of suitable routing algo-

rithms (Maihofer, 2004).

Besides of an IVS, an ITS Central Station (ICS)

may also be the origin of such messages. An ICS can

be, for example, a Trafﬁc Center or a Service Cen-

ter operated by an Original Equipment Manufacturer

(OEM). It may also have access to a meteorological

service or to a database of up-to-date road works in-

formation to generate the messages. Typically, an ICS

is not located inside the dissemination area of the gen-

erated messages. Therefore, the messages have to be

transported to the region ﬁrst. This can be done by

several communication technologies like mobile net-

works or DSRC. The IVSs located in the area may

then further distribute these messages.

Some ITS applications, like the ones provided by

the OEMs, are not distributed to all IVSs in the dis-

semination area. They may be only provided to a

subset like all vehicles of a certain brand or all sub-

scribers of a speciﬁc application. Messages of some

applications may further have a commercial value and

therefore require a special protection. Given that an

IVS does not have a high computational power on-

board, it makes sense that only the desired IVSs re-

ceive and process the messages. The dissemination

area of the messages may also be dynamic. An ICS

may, for example, warn about distinct weather haz-

ards in various areas at the same time. The dissemina-

tion area may in addition change over time. Another

special requirement of messages sent by ITS applica-

Büttner, C. and Huss, S.

An Anonymous Geocast Scheme for ITS Applications.

DOI: 10.5220/0005797501790189

In Proceedings of the 2nd International Conference on Information Systems Security and Privacy (ICISSP 2016), pages 179-189

ISBN: 978-989-758-167-0

179

tions is that they have a validity period, in which they

should be also sent to each IVS entering the dissemi-

nation area.

Long Term Evolution (LTE) is the current high

speed communication standard for mobile networks.

Different methods exist to distribute messages via

LTE to IVSs in a geographic area. However, none of

them is suitable to fulﬁll the requirements of the out-

lined ITS applications: they either do not scale with

the number of recipients or they are not able to au-

tomatically distribute messages to IVSs entering the

dissemination area. Furthermore, the procedure be-

comes rather complicated when different messages

have to be distributed in various frequently chang-

ing geographic areas at the same time. In addition,

they do not respect the privacy of the IVSs. When ex-

ploiting DSRC, ITS Roadside Stations (IRSs) within

the dissemination area and connected to the ICS may

also be applied to distribute the messages to relevant

IVSs. However, DSRC currently does not support the

addressing of a group of IVSs as the receiver of a mes-

sage. Therefore, the current mechanisms for mobile

networks and DSRC are not suitable to distribute ITS

messages to a group of IVSs in a given geographic

area.

In this paper we propose an Anonymous Geocast

scheme for ITS Applications (AGfIA), which enables

an ICS to distribute an ITS message to each IVS be-

longing to a group and located in or entering a certain

area which has been ﬁled as a patent (Buettner and

Huss, 2015). It can handle the distribution of differ-

ent messages at various, even overlapping, areas at the

same time. The proposed scheme works for distribu-

tion via both, mobile networks and DSRC. Moreover,

it protects the privacy of the IVSs, whereas no cen-

tral entity is able to track the exploited applications

of an IVS. This is done by minimizing the informa-

tion about application subscriptions of an IVS stored

within the network. We compare the proposed mech-

anism theoretically with the state of the art and, in

addition, we provide a prototype implementation of

the scheme created and evaluated on real DSRC hard-

ware.

The rest of the paper is structured as follows. In

Section 2 we discuss the requirements of ITS applica-

tions regarding a geocast. The related work on geo-

casts for ITS applications via mobile networks is re-

viewed in Section 3. We then propose the AGfIA ap-

proach in Section 4. Afterwards, we compare it with

the state of the art and present our real-world evalua-

tion in Section 5. Finally, we conclude in Section 6.

2 REQUIREMENTS

Different kinds of ITS applications require a geocast

mechanism to distribute messages. To support a wide

variety of such applications, a geocast mechanism

must fulﬁll various requirements. In the sequel we

discuss these requirements.

Multiple Applications: A geocast mechanism in

general introduces some overhead. In order to mini-

mize it, a geocast mechanism should be able to handle

quite different applications.

Receiver Groups: Usually an IVS does not employ

all available applications. Each IVS does just sub-

scribe to the applications it is interested in. In order

to transmit the messages only to the subscribers of an

application, a geocast mechanism should support the

addressing of a subset of all IVSs.

Content Type: Typical ITS messages consist of

small messages. Therefore, a geocast mechanism

does not need to support the transmission of a huge

amount of data.

Dissemination Area: Each ITS message dis-

tributed via geocast has a dedicated dissemination

area. Some applications, like a weather hazard warn-

ing, might intend to distribute messages in a large area

like a whole state, while others, like a particulate mat-

ter emission warning or road works warning, target

only a town or just a road section. The dissemination

area may also change over time. An application might

further distribute different messages to various areas

at the same time. In addition, these areas may overlap.

Therefore, it should be possible to specify both the

dissemination area and the granularity for each mes-

sage.

Validity Period: Distributed messages may have a

validity period of several minutes for, e.g., trafﬁc jam

ahead warnings, hours for, e.g., weather hazard warn-

ings or even days for, e.g., road works warnings. Dur-

ing this validity period the ITS message should be

transmitted to each IVS entering the dissemination

area. Accordingly, a geocast mechanisms should sup-

port the transmission of messages to all IVSs entering

the dissemination area.

Scalability: An ITS application may be used by a

huge number of IVSs. Consequently, a geocast mech-

anism should be able to scale for a large number of

receivers.

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

180

End-to-End Delay: Some ITS applications like a

wrong way driver warning require a real-time deliv-

ery of the messages in the dissemination area. There-

fore, a geocast mechanism should have an as small as

possible end-to-end delay.

Channel Load: In order to avoid unnecessary load

within the communication network, ITS messages

should be transmitted in an efﬁcient way.

3 RELATED WORK

In (Jodlauk et al., 2011) the authors propose a grid-

based geocasting scheme (GBGS) for ITS applica-

tions. They divide the surface of the world into rectan-

gles to deﬁne possible dissemination areas. The size

of each rectangle is adjusted according to the number

of IVSs within. When more IVSs than a threshold

value are present in a rectangle, it is subdivided into

two rectangles of equal size. If the number of IVSs

in two neighboring rectangles drops below another

threshold value, they are merged. Each IVS is aware

of the rectangle it is currently in. Every time an IVS

leaves a rectangle, its current position is transmitted to

a so-called Geo Messaging Server (GMS). On recep-

tion, the GMS determines the new rectangle the IVS is

located in and sends it back to the IVS. Therefore, the

GMS is all the time aware of the position of all IVSs.

An ICS aiming to sent a message to each IVS in a

geographic area needs to query the GMS for all IVSs

in the dissemination area ﬁrst. The server then deter-

mines and returns all IVSs located in the correspond-

ing rectangles. The disadvantage of this scheme is

clearly the central GMS, which is aware of the coarse

position of all IVSs and is therefore able to track them

and thus may infringe their privacy. Furthermore, the

scheme does not scale because each message has to be

distributed to each IVS via a single unicast message.

In addition, this scheme does not support the address-

ing of a group of IVSs in the ﬁrst place. However, this

feature was later on added as part of the CONVERGE

project (CONVERGE, 2015). In the evaluation sec-

tion we compare this scheme to our AGfIA approach.

In LTE the evolved Multimedia Broadcast Multi-

cast Service (eMBMS) (3GPP TS 23.246, 2013) can

be exploited to distribute data from a content provider

to a group of recipients in predeﬁned broadcasting ar-

eas by means of multicast. In order to apply eMBMS,

each application has to register an eMBMS User Ser-

vice at the Mobile Network Operator (MNO) ﬁrst. An

IVS aiming to exploit several applications has to reg-

ister for each application separately. eMBMS was

developed to download a huge amount of data or to

stream audio or video data from a radio or TV sta-

tion to many recipients. For this reason it is based

on multicast in order to save bandwidth. Therefore,

this scheme is not well-suited to distribute the rather

small ITS messages. In order to support the distribu-

tion of different messages in various broadcasting ar-

eas, one eMBMS session has to be initiated for each

broadcasting area, but this introduces a high complex-

ity. Furthermore, it is not possible to have overlapping

broadcasting areas. In addition, messages are not re-

peated automatically in order to inform IVSs entering

the broadcasting area. Consequently, the messages

have to be sent periodically from the content provider

to the MNO, which spreads them in the broadcasting

area. Obviously, this method is not very efﬁcient. We

compare this scheme with AGfIA in Section 5.

The authors of (Calabuig et al., 2014) compare

the LTE unicast and eMBMS transmission modes for

safety-related ITS applications. They further study

the conﬁguration of eMBMS for safety-related ITS

applications. Their proposed conﬁguration consists of

a central entity which receives all messages. It is ac-

cessible by all MNOs and distributes the messages via

all mobile networks covering the dissemination area.

The authors also state that a new data delivery method

for eMBMS is necessary to fulﬁll the requirements of

ITS messages. They conclude that eMBMS is more

efﬁcient in terms of resource consumption when com-

pared to unicast messages. However, this seams obvi-

ous, because less messages have to be transmitted in

multicast compared to unicast. Furthermore, they do

not consider multiple ITS applications with different

subscriber groups.

The transmission of ITS messages via LTE and

MBMS has also been studied in (Araniti et al.,

2013), (ETSI TR 102 962, 2012), and (Valerio et al.,

2008). However, none of them provides a solution

which fulﬁlls all requirements of ITS applications.

Three methods of cellular geocast which form the

state of the art were studied in (Jodlauk et al., 2011).

In the ﬁrst method a central server, aiming at the dis-

tribution of a geocast message, sends an inquiry to all

clients requesting their location. From the response,

the server selects the relevant clients and sends the

message to them. This method clearly does not scale

for a large amount of clients and features a consider-

able delay in message delivery. The second method

requires all clients to send periodical position updates

to a central server which stores them in a database.

When a message shall be sent to all clients in a geo-

graphic region, the central entity queries its database

and sends the message to the relevant clients. This

method does not suffer from the additional delay of

the ﬁrst method. However, it introduces some blur

An Anonymous Geocast Scheme for ITS Applications

181

on the position data, because some clients might have

moved away since the last position update. In the third

method the clients autonomously update their current

location at the central entity when they moved a cer-

tain distance. This improves the accuracy of the posi-

tions in comparison to the second method. Nonethe-

less, it still has scalability problems as the ﬁrst two

methods. Last but not least, all these methods do not

protect the location privacy of the IVSs.

4 ANONYMOUS GEOCAST

ITS applications like a weather hazard warning re-

quire a geocast to distribute relevant messages to all

IVSs located in a speciﬁc geographic area. As com-

munication technologies to perform the geocast we

consider LTE for mobile networks and IRS networks

for DSRC. In LTE the clients are connected to evolved

NodeBs (eNodeBs) which are linked to the core net-

work of the MNO. We assume a Mobile Network

Central Station (MN CS) as part of the core network

to handle all incoming ITS geocast messages. An

IRS network consists of one or multiple ITS Road-

side Stations, which are connected to one IRS Central

Station (IRS CS). This central station handles like the

MN CS for mobile networks all incoming ITS geocast

messages. In case that the network consists of only

one IRS, the IRS CS may also be part of this IRS.

IVSs communicate with the IRS network if they are

in its communication range. Both, the Mobile Net-

work Central Station and the IRS Central Station, are

connected to the Internet.

The geocast scheme introduced in the sequel may

be exploited for mobile networks like UMTS and LTE

as well as for IRS networks. It fulﬁlls the special re-

quirements of ITS applications and, in addition, pro-

tects the privacy of each IVS. The mechanisms to reg-

ister for ITS geocast messages as well as the way how

the messages are distributed are described for LTE

and IRS networks in the sequel. Furthermore, a suit-

able message format for both network types, a possi-

ble usage-based billing mechanism, and an example

are detailed.

4.1 IVS Registration

In order to receive geocast messages each IVS has to

independent of the ITS applications an IVS exploits.

For the two network types different mechanisms are

applied. They are detailed as follows.

4.1.1 LTE

The registration in LTE can be done like for eMBMS,

where the devices join multicast groups in order to

receive messages belonging to this group. In com-

parison to eMBMS not only one application utilizes

this multicast group. Instead, all ITS applications are

handled by the same multicast group. Therefore, each

IVS has to join only one multicast group, independent

of the number and types of ITS applications it runs.

This protects the privacy of the ITS Vehicle Stations

because the MNO does not learn the applications an

IVS exploits. Therefore, the subscribed IVSs remain

anonymous to the MNO. Furthermore, we assume

a continuous eMBMS service to minimize the time

overhead for setting up an eMBMS session. A time

sequence diagram showing the registration scheme is

depicted in the upper part of Figure 2.

4.1.2 IRS

For IRS networks no registration is necessary because

the ad-hoc characteristic of the network does not need

any registration. As a consequence, without a regis-

tration the operator of an IRS network is not able to

track the IVSs subscribed to a certain ITS application.

Therefore, the receiving IVSs stay anonymous.

4.2 Sending Messages

Whenever an ITS Central Station aims to distribute

a message in a geographic area, it has to lookup the

present mobile and IRS networks in the area ﬁrst. To

achieve this, we assume the ICS has a coverage map

of all mobile and IRS networks it has a contract with.

After all relevant networks have been identiﬁed, the

ICS passes the message containing the dissemination

area, an distribution frequency, an expiry time, and

an Application ID (AID) to the central station of each

network. The dissemination area deﬁnes the region

in which the message shall be spread. To distribute

the message also to IVSs entering the dissemination

area, they are repeated at the given distribution fre-

quency until the expiry time. The AID identiﬁes an

ITS application uniquely and is necessary for an IVS

in order to determine if the particular message is rele-

vant or not. The message distribution by the different

network types is illustrated in Figure 1 and the corre-

sponding sequence diagram in the lower part of Fig-

ure 2. We describe it in the sequel.

4.2.1 LTE

In order to handle ITS geocast messages in LTE a Mo-

bile Network Central Station is necessary. It consists

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

182

eNodeB

IRS

IVSICS

IRS CS

MN CS

Lookup eNodeBs &

Forward

Store & Send

periodical

Lookup IRSs &

Forward

Store & Send

periodical

Generate

message

Unicast

Xcast

Multicast

IRS Network

LTE

Figure 1: Message distribution in AGfIA.

of a database, containing the position, communication

range, and address of each eNodeB (eNB) within the

network. Each time an ICS aims in distributing an

ITS message in a certain area, it passes the messages

to the MN CS. There the relevant eNodeBs to dis-

tribute the message are identiﬁed ﬁrst. Then, the geo-

cast message is forwarded to this eNodeBs by means

of Xcast (Boivie et al., 2007). Upon reception the

eNodeB stores the message locally. All locally stored

messages are sent at the given frequency to all IVSs in

communication range belonging to the ITS multicast

group until they expire.

This mechanism protects the privacy of the IVSs

since each IVS member of the ITS multicast group for

ITS applications receives the message. Therefore, the

MNO is not able to determine which IVS processes

the messages and consequently can not get the ap-

plications exploited by an IVS. Furthermore, the IVS

does not periodically send its position to a new central

entity. This prevents tracking of IVSs.

4.2.2 IRS

For AGfIA over DSRC, the geocast messages are

passed from the ICS to the IRS Central Station. The

IRS CS has access, like the Mobile Network Cen-

tral Station in LTE, to a database containing position,

communication range, and address of each of its IRS

in order to select the relevant Intelligent Roadside Sta-

tions for distribution. After selection, the messages

are forwarded like in LTE via Xcast to these IRSs.

There the message is stored locally and sent periodi-

cally according to the given frequency to all IVSs in

communication range until it expires.

Considering that the IRS does not get any feed-

back which IVS in communication range processes

the received message, no entity is able to determine

the applications exploited by a certain IVS. There-

fore, the distribution of geocast messages over IRS

networks protects the privacy of the IVSs too.

ICS

MN CS /

IRS CS

eNodeB /

IRS

IVS

IVS Registration

Seding messages

Join eMBMS

Multicast group

Message + infos

Distribute to

relevant eNBs/IRSs

Periodical

multicast messages

Store message

locally

Figure 2: Time sequence diagram.

4.3 Message Format

An important property of the exploited message for-

mat is that it can be applied for both communication

technologies. Therefore, it is simple for the ITS cen-

tral station and ITS Vehicle Station to handle the mes-

sages. The ICS needs to create only one message and

can provide it to all networks. The IVS may parse

the message in the same way, independent of the ap-

plied communication technology. Furthermore, an

IVS may simply forward a message received by LTE

to other IVSs via DSRC without the need to convert

it.

We apply the GeoNetworking message format

as standardized in (ETSI EN 302 636-4-1, 2014).

This format was developed to exchange messages by

means of DSRC between IVSs or between IVSs and

IRSs. Therefore, it is well-suited for a geocast over

an IRS network. We now discuss how it can be also

utilized for a geocast over LTE. GeoNetworking sup-

ports unicast, anycast, and broadcast messages. For

the outlined scenario it is necessary to support the ad-

dressing of a group of IVSs. Hence, we added support

for multicast messages by adapting the GBC/GAC

(Geographically Scoped Broadcast / Geographically

Scoped Anycast) header. All GeoNetworking mes-

sages are secured by cryptographic mechanisms in or-

der to protect their content. Besides of the adapted

header aimed to support multicast, we apply the mes-

sage format as denoted in (ETSI EN 302 636-4-1,

2014) and exploit the Basic Transport Protocol (BTP-

A) (ETSI EN 302 636-5-1, 2014) as transport proto-

col.

The detailed format of the header supporting mul-

ticast is illustrated in Figure 3. The changes compared

to the original GBC/GAC header are as follows. We

ﬁrst removed the location of the source, because it is

an ICS whose location is not relevant for the receiving

or forwarding IVSs. Additionally, we utilize the re-

served octets to encode the Application ID (AID) into

the message and add ﬁelds to embed the frequency

An Anonymous Geocast Scheme for ITS Applications

183

32 Bit

SN AID

GEOAREAPOS_LATITUDE

GEOAREAPOS_LONGITUDE

DISTANCE_A DISTANCE_B

ANGLE FREQUENCY

EXPIRY_TIME

Figure 3: Detailed message format of the geographically

scoped multicast.

(FREQUENCY) and expiryTime (EXPIRY TIME) of

the message. The multicast routing is added by en-

coding the AID into the message. Therefore, an IVS

which does not support the corresponding application

can drop the message without further processing. The

frequency indicates how often the message shall be

distributed to the IVSs in communication range by ei-

ther an IVS, IRS, or eNodeB. The message is valid

until the point in time encoded in expiryTime. After

this point in time, all entities will drop and no longer

distribute the message. All other ﬁelds are applied

as in the original GBC/GAC message. The sequence

number (SN) indicates the index of the sent packet

and is utilized to detect duplicate GN packets (ETSI

EN 302 636-4-1, 2014). The remaining ﬁelds are

applied to describe the geometric shape of the dis-

semination area as deﬁned in (ETSI EN 302 636-4-1,

2014).

This message format can be applied for both LTE

and IRS networks to deliver geocast messages to a

group of IVSs. When they are distributed over mobile

networks, the GeoNetworking message is the payload

of the IP connection. For DSRC the GeoNetworking

message is also used within the Network and Trans-

portation Layer, respectively, to deliver the message.

In both cases the receiving IVS parses the GeoNet-

working message by its G5 stack and checks if the

message is relevant. The relevance check is done by

comparing the included AID to its supported AIDs.

Figure 4 illustrates the location of the GeoNetwork-

ing message in the OSI layers for LTE and DSRC, re-

spectively. Furthermore, if an IVS receives a GeoNet-

working message via LTE, it is able to redistribute it

via DSRC without any modiﬁcation.

4.4 Introduced Overhead

When messages are transmitted wireless, all entities

in communication range receive the message. Mes-

sages are dropped at network layer when eMBMS is

applied and the receiver is not part of the correspond-

ing multicast group. In the proposed scheme, each

IVS will receive the messages of all ITS applications,

independent if it is subscribed to the application or

not. This introduces an overhead because all received

messages need to be forwarded to the DSRC stack.

DSRC

MAC

LLC

GeoNet.

Message

PHY

LTE

PHY

MAC

RLC

PDCP

GeoNet.

Message

Physical Layer

Link Layer

Network / Transport

Layer

Payload

Figure 4: Comparison of the GeoNetworking message lo-

cation within the LTE and DSRC layers.

There the messages are dropped if they are not rel-

evant. Whenever messages are received via DSRC,

all incoming messages are checked for relevance at

network level. This analysis includes an inspection

of the messages geographic region. Therefore, this

check needs to be extended in order to drop messages

from not supported applications at network layer.

Subsequently, there is no overhead introduced

when messages are received via DSRC. For LTE each

message needs to be forwarded to the DSRC stack.

However, these messages are only distributed a few

times per minute and have a size of less than 3000

bytes. Furthermore, it is not expected that several

dozens of messages are valid in the same region at

the same time. Therefore, AGfIA does not introduce

a signiﬁcant overhead.

4.5 Billing

For economical reasons it must be possible to bill the

network usage of geocast messages. In the outlined

scheme an ICS may pay a basic amount for the ser-

vice provision of the operators. Furthermore, the ICS

might be billed by the number of messages it sends,

depending on the size of the dissemination area, send-

ing frequency, and validity period of the messages.

Therefore, the network operators do not need any in-

formation about the IVS exploiting the messages or

even the number of receivers of a message. Accord-

ingly, it is not necessary for the network operators to

track the IVSs by exploiting a certain ITS application

for billing. Therefore, this scheme protects the pri-

vacy of the ITS Vehicle Stations.

4.6 Example

We illustrate the advantages of the described geocast

scheme by way of the example given in Figure 5. The

ﬁgure shows the two hazards Hazard

and Hazard

like an icy road and roadworks. The rectangles illus-

trate the dissemination areas of possible warning mes-

sages. Furthermore, the eNodeBs and IRSs covering

the area are depicted together with their communica-

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

184

Hazard

IRS

eNodeB

IRS

Hazard

eNodeB

Figure 5: Message distribution example.

tion range. When exploiting the proposed scheme,

only the eNodeBs and IRSs covering the respective

dissemination area by their communication range dis-

tribute the message to the IVSs.

In the example IRS

, IRS

, and eNodeB

cover the

dissemination area of Hazard

, while IRS

, eNodeB

and eNodeB

cover the area of Hazard

. Since IRS

and eNodeB

are covering both areas, they distribute

both messages. The other IRSs and eNodeBs cover-

ing only one of the areas distribute just this message.

Consequently, the eNodeBs and IRSs not covering

any dissemination area do not forward any message.

Therefore, the messages are only distributed by the

relevant eNodeBs and IRSs. Moreover, only the black

ITS Vehicle Stations exploit the application warning

of Hazard

, while the white ones utilize the applica-

tion that distributes information about Hazard

. The

gray ones illustrate IVSs exploiting both applications.

Only the IVSs applying the corresponding application

display a warning to the driver. All other IVSs dis-

card the message. The selection of the relevant IVSs

is done without having knowledge on which IVS ex-

ploits any speciﬁc ITS application at the network, nor

knowing which IVSs are located within the dissemi-

nation area. Therefore, the privacy of each IVS in the

dissemination area is preserved.

5 EVALUATION

For evaluation purposes we compare the privacy,

complexity, and scalability ﬁgures as well as sup-

ported network types and the fulﬁlled ITS require-

ments of the proposed scheme to the grid based geo-

casting scheme and eMBMS. In addition, we imple-

mented AGfIA for IRS networks and evaluated its

properties on top of real-world vehicles.

5.1 Privacy

In order to compare the privacy of the different

schemes, we analyze which entities are getting po-

sitions updates from the IVSs and therefore are able

to track them. Furthermore, we analyze if it is pos-

sible to identify the applications utilized by a certain

IVS or all ITS Vehicle Stations subscribed to a spe-

ciﬁc application.

The MNO is in all schemes able to track the IVSs.

The MNO needs to know by design the location of a

device to, e.g., forward a voice call or to route IP traf-

ﬁc to the device. Schemes like Privacy Augmented

LTE as proposed in (Angermeier et al., 2013) may

possibly prevent tracking by the MNO. However, they

are currently not available in practice and it is there-

fore not possible to apply them yet. For the grid based

geocasting scheme the central GMS is in addition to

the MNO aware of the positions of each IVS. This

is a major privacy drawback compared to the other

schemes. In case that AGfIA is applied for distribu-

tion over IRS networks, a tracking of the IVSs is ex-

cluded.

An attacker aiming at identifying the applications

utilized by a certain ITS Vehicle Station or all IVSs

subscribed to a speciﬁc application can gain this in-

formation when eMBMS or GBGS is applied. In both

schemes a local database containing the subscribers

of each application exists. For eMBMS the MNO

hast knowledge on which IVS is subscribed to a spe-

ciﬁc service, whereas for the GBGS the geo messag-

ing server is aware of the applications an IVS utilizes.

In AGfIA it is not possible to determine which IVSs

subscribed to a certain application because this rela-

tion is not stored anywhere. It is only possible for

the MNO to determine all IVSs that are utilizing ITS

applications. However, this is no privacy threat at all

since the MNO knows anyway by its contracts which

entities are IVSs.

5.2 Complexity

To assess the complexity of the schemes we compared

the procedures for application registration, geocasting

a message in an additional area, utilizing an additional

network to distribute the messages, and updating the

position information of the IVS within the network.

The results of the complexity evaluation are shown in

Table 1.

In case that an ITS Vehicle Station aims to regis-

ter or unregister for an application, it has to send an

additional notiﬁcation message to a central entity for

eMBMS and GBGS. There, the relation between the

IVS and application is either created or deleted. This

An Anonymous Geocast Scheme for ITS Applications

185

Table 1: Complexity evaluation.

eMBMS GBGS AGfIA

Registration Per applications Per applications Once

New Area Additional session Receiver lookup eNB lookup

Additional Network 1 Additional message Nothing 1 Additional message

New Position Nothing 1 message to central entity Nothing

Table 2: Scalability evaluation.

eMBMS GBGS AGfIA

ICS to network 1 per message and receiver (U) 1 per message (U) 1 per hazard (U)

Within network 1 per router (M) 1 per receiver (U) 1 per router (X)

to IRSs / eNodeBs 1 per eNodeB (M) 1 per receiver (U) 1 per eNodeB / IRS (X)

to IVSs 1 per eNodeB (M) 1 per receiver (U) 1 per eNodeB / IRS (M)

is not necessary in AGfIA, because each IVS regis-

ters itself only once for all ITS applications and not

for each application separately.

Each time an ICS intends on broadcasting a mes-

sage in a new area, which happens quite often for ITS

applications, an additional session has to be created

if eMBMS is applied. For GBGS all IVSs in the new

area have to be selected at the GMS, which may result

in a considerable effort. For AGfIA only a lookup for

all relevant eNodeBs and IRSs in the new area has to

be made. Therefore, AGfIA has a lower complexity

than both eMBMS and GBGS when messages shall

be distributed in a new area.

When the message shall be distributed via an ad-

ditional network, one additional message has to be

sent to this network in case of eMBMS or AGfIA. For

GBGS nothing has to be done, because each message

is sent to each IVS individually, independent of the

network it is registered at.

For eMBMS and GBGS the IVS does not need

to do anything when it changes the eNodeB. Every

position update is handled automatically by the mo-

bile network. When GBGS is applied, the IVS has in

addition to regularly report its position to the central

GMS.

5.3 Scalability

An ITS geocast message might be sent to a large num-

ber of receivers. Therefore, it is important that the

applied geocasting scheme does scale with the num-

ber of receivers. Therefore, we compared the outlined

scheme with eMBMS and the GBGS regarding the

number of messages the ICS needs to send to the net-

work operator, the amount of messages within the net-

work of the network operator, the number of messages

received by the IRS or eNodeB, and the messages sent

from the network to the IVSs. The results of the scal-

ability evaluation are shown in Table 2, whereas U

stands for unicast, M for multicast, and X for Xcast

messages, respectively.

For eMBMS, the ICS has to pass one message

to the network each time a message shall be sent to

the IVSs. For the grid based geocasting scheme one

message needs to be sent to the network for each

IVS at each point in time a hazard message needs

to be distributed. When AGfIA is applied, only one

message for each hazard needs to be sent to the net-

work no matter of how often it has to be forwarded

to the IVSs. Therefore, AGfIA scales better than the

other schemes mentioned. However, eMBMS per-

forms better than GBGS in terms of scalability.

For the distribution of the messages within the net-

work, eMBMS applies multicast, whereas almost one

message is processed by each router. In contrast, one

message per receiver is sent in case of GBGS. AG-

fIA does use Xcast to distribute the messages within

the network and needs accordingly almost one mes-

sage per router. Therefore, both eMBMS and AGfIA

scale much better than GBGS within the distributing

network.

One message is forwarded to the eNodeB or IRS,

respectively, in case of eMBMS and AGfIA. When

GBGS is applied, one message per receiver is sent to

the eNodeBs and IRSs of the network, which results

in considerably more messages compared to the other

schemes.

The messages are distributed by means of multi-

cast from the eNodeBs and IRSs of the network to the

IVSs if eMBMS or AGfIA is applied. For the GBGS

scheme the messages are distributed by means of uni-

cast to each receiver, which requires more messages

compared to multicast.

This evaluation shows clearly that eMBMS and

AGfIA do scale better than the GBGS. In these

schemes the number of messages does not depend on

the number of receivers, but only on the size of the ge-

ographic area and the number of eNodeBs and IRSs

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

186

Table 3: Comparison of the fulﬁlled requirements.

eMBMS GBGS AGfIA

Multiple Appl. o + +

Receiver Groups o + +

Content Type o + +

Dissem. Area - o +

Validity Period o o +

Scalability + - +

End-to-End Delay + o +

Channel Load + - +

located within. For AGfIA a larger message header

is applied within the network to enable Xcast in com-

parison to eMBMS. However, AGﬁA requires only

one message per hazard from the ICS to the MNO,

whereas for eMBMS the message has to be sent peri-

odically to the MNO.

5.4 Supported Networks

If a scheme is able to support different kinds of net-

works, it may have a better coverage and therefore it

may reach more ITS Vehicle Stations. Furthermore,

an ICS might have a better choice of networks to uti-

lize for message distribution. Our analysis shows that

eMBMS can only be applied to LTE networks, there

is no support for DSRC communication. GBGS can

be utilized for transmissions over LTE and IRS net-

works if the IVS and IRS network do support IPv6

over GeoNetworking. In contrast, AGfIA enables the

transmission over both LTE and IRS networks with-

out the limitation on IPv6 support in DSRC.

5.5 Requirements

We evaluated which of the previously outlined re-

quirements for ITS applications are fulﬁlled by the

different schemes and discuss the results in the sequel.

A summary is presented in Table 3.

eMBMS does fulﬁll the requirements for scalabil-

ity, end-to-end delay, and channel load. It may also

support multiple applications, receiver groups, and

content type suitable for ITS applications and validity

periods of messages. However, an additional effort

is necessary to meet these requirement. Overlapping

dissemination areas that may change over time are not

supported by eMBMS, however.

The grid based geocasting scheme enables mul-

tiple applications in the ﬁrst place and it was ex-

tended in to support receiver groups and is thus well-

suited for ITS messages. However, the dissemination

area may be in certain constellations much larger than

necessary. A validity period in which messages are

frequently distributed to all relevant IVSs may only

be supported at an additional effort. Because it dis-

tributes all messages by means of unicast, it does not

scale with the number of receiving IVSs, the channel

usage is not efﬁcient, and it features rather high end-

to-end delay values.

In contrast, the advocated anonymous geocast

scheme for ITS applications fulﬁlls all outlined re-

quirements.

5.6 Experimental Evaluation

For the real-world evaluation we implemented soft-

ware to integrate the proposed scheme into IRS net-

works consisting of one IRS and of IVSs equipped

with DSRC communication. We evaluated the soft-

ware prototype in different realistic scenarios.

5.6.1 Implementation

The implementation was done as part of the work

documented in (Bartels, 2015) and consists of two

Java programs running on the IRS and each IVS, re-

spectively. Both programs utilize a GeoNetworking

stack written in Java. The one running at the IRS CS

gets as input the distribution information from an ICS.

As output it distributes the message via DSRC to the

IVSs in communication range. The IVS-related pro-

gram takes as input the AID of the running ITS ap-

plications, the current position of the IVS, and the re-

ceived messages. On reception, it parses the messages

and evaluates them regarding their relevance. To con-

sider a message as relevant, the ITS Vehicle Station

has to be located inside the relevance area, it runs

the corresponding ITS application, and the message

at hand is not expired. The relevance area is encoded

into the message and describes the actual warning re-

gion of the event. Therefore, this area is in general

smaller than the dissemination area.

5.6.2 Measurement setup

Our evaluation setup consist of two IRS networks fea-

turing one IRS each. The IRS also runs the IRS CS.

Each IVS and IRS consists of an Application Unit

(AU) and a Communication Unit (CCU): the AU runs

the application software, whereas the CCU is respon-

sible to send and to receive the DSRC messages. Both

units are connected via Ethernet.

5.6.3 Results

Within the outlined setup we evaluated several basic

and realistic scenarios. The principles of the basic

An Anonymous Geocast Scheme for ITS Applications

187

App. 1

App. 2

(a) Scenario A (b) Scenario B

App. 1

App. 2

App. 1

App. 2

(a) Scenario C (b) Scenario D

Figure 6: Basic evaluation scenarios.

scenarios are depicted in Figure 6. Scenario A con-

sists of a message from Application 1, which is out-

side of the vehicles route, whereas in Scenario B the

message from Application 2 is on the route of the ve-

hicle. Scenario C contains messages from different

applications, where not all are on the route of the vehi-

cle. The reception and processing of multiple overlap-

ping messages from different applications are tested

by Scenario D.

We ran several different tests on the basic sce-

narios. We varied the AIDs an IVS supports from

those applications not applied in the scenario up to

all AIDs of the message. To evaluate the message

validity check we ran tests with valid messages, ex-

pired messages, and messages that will be valid in the

future. The evaluation of the different scenarios and

conﬁgurations showed that the IVSs running the par-

ticular application consider a message as relevant only

in case that they are within the relevance area of the

message and the message is still valid.

As an example, a realistic scenario around

usselsheim, Germany is depicted in Figure 7. The

scenario features two IRS networks, IRS1 and IRS2,

respectively. A possible route of an IVS is drawn in

red aiming from R

usselsheim city towards a motor-

way.

In this scenario three messages denoted as

message

, message

, and message

are distributed to

the IVSs, each with a different Application ID. The

relevance area of the messages is indicated by the

ﬁlled shape surrounding the message name. The big-

ger enclosing shape indicates the dissemination area

of the messages. message

may be, for example, an

icy road warning. Therefore, its shape is enclosing the

icy road. The dissemination area has the same shape

but covers a bigger area. message

located in the cen-

ter of the city may be a notiﬁcation about road clo-

sures due to a big event. To inform all IVSs reaching

message

IRS

Figure 7: Example of a real-world evaluation scenario.

the center, the dissemination area covers the whole

city. The third message warns about a trafﬁc jam

eastbound on the highway located south to the city.

Therefore, the dissemination area is only extended

towards west, where the IVSs reach the trafﬁc jam.

Because of the large dissemination area of the sec-

ond message, it is in reach of both IRSs and is there-

fore distributed by all of them. Only IRS

is located

within the dissemination area of the icy roads warn-

ing. Therefore, only this IRS is distributing the mes-

sage. For the trafﬁc jam ahead warning only IRS

located within the dissemination area and distributes

the message.

This scenario clearly demonstrates the main ad-

vantage of AGfIA: Only the IRSs and eNodeBs lo-

cated within the dissemination area of a certain mes-

sage distribute the message. In contrast, even IRSs or

eNodeBs in overlapping areas distribute all relevant

messages. In addition, only the ITS Vehicle Stations

exploiting the corresponding application process the

message. All other IVSs drop the messages at net-

work layer. Hence, we proved that AGfIA works well

on real devices.

6 CONCLUSION

In this paper we proposed AGfIA, an anonymous geo-

cast scheme for ITS applications. This scheme allows

to send messages via various communication infras-

tructures to a all IVSs belonging to a speciﬁc group

and being located within a certain area, without know-

ing which IVSs are present. Moreover, no entity is

able to determine the applications exploited by a cer-

tain IVS or to identify all IVSs subscribed to a speciﬁc

ITS application. Furthermore, the same message for-

mat can be applied for rather different communication

technologies. We detailed on how the scheme works

in terms of registration, message distribution, billing,

and how the proposed message format looks like.

As data format we took the GeoNetworking mes-

sage as standardized for DSRC and extended it to sup-

port multicast aimed to efﬁciently address a group of

ICISSP 2016 - 2nd International Conference on Information Systems Security and Privacy

188

IVSs. Furthermore, we compared this novel scheme

regarding privacy, complexity, scalability, and the re-

quirements of ITS geocast applications to both eM-

BMS and GBGC. Additionally, we implemented the

scheme for DSRC, set up experimental IRS networks,

and evaluated the prototype software on top of real

IVSs. The presented results show that the AGfIA sys-

tem is well-suited for an efﬁcient and at the same time

privacy-preserving distribution of ITS messages to a

group of ITS Vehicle Stations located within a certain

area.

ACKNOWLEDGEMENT

This work was funded within the project CON-

VERGE by the German Federal Ministries of Edu-

cation and Research as well as Economic Affairs and

Energy.

REFERENCES

3GPP TS 23.246 (2013). 3rd Generation Partnership

Project; Technical Speciﬁcation Group Services and

System Aspects; Multimedia Broadcast/Multicast

Service (MBMS); Architecture and functional de-

scription (Release 12).

Angermeier, D., Kiening, A., and Stumpf, F. (2013).

PAL - Privacy Augmented LTE: A Privacy-preserving

Scheme for Vehicular LTE Communication. In Pro-

ceeding of the 10th ACM International Workshop on

Vehicular Inter-networking, Systems, and Applica-

tions, VANET ’13.

Araniti, G., Campolo, C., Condoluci, M., Iera, A., and

Molinaro, A. (2013). LTE for vehicular networking: a

survey. IEEE Communications Magazine.

Bartels, F. (2015). Senden und Empfangen von C2X-

GeoMulticast-Nachrichten. Technical report, Rhein-

Main University of Applied Sciences.

Boivie, R., Feldman, N., Imai, Y., Livens, W., and Ooms,

D. (2007). Explicit Multicast (Xcast) Concepts and

Options. RFC 5058.

Buettner, C. and Huss, S. A. (2015). Verfahren zum

Verbreiten einer Nachricht. Patent application, DE

102015009599.4.

Calabuig, J., Monserrat, J., Gozalvez, D., and Klemp, O.

(2014). Safety on the Roads: LTE Alternatives for

Sending ITS Messages. IEEE Vehicular Technology

Magazine.

CONVERGE (2015). Architecture of the Car2X Systems

Network. Deliverable D4.3.

ETSI EN 302 636-4-1 (2014). Intelligent Transport Systems

(ITS); Vehicular Communications; GeoNetworking;

Part 4: Geographical addressing and forwarding for

point-to-point and point-to-multipoint communica-

tions; Sub-part 1: Media-Independent Functionality.

ETSI EN 302 636-5-1 (2014). Intelligent Transport Systems

(ITS); Vehicular Communications; GeoNetworking;

Part 5: Transport Protocols; Sub-part 1: Basic Trans-

port Protocol Functionality.

ETSI TR 102 962 (2012). Intelligent Transport Systems

(ITS); Framework for Public Mobile Networks in Co-

operative ITS (C-ITS).

Jodlauk, G., Rembarz, R., and Xu, Z. (2011). An Op-

timized Grid-Based Geocasting Method for Cellular

Mobile Networks. In Proceedings of the 18th ITS

World Congress.

Maihofer, C. (2004). A survey of geocast routing protocols.

IEEE Communications Surveys Tutorials.

Navas, J. C. and Imielinski, T. (1997). GeoCast - Gographic

Addressing and Routing. In Proceedings of the 3rd

annual ACM/IEEE international conference on Mo-

bile computing and networking, MobiCom ’97.

Valerio, D., Ricciato, F., Belanovic, P., and Zemen, T.

(2008). UMTS on the Road: Broadcasting Intelligent

Road Safety Information via MBMS. In Proceeding

of the IEEE Vehicular Technology Conference, VTC

Spring 2008.

An Anonymous Geocast Scheme for ITS Applications

189