1

Vehicle to infrastructure communication with today’s telecommunication systems 1

André Nieuwland (Flanders’ DRIVE), Philippe Dobbelaere (Alcatel-Lucent Bell N.V.), 2

Stephane Petti (Mobistar), Christian Ress (Ford) 3

Abstract 4

Today’s cellular technology can already be used to realize (a set of) connected driver assistance 5

functions. We focus in the paper on how the network architecture should look like to support these 6

functions, and how extensions can be made to the network to alleviate any bottlenecks. We focus on 7

system wide optimizations to minimize the amount of data to be sent over the wireless 8

communication link to the vehicle, and make a comparison between cellular systems and WLANp 9

(IEEE 802.11p) with respect to deployment. 10

11

Introduction 12

One of the ways to increase traffic safety is by the application of cooperative driver assistance 13

functions. These cooperative functions provide the driver with additional information such that 14

accidents can be prevented. E.g. infrastructure or vehicles could send or relay warning messages to 15

other vehicles for dangerous situations such as slippery road conditions or obstacle hazards ahead. 16

The communication protocol proposed for communication between vehicles is the IEEE 802.11p 17

standard, also known as WLANp. This standard is designed for fast, time critical communication and 18

uses an open access network. 19

Alternatively, vehicles could communicate with ‘the infrastructure’ to obtain information on the road 20

ahead. Contemporary examples are navigation systems which receive up-to-date traffic information, 21

updates on road-conditions or road-works by radio broad-cast such as RDS or TPEG, or via cellular 22

networks for mobile communication (GSM-GPRS). Typically, information rates are low and latencies 23

tend to be high. 24

With the advance in wireless technology and the investments in the expansion of cellular networks 25

to offer high-speed and affordable data communication, and boosted by the deployment of small 26

cells (picocells, femtocells), the difference between the two communication systems, WLANp and 27

cellular, is diminishing and even turning in favor of 3rd and 4th generation cellular (UMTS (3G) and LTE 28

(4G)). UMTS networks already offer sufficient data rates comparable for driver awareness and 29

mobility applications. Even more, 4th generation cellular systems (LTE), currently being rolled out by 30

telecom operators, offer even increased bandwidths at lower latencies than UMTS. These advances 31

in telecom infrastructure, create the possibility for implementing a set of cooperative driver 32

assistance functions using today’s cellular systems. 33

Apart from the fact that it is technically feasible to implement cooperative driver assistance functions 34

using cellular communication, there is a number of practical reasons why it is a good idea to start 35

implementing these functions based on cellular communication rather than waiting for WLANp to 36

mature. All issues such as handling (soft-) handover, standards-compliancy testing, authentication, 37

roaming and even billing are addressed for 3G networks and devices, yet still have to be tackled for 38

WLANp. Handling network overload is tackled in 4G (LTE) networks, as described in release 10 of the 39

2

3GPP standard. 3G cellular networks are mature and abundantly available throughout the world and 40

rapidly being expanded in coverage and performance or upgraded to 4G by telecom operators. The 41

networks are equipped with encryption and validation to check whether the device (SIM card) is 42

allowed to connect to the operator network and maintain privacy in the communication. Moreover, 43

the organizations and procedures are in-place for checking the compliance of devices with cellular 44

telecommunication standards. Most important of all is the likelihood of building a valid business 45

case for driver awareness and cooperative assistance functions using cellular. With the increase in 46

number people using smart phones, there is a potential user base of communicating devices on the 47

market, capable of implementing limited driver assistance functionality today. If only the 48

infrastructure would provide the necessary information, the market for connected assistance 49

functions could really take a head-start once the (downloadable) applications are provided. In this 50

way the proliferation of connected driver assistance could start, paving the way for the more 51

enhanced driver assistance functions which requires in-vehicle integration by the OEM. 52

In the remainder of the paper we will first discuss some practical issues of realizing connected driver 53

assistance functions using mobile communication networks. We discuss deployment aspects 54

alongside the network architecture, and the possible modifications to handle large sets of 55

communicating devices with reduced communication latency. 56

57

Example application: Intersection assistant 58

Numerous examples of driver assistance applications can be imagined within the domain of 59

Intelligent Transport Systems (ITS). In this paper, we focus on “road intersection assistance” as a 60

typical example of a (connected) driver assistance function. It covers less time critical assistance 61

functions such as an intelligent speed advice to pass an upcoming traffic light(s) at green without 62

stopping (Green Wave speed). This function is comparable to e.g. an optimal lane or speed advice on 63

the highway to minimize congestion. The intersection assistant also covers time-critical use cases, 64

such as warning the driver for local hazards. This could be a potential accident with objects like 65

crossing pedestrians, bicyclists or vehicles, which may be difficult to see from the driver’s point of 66

view. This part of the assistance function is similar to e.g. a warning for local hazards on a highway 67

such as an accident or sudden traffic jam. Generally speaking, the time-criticality of a hazard warning 68

depends on the time to reach the hazard location and whether that hazard then still exists, rather 69

than the hazard itself. Note that for many connected driver assistance functions, it is not the 70

reception of a hazard warning which is the bottle neck, but the timely detection and generation of 71

the hazard warning. For our intersection assistant application, we addressed the detection 72

bottleneck by using infrastructure cameras for detecting sudden hazards, like crossing pedestrians, 73

and we focus on the incident analysis and subsequent fast communication of these sudden events to 74

provide an in-vehicle driver warning to the impacted vehicles. Targeted communication from the 75

infrastructure to vehicles saves on bandwidth and needed spectrum and significantly increases 76

goodput by lowering retransmits and offering message acknowledgements. 77

78

Functional topology 79

3

Without car-to-infrastructure communication, a driver’s vehicle needs to listen to the broadcasts of 80

all other objects near an intersection and determine whether or not in may collide to one (or 81

multiple) of those objects. All objects need to broadcast their identifier, speed and position with a 82

sufficiently high repetition rate such that new objects driving into this area have a high likelihood to 83

receive this information. With a growing number of objects, high repetition rates quickly consume all 84

of the available bandwidth and cause the collision free throughput of the network to drop 85

significantly. Orchestrating the information on objects via an infrastructure node alleviates this issue. 86

Update rates could be lower, and only a single object (infrastructure) has to be queried to receive 87

information on all objects. 88

It is important to realize that on an intersection, the infrastructure has unique knowledge of the 89

status of traffic lights and the future moments they will switch. The infrastructure can be extended 90

with sensors to detect other road users, such as pedestrians, bicyclists or approaching vehicles. As all 91

connected vehicles need to contact the infrastructure for this information, it is a small step to 92

aggregate the information from these vehicles with the information already present. The 93

infrastructure can use this information about all objects at the intersection to control the traffic lights 94

‘on demand’, and redistribute the assembled information to all approaching vehicles by either 95

broadcast or point-to-point communication. The infrastructure can filter, process and even prioritize 96

and predict information to be sent to approaching vehicles. E.g. information about vehicles leaving 97

the intersection is of no use to other vehicles and could be left out to save bandwidth. For point to 98

point communication, the infrastructure could prune this information even further, by selecting only 99

the relevant information for this specific vehicle, leaving out all information which is only relevant to 100

other vehicles. This further reduction of the data to be communicated reduces the required 101

bandwidth and communication delay. Communicating less data is especially important in 102

environments with low signal-to-noise ratios, as larger packets would require more retransmits 103

causing a larger delay and larger bandwidth utilization. Pre-processing data in the infrastructure has 104

the additional advantage that it reduces the processing power required in vehicle, as less data needs 105

to be handled. 106

107

Requirements on communication 108

The delay on the communication path to the vehicle (which can include the setup time of the radio 109

link) will be limiting the usefulness of sharing time-critical and time-bound-events, and by that, 110

limiting the potential of driver assistance applications. Note that most of the time critical information 111

is required on a small geographical scale only. E.g. relaying a warning to a driver for a crossing 112

pedestrian on an intersection is only helpful if the vehicle receives this message before the physical 113

encounter with pedestrian (see yellow circle in Figure 1). Likewise, data will by nature be less time 114

critical on larger distances from the intersection, e.g. the crossing pedestrian would already have 115

crossed the road before the vehicle would have reached him. Data for anticipating traffic lights 116

remains relevant on this distance, as the duration of those events is longer (Green circle in Figure 1). 117

On even larges distances, the individual timing of the longer events becomes less relevant for the 118

driver, and it is more useful to receive statistical data, e.g. the average time to pass a certain area, 119

such that an alternative route might be selected. 120

4

121

Figure 1: Time criticality of v2i data around an intersection 122

To minimize latency and maximum data routing efficiency, the functional topology of the intersection 123

assistance application is preferably reflected in the architecture of the communication network. A 124

local compute resource in the infrastructure, usually called road side unit (RSU), is needed at the 125

intersection to collect and process local traffic data and prepare the data for the approaching 126

vehicles. This RSU has to communicate time critical data with the nearby vehicles and the less time 127

critical data with all the vehicles approaching the (set of) intersection(s) covered by this server. 128

Preferably, the RSU has a local transmitter for communicating this data. A backhaul network is 129

needed for communicating less time critical data to other transmit stations for approaching vehicles 130

outside the coverage of the local transmitter, and to systems higher in the traffic flow management 131

hierarchy. Besides technical requirements derived from the application domain, there are 132

economical and other non-functional requirements which needed to be addressed when setting up a 133

communication network for connected driver assistance applications. 134

135

Non-functional requirements: Authentication, roaming and link handover 136

An important, yet often forgotten aspect of wireless communication is authentication and roaming. 137

By authentication, both ends of the wireless communication link obtain certainty about the identity 138

(and validity) of the other side. Roaming is the feasibility for devices managed by other or foreign 139

operators, to obtain access to the local communication network. Mostly, authentication and roaming 140

are connected to ‘billing’, but it is an essential item for trustworthy communication. If the sender of 141

the data cannot be authenticated, the data received cannot be trusted. The data received on the 142

status of traffic lights or crossing pedestrians, would be totally void if the vehicle cannot authenticate 143

the sender of the information (infrastructure). Likewise, the infrastructure could not trust the 144

information received from the vehicle if it could not authenticate the sender. 145

For cellular networks as used by mobile phones, authentication is done by checking secret keys in the 146

SIM-card against secret keys in the Mobile core (SGSN, Serving GPRS Support Node) of the operator 147

network via secured connections. Roaming requires even more time and effort: an authentication at 148

5

the foreign operator’s Mobile core, and a check to decide whether this device is allowed to connect 149

to the local network. 150

For an open access network like WLANp, connecting to and communicating over the network is 151

unsecured to allow fast attachment to the network. As received data cannot be trusted without 152

authentication, the IEEE 1609 standard proposes additional measures and concepts for security are 153

being proposed by the Car2Car consortium. The authentication process requires time, processing 154

power on both ends and a backhaul connection from the RSU to, speaking in cellular terms, the 155

mobile core of the RSU-operator. As equipped with devices from other or foreign operators need to 156

be authenticated as well (roaming), similar agreements, standards, procedures and implementations 157

are required as is currently in place for cellular communication. 158

It will be clear that the process of authentication takes time, varying between hundreds of 159

milliseconds to even seconds, and needs to be performed each time vehicle attaches to a network. 160

The coverage range of a local transmitter of an RSU needs therefore be large enough, such that there 161

is sufficient time for authentication and preparing the set-up for the data link/exchange. When the 162

coverage ranges become small, the overhead in re-establishing the wireless link and redoing the 163

authentication and the preparation for data exchange would limit the usefulness of the system, as 164

data would no longer arrive in the vehicle on time. Alternatively, the communication network 165

supports ‘handover’. With handover, the wireless connection with the mobile device is passed on to 166

another basestation of the same operator .Security context transfer as specified by 3GPP1 greatly 167

reduces the setup latency due to authentication. Furthermore, research is ongoing to optimize the 168

handover authentication even further2. With ‘soft’ handover (“make before break”) as is supported 169

in current 3G cellular systems, even the data link can remain active during the handover. 170

Implementing features such as handover, roaming and authentication is quite complex. It took 5 to 171

10 years before these issues were solved and implemented in a proper standardized way for cellular 172

networks. Further developments and standardization of these aspects for WLANp is still needed. 173

174

Financial constraints: Incremental investments, expansion and deployment 175

Financial constraints are one of the most important, non-technical requirements impacting the 176

realization of a communication network for ‘connected driver assistance’ functions. Realizing a 177

country-wide mobile communication network from scratch requires an enormous up-front 178

investment. Revenues from this network, either in Euros by paid subscribers or by the reduction in 179

(deadly) accidents or improved traffic flow efficiency, will only come after the network is operational 180

and services are deployed, and only once there is a sufficiently large group of drivers using the 181

connected driver assistance functionality. 182

1 3GPP TS 33.102 v7.1.0, 3G Security; Security Architecture,

2 A simple and robust handover authentication between HeNB and eNB in LTE networks, Jin Caoa, Hui Lia,

Maode Mab, Yueyu Zhanga, Chengzhe Laia

6

Providing coverage only in (a part of) a single city would not attract many consumers to pay for 183

equipment for connected driver assistance and services, as they have only a marginal return on this 184

investment. Either the consumers’ investment has to be significant lower or the service has to add 185

more value, e.g. by being available on a wider scale. 186

Let’s assume that a provider or road-operator wants to enable a connected driver assistance such as 187

‘intelligent speed advice and local hazard warning’ along the 15000 km [wegenwiki]of German 188

highway. Assume further that a single WLANp equipped RSU typically covers a range of 1.5 km of bi-189

directional highway, and that installing an RSU next to the highway costs € 30000 when buying and 190

installing them in large quantities. The upfront investment then easily rises to 300 M€ for providing 191

basic coverage. Assume further that setting up a backhaul network and the connected services 192

incorporates similar cost. Considering only capital expenditure costs of 5% of the 600 M€, and 193

system depreciation and maintenance cost of 10% easily brings the total cost of ownership for the 194

provider to at least 90 M€ per year to support connected driver assistance functions. If 1 Million 195

drivers would pay for this service, each of them has to pay € 7.5 per month to cover only basic costs 196

of this service and does not include provisions for accumulated interested costs nor any profit margin 197

for the service provider. Note that this examples still excludes the cost of the required in-vehicle 198

equipment. 199

Current cellular networks already have the capacity, and are already being upgraded by telecom 200

operators to sustain the growing need in data transport by the growing number of connected 201

navigation devices and smart phones. As investments in extending network capacity are keeping 202

pace with the growing number of (paying) users, the financial risk of the network operator and/or 203

service provider remains limited. Deploying services on today’s cellular networks and existing devices 204

in the market, avoids the need of the consumer to invest in new (dedicated) equipment. It also limits 205

the upfront investments to application development and to gathering the required input data for 206

connected driver assistance services, as is illustrated by the following examples. 207

A navigation provider, offering a navigation service which is augmented by real-time traffic 208

congestion data (e.g. TomTom HD Traffic), could extend his product by including intelligent speed or 209

lane advice to maximize traffic flow, or by adding a warning for local hazards such as road-works, or 210

sudden traffic jam build up. The input data for their traffic application server would be obtained from 211

either the regular channels (predictable), or by further processing the received floating car data. The 212

(finer grained) floating car data could indicate a traffic jam build up, or show sudden speed variation, 213

which could be used to alert the drivers upstream of this location using the regular cellular 214

communication as is depicted in Figure 2 for the vehicle (UMTS modem) just below Bonn on the A61. 215

This only requires an incremental investment in service and application development. When the 216

number of users would grow to a level that the number of simultaneous connections becomes a 217

bottleneck in the provides communication network, the network capacity could be extended 218

incrementally by adding additional transmitters (femto cells) at locations with intense traffic, as 219

indicated in Figure 2 on the A3 just above and below Dreieck Dernbach (A48). 220

7

221

Figure 2: Using existing cellular systems to deploy driver assistance functions 222

223

224

Figure 3: The connection and data path between the mobile device to the traffic application server 225

8

226

With a growing number of users , the aggregated data rates and latencies in the operator network 227

may cause a bottle neck at the telecom operator’s internet gateway, the Gateway GPRS Support 228

Node (GGSN), see Figure 3. This would block the development of connected assistance services into 229

fine grain and more time critical service, as our intersection assistant. 230

A logical step to tackle this problem is to build the network with a less centralistic routing of data, 231

such that data on the network can be handled as local as possible, eliminating the concentration on 232

single hotspots in the network. 233

4th Generation cellular systems (4G, LTE) as currently being deployed by telecom operators, are 234

designed for data transport and support this decentralized data break out, which makes this 235

architecture ideally suited for providing connected driver assistance functionality. 236

The current 3rd Generation cellular (UMTS) is architecturally designed for speech, and despite of the 237

higher data rates, still suffers from the data-routing bottleneck. To overcome this bottleneck and 238

single point of failure, the 3G networks can be augmented with femto cells providing the local 239

wireless link to the mobile devices in their coverage area. Femto cells according to release 10 of 3GPP 240

standard [REF] offers the architectural advantage of 4G local data break-out, but are already 241

available with 3G radio technology. With femto cells, one could create a cost effective high 242

performance low latency local 3G connection to a (local) traffic application server, such as an RSU. 243

Figure 4, depicts this solution. The mobile device (UMTS modem) connects wirelessly to the femto 244

cell at the right-top in Figure 4. For authentication and handover, it requires services from the 245

operator network. The data connection can be re-routed locally to connect to the nearby server with 246

traffic data, allowing fast sustainable low-latency access to local traffic data and offloading the main 247

internet connection of operators network. 248

9

249

Figure 4: Femto cell augmented 3G network 250

251

252

The mobile client, in-vehicle device 253

If the in-vehicle device needs to communicate directly with all other (moving) in-vehicle devices in its 254

surrounding, it needs to authenticate with all of them, process their data, and calculate whether one 255

of those objects might be on a collision course. The requirements for this device will be high, and 256

lead to a costly thick client and likely to high latency in communication on complex authentication 257

schemes. Standardization wise, this solution is challenging as somehow, it has to be 258

guaranteed/verified that each in-vehicle device is able to set-up and maintain time critical 259

communication with all other devices of all vendors and for all the hardware and software versions 260

of this set. The complexity of this problem is of the order n(n-1)/2, where n is the number of devices 261

in the set. Limiting the in-vehicle device’s communication to infrastructure only reduces this 262

problem, to testing against the much smaller number of infrastructure devices. The fact that 263

compliancy testing could be based on existing and proven standards is an additional argument in 264

favor of cellular networks. 265

The mobile client needs to establish the wireless connection to the infrastructure, exchange data and 266

advice the driver. For our Intersection assistant, the client device has e.g. to inform the driver on the 267

appropriate speed to pass the intersection smoothly and efficiently and warn the driver for potential 268

hazards like crossing pedestrians, bicyclists or vehicles. For integration into vehicles, this device 269

10

should preferably be reasonably low cost. This implies that it has to fulfill its function with limited 270

compute and memory resources (thin client), and is preferably based on mass-market developments 271

and/or is merged with other connected processing capable devices inside the vehicle as e.g. 272

navigation systems or an eCall unit. 273

In our project we show that it is feasible to run a set of connected driver assistance functions on a 274

smart phone, as is currently owned by 30% to 50% of the population (country dependant). This 275

market penetration offers a quick start for deploying ITS services in the area of connected driver 276

assistance, as the devices to interface with the driver are already present and only the services need 277

to be developed. 278

Realization of intersection assistant using 3G communication 279

In many cities, traffic lights do not operate on a standalone manner, but are connected to a central 280

system which could be extended by a webserver. An application (e.g. Green Wave speed advice) 281

could be developed for a smart phone, which request the status and switching moments of nearby 282

traffic lights on the (main) roads from the webserver, based on the requestor’s position and heading. 283

This information could then be used to calculate a target speed for the user to pass the next traffic 284

light at green without stopping. As this service can be supported by today’s cellular networks, the 285

upfront investment is limited to application development only, and could be beared by a city seeking 286

to improve traffic flow and reducing pollution. If the application is downloadable for free, the end 287

user only pays for the data exchange, and only when using the application. 288

The intersection assistant being developed by Flanders’ DRIVE and partners within the Vision 289

project*i, is based on the outlined philosophy of re-using available communication infrastructure. 290

The in-vehicle application has to run with limited processing power and with limited communication. 291

With this example driver assistance application, we target non-time critical functionality as the Green 292

Wave speed advisory, as well as non-predictable time-critical functionality such as a local hazard 293

warning for a crossing pedestrian, and in a next step faster moving objects such as crossing bicyclists 294

and vehicles. We use a Samsung Galaxy Nexus (running Android 4.0) as our development platform 295

for the JAVA based intersection assistant application. Although we use the smart phone for user 296

interfacing, application testing and as an example of an existing mobile device on which these kind of 297

applications can be deployed, we fore see a migration of the application code to thinner, vehicle 298

integrated clients such as navigation devices and eCall units, in the near future. 299

A test intersection has been created at Lommel Proving Ground, which is being equipped with 300

sensors for detecting pedestrians, bicyclists and vehicles. The sensors are connected to a traffic 301

application server (TAS), which also controls the installed traffic lights. The mobile device sets up an 302

data link (IP connection) via a 3G wireless link to the TAS which is kept open. The device sends the 303

traffic application server periodically its position, speed and heading, such that the traffic application 304

knows from where the vehicle is approaching the intersection. The traffic application server selects 305

the relevant information for this approaching vehicle, such as traffic light status and advised speed to 306

the vehicle. As soon as e.g. a crossing pedestrian is detected by one of the infrastructure sensors, the 307

traffic application server checks for which vehicles this event is relevant, and sends those vehicles the 308

information (location and type of event). As the data link is kept open, the latency on the 309

communication link is very low, especially with a state of the art device with a (standard) state of the 310

11

art operating system and telecom stack. Measurements in the surroundings of Lommel (Belgium) 311

showed a typical one way latency of 40 ms for communicating our message between the TAS and our 312

mobile device. For 2G communication (EDGE), we measured a typical latency of 126 ms for 313

communicating a speed advice message between the TAS and our mobile device, which is still low 314

enough for even time critical applications. The remainder of the project is directed in testing 315

different users scenarios, under different network load conditions, using standard 3G cellular 316

networks as well as femto cell equipped networks. 317

318

Conclusions 319

As the driver’s vehicle may not be able to communicate with all the objects near the intersection for 320

the simple fact that not all objects carry transponders, and/or there are too many objects to 321

communicate with all of them, there is an important role for the infrastructure to collect and relay 322

the necessary information to the approaching vehicles in due time. Without communicating 323

infrastructure, the economically interest for an OEM to integrate the intersection assistance function 324

into a vehicle might be questionable. Even if some premium OEMs will be interested in this option as 325

an extension of their already existing telematics services mass manufacturers will be hesitating due 326

to relatively high investment cost compared to low customer benefit for the early adopters. On the 327

other hand, for the road-operator, the return on investment in communicating intersections is rather 328

poor when there are no vehicles using it. 329

Deploying connected driver assistance functionality is technically feasible using contemporary 3G 330

cellular networks. Deployment using existing 3G cellular networks and exploiting the existing user 331

base of smart phones and in-vehicle connected devices (navigation, eCall units), seems a good 332

approach from an economical perspective and might be used to break the vicious circle described 333

above. Investments in the roll-out of services and infrastructure remain low, and can be gradually 334

increased when the number of users increases. Network data transport capacity can be further 335

improved and communication latency reduced with distributed (local) traffic application servers 336

connected to femto cells, such that connected driver awareness functions may evolve in true driver 337

assistance functionality. 338

Acknowledgements 339

The authors would like to acknowledge the team members of the Vision project for their effort in 340

driving the project forward and the feedback they gave to this paper. Special thanks go to Jef de 341

Busser and Michiel Gijbels (both with Flanders Drive) and Johan Moreels (Alcatel Lucent Bell Labs), 342

for their work and contribution to this paper. 343

References 344

i These are the partners which collaborate with Flanders’ DRIVE in the Vision Project: Alcatel-Lucent, Ford

Lommel Proving Ground, Mobistar, NXP, TomTom, Traficon, LMS, Melexis and Tenneco. The project is

financially supported by the Flemish government, and runs until the end of september 2012. For more

information on Flanders’ DRIVE: www.flandersdrive.be.