Communication between vehicles (and between vehicles and available infrastructure) is the topic of this chapter. Essentially, we give a basic introduction to inter-vehicle communication (IVC) identifying the key concepts in the safety as well as in the non-safety application domains. For this, we derive all the relevant communication concepts and solutions for those applications and, most importantly, identify the requirements such as maximum delays, minimum dissemination range, or minimum data rates. Furthermore, we present an overview on the possible communication paradigms, such as whether information is to be exchanged without the help of any available infrastructure or whether infrastructure elements – roadside units (RSUs), parked vehicles, or even widely deployed cellular networks – can be used for the information exchange.

The scope of this chapter is to introduce IVC as an active research field. The main motivation is to become familiar with the field to a level that helps one to understanding the fundamental concepts and their limitations. All the communication principles outlined will be studied in greater detail in the following chapters.

This chapter is organized as follows.

1. • Applications (Section 3.1) – In this section, we introduce the field starting with typical applications for IVC. We will show that the scope and character of these applications vary widely, which complicates the development of common and generalized IVC protocols.

2. • Requirements and components (Section 3.2) – Starting from knowledge about IVC applications, we derive requirements on IVC solutions and study metrics to assess their effectiveness. In a second part, we introduce all the communication entities involved and possible mechanisms for information exchange.

3. • Concepts for inter-vehicle communication (Section 3.3) – This section can be regarded as the main part of this chapter. We broadly study all the communication principles and protocols that have been considered for IVC. This overview explains why the different protocols have been studied and what their main advantages and disadvantages are.

4. • Fundamental limits (Section 3.4) – We conclude this chapter by discussing fundamental limits for IVC.

5. […]

Wireless sensor networks (WSNs) have fascinated both the research and development communities. Applications of WSNs have mushroomed in both civilian and military domains. The growth of wireless sensor networks was originally motivated by military applications; however, WSNs are now used in all kinds of civilian and industrial applications [1–20]. Currently, the overwhelming majority of WSNs measure scalar tangible phenomena such as humidity, pressure, temperature, movement, and pollutants. Typically, most WSNs are built for delay-tolerant and low-bandwidth applications. Hence, most research efforts have concentrated on this latter paradigm, which is often called terrestrial sensor networks. In any WSN application the main challenge is the lifetime of the network. A WSN structure includes a gateway that offers wireless connectivity back to the wired/fixed network.

In nearly all applications of the WSNs, they are used to monitor certain physical processes. They are deployed for measuring the temperature, air pressure, radiation of the human body, chemical reactions, movement of objects, vitals of the body, and so on. By doing this we can recover some important information of the boundaries that are often called edges. To keep track of the edge of a physical development, the recognition of a boundary is imperative. The issue of discovering the boundary is considered to be the first step for resolving the edge detection. In digital processing there are many methods for identifying the edge; however, they are not easy to implement in the WSNs’ environment since the sensor nodes are not equally spaced like pixels, and because of limited computational power and memory [3–6].

Wireless sensor networks (WSNs) use the same medium (which is the air) for wireless transmission that the nodes in a wireless local area network use. In order for nodes in a local area network to communicate properly, standard access protocols like IEEE 802.11, IEEE 802.15.4, and ZigBee, are available. However, these and other protocols cannot be directly applied to the wireless sensor area networks. The major difference is that, unlike the devices participating in local area networks, sensors are equipped with a small source of power (usually a battery), which drains very quickly. In addition, sensor nodes have limited resources of memory and computational power. Hence, there is a need to design new protocols for medium access control (MAC). This chapter investigates some of the major MAC protocols available [1–7].

Medium access control in wireless networks

There exists a very good set of standard protocols for wired and wireless area networks, which are proven to operate efficiently. There are many reasons for not using the wired and traditional wireless MAC protocols for WSNs. The standard protocols in wired local area networks use the well-known carrier sense multiple access with collision detection (CSMA/CD) scheme for individual stations to access the medium. This protocol, the IEEE 802.3, is known as Ethernet [1–46]. In this scheme, each station senses a medium for a random amount of time. If no activity is detected it starts its own transmission. If it detects any activity in the medium it defers its transmission until the activity ceases. If it senses a collision of packets from different nodes in the networks it backs off a random exponential amount of time and then starts contending for transmission using the backoff exponential algorithm. Slotted ALOHA networks traditionally use a time division multiple access (TDMA) scheme [9–10]. In this scheme, the time is divided into an equal number of slots such that a node is allowed to transmit only in its allotted slot. Here, the disadvantage is that a node is allowed to transmit if and only if it owns the slot; otherwise it has to listen to the medium for the data intended for it. Therefore, if the node has no data to send the bandwidth is simply wasted because there will be no activity for the amount of slot time allotted to a node with no data.

Radio access technologies like WiFi, IEEE 802.11p, and LTE form the basis of any communication stack, and the choice of technology heavily influences application performance. They are the topic of this chapter.

In general, two families of radio access technologies can be differentiated: those based on cellular networks and those based on short-range radio. Traditionally, these two families were conceptually vastly different. Cellular networks relied on central coordination, whereas short-range radio operated in a fully distributed fashion. Cellular networks used licensed spectrum, whereas short-range radio had to make do with unlicensed spectrum. These differentiations are no longer strictly true. Cellular networks are slowly moving towards (some) distributed control, while short-range radio, particularly for inter-vehicle communication (IVC), is profitting from infrastructure support and central services. Further, short-range radio for IVC can now rely on allocated dedicated spectrum. A new trend further blends licensed and unlicensed spectrum into spectrum that has primary users, which can access the spectrum with absolute priority, but one also allows its white spaces to be filled by non-primary users.

We will take a detailed look at the concepts and the underlying principles of representative radio access technologies from both families, always with a focus on their use in vehicular networks.

This chapter is organized as follows.

1. • Cellular networks (Section 4.1) – We start by following the evolution of the Third Generation Partnership Project (3GPP) family of cellular networks: from GSM, via UMTS, to LTE, with a perspective on future technologies. We will always be considering both halves of a cellular network, that is, the air interface and the radio access network (RAN), as well as the core network.

2. • Short-range radio technologies (Section 4.2) – We then turn towards a classical short-range radio technology, following the evolution of IEEE 802.11 wireless LAN (WLAN) and its many extensions. We discuss one extension in particular detail: IEEE 802.11p, which extended WLAN for use in vehicular networks. Lastly, we discuss efforts building on WLAN to provide a complete IVC protocol suite.

3. […]

The decision on the overall functionality to provide with a car is first of all a marketing decision and independent of the in-car networking technologies used and available. However, as soon as decisions have to be made on how to enable the functionality, in-car networking becomes important. Aspects like flexibility, scalability, or how to distribute functions are severely impacted by the properties of in-car networking. This chapter thus discusses the opportunities and changes Automotive Ethernet brings to system development.

A brief overview of the system development process

The development process in automotive follows the V-cycle. While Section 2.3.1 used the V-cycle to explain the responsibilities shared between car manufacturer and Tier 1 supplier, in this section the model is used to explain the changes the introduction of Ethernet-based communication brings to the development process. The important idea of the V-cycle is to follow a top-down approach on the development side and a bottom-up approach on the test side. On both sides, each new step requires the conclusion of the previous. During the development, the later need for testing is directly supported with the provision of test cases. This ensures stringent test coverage.

Preface

On 11 November 2013, I [Kirsten Matheus] attended a celebration of 40 years since the invention of Ethernet at an IEEE 802 plenary meeting. During the celebration Robert Metcalfe, David Boggs, Ronald Crane, and Geoff Thompson were honoured as the pioneers of Ethernet. If I had to name the people without whom Automotive Ethernet would not have happened, I would name Thomas Königseder, technical expert at BMW and co-author of this book, and Neven Pischl, EMC expert at Broadcom.

It all started in 2004, when Thomas received the responsibility for speeding up the software flash process for BMW cars. With the CAN interface used at the time, flashing the 1 Gbyte of data anticipated for 2008 would have required 16 hours to complete. After careful evaluation, Thomas chose and enabled the use of standard 100BASE-TX Ethernet for this purpose. Thus in 2008 the first serial car with an Ethernet interface, a BMW 7-series, was introduced to the world.

Role of in-car networking

An explanation of the needs, the development, and some of the choices in in-car networking starts with the windows. When automobiles were invented they were simply machines on wheels without windows. It was only later that windows were added, first at the front, then at the sides and back. The windows were static or insertable in one piece. This obviously was not very comfortable, neither for the handling of the windows, nor for the temperature regulation in the passenger cabin. Thus, in 1928 the first mechanical window winder, able to hold a window at any position desired, was presented to the public [1]. The first power windows were introduced in 1941 [2]. BMW was the first company to introduce power windows in Europe and the first BMW with all electric power windows was a “Serie 2 BMW 503,” which had an SOP at the end of 1957 [3]. This is where it gets interesting.

It is quite straightforward to imagine a switch in a vehicle door that actuates the electric motor for a window located in the same door. Everything is in one physical location and the wiring will be short. The wiring gets longer when all movable windows are required to be controllable by the driver, in addition to the “local” control in every door. More wiring between almost exactly the same locations is needed if a central door lock plus an electronic side mirror adjustment are also discretely wired. Figure 2.1(a) indicates that with only the basic comfort functions the size, weight, and number of wires will soon become prohibitive. In the case of discrete wiring, inventiveness quickly circles around the question of “How is it possible to fit another wire onto this inline connector or through this opening between e.g. body and door?” instead of fully exploring the possibilities of creating a new feature. On top of this, large wiring bundles are not only heavy, costly, and hard to install, but also error prone and difficult to diagnose [4].

To understand physical transmission in in-car networks two aspects are important: the actual automotive environment in which the communication happens and how the properties of the PHY technology ensure its use in this environment. This chapter will therefore start with the PHY technologies in Section 4.1, explain the automotive channel in Section 4.2, and discuss ElectroMagnetic Compatibility (EMC) in Section 4.3. Other important requirements in this context, such as semiconductor quality, Power over Data Line (PoDL), and Energy Efficient Ethernet (EEE), are introduced in Section 4.4.

The Physical Layer (PHY) technology

100 Mbps BroadR-Reach (OABR)

It all started with the IEEE 802.3 1000BASE-T standard. During its development, the engineers at Broadcom learned to handle the communication challenges that needed to be mastered for such a high data rate transmission. So when Ethernet in the First Mile (EFM) was being developed at IEEE, Broadcom reused some of the basic principles of 1000BASE-T for a suitable solution: instead of four pairs of wiring one pair was used and the channel coding was made more robust, so that it was possible to transmit 100 Mbps data over a worse, i.e. longer, channel. IEEE standardized a different solution for EFM, while Broadcom proposed their technology for EFM in China [1]. When BMW was looking for an Ethernet solution suitable for automotive another interesting use case was found for the Broadcom technology.

From the beginning

In 1969 employees at AT&T/Bell Labs developed the first version of Unix. The original intention was to aid the company’s internal development of software on and for multiple platforms, but over time Unix evolved to be a very widespread and powerful operating system, which facilitated distributed computing. An important reason for the successful proliferation of Unix was that for antitrust reasons AT&T was neither allowed to sell Unix nor to keep the intellectual property to itself [1]. In consequence Unix – in source code – was shared with everybody interested.

It was especially, but not only, embraced by universities and the community that evolved provided the basis for the computing environment we are used to today and in which also Ethernet has its place. At a time when computing was dominated by large, proprietary, and very expensive mainframe computers few people could use, Unix created a demand for Local Area Networking (LAN) while at the same time providing an affordable, common platform for developing it [2]. As one example, a group at the University of California, Berkeley created a Unix derivative. The Berkeley Software Distribution (BSD) was first released in 1978 and its evolutions became as established as the “BSD-style license” attached to it [3]. Another example is the TCP protocol. The first version of this, published in 1974, was implemented for Unix by the University of Stanford by 1979 [4]. Later in 1989, the then up-to-date TCP/IP code for Unix from AT&T was placed in the public domain and thus significantly helped to distribute the TCP/IP Internet Protocol Suite [5].

When a new technology is being developed and enabled in an industry, there are various factors that impact the success of that technology. In the authors’ opinion the most important ones are its benefit, its costs, and the framework that allows an industry to develop around it. This chapter will discuss these topics with respect to Automotive Ethernet. However, as is also frequently pointed out (see e.g. [1–3]), it is not only technical facts but also individuals who act as the driving force behind a new technology. In respect to Automotive Ethernet, both authors feel that they have their share in the events. In consequence, the events in this chapter will sometimes be described from a personal viewpoint.

The first use case: programming and software updates

Architectural challenges

In 2004, BMW decided to introduce a central gateway in its cars starting from 2008 Start of Production (SOP) onwards. This central gateway was to combine two functions: (1) to route data between the different CAN, FlexRay, and MOST busses inside the cars; and (2) to function as the diagnostic and programming interface with the outside world. For the latter, BMW has always used a centralized approach. This means that software can only be flashed with an external tester device that is connected via the OnBoard Diagnostics (OBD) connector [4] and that all flashable Electronic Control Units (ECUs) inside the car are updated with their latest software versions. This approach assures that the customer always has the latest software in the car and that there are no sudden software inconsistencies in functional domains, in which some units have been updated and others have not. This is an architectural choice that, as it happens, was decisive for the introduction of Automotive Ethernet. Nevertheless, there are car manufacturers that use decentralized approaches for software updates and handle the version management differently. They might update e.g. only the multimedia/infotainment units via USB or DVD.

One of the reasons for the automotive industry to adopt Ethernet-based communication as an in-car networking system is the chance for synergies, i.e. the possibility of reusing protocols that have been developed and tested in other applications. Across the various protocol layers for the various applications it therefore needs to be carefully investigated whether to adopt, adapt, or to add protocols. Figure 5.1 gives an example overview of the protocol stack. This chapter discusses three areas that require special care: how to adopt and potentially adapt Audio Video Bridging (AVB, see Section 5.1); how to use the Internet Protocol (IP) and Virtual LANs (VLANs, see Sections 5.2 and 5.3); and what is needed in terms of command and control (see Section 5.4). Be aware that there might be other solutions that work. The described solutions make no claim to be complete; nevertheless they do work.

Quality of Service (QoS) and Audio Video Bridging (AVB)

Ethernet as such, i.e. the PHY and MAC layers as defined by IEEE 802.3, provide best-effort traffic only. Going to “full-duplex,” in the sense of switched Ethernet networks, improved the determinism of each individual link, since a number of units no longer needed to contend for the same medium at potentially the same time and have to go into random, i.e. non-deterministic, back-off periods. However, in a switched network, data of different sources with different destinations might have to be sent over the same link at the same time. It is therefore in the switch – often also referred to as a bridge – that many QoS requirements can effectively be supported. Today, it is mainly at IEEE 802.1 that the respective standards are being developed. The following sections will give some background information on the standards’ activity (Section 5.1.1), and enlighten the differences between the originally envisioned use cases and automotive deployment (Section 5.1.2). In return, this allows describing how each QoS standard can best be used in in-car networking (Section 5.1.3), before the efforts of how to go beyond the QoS for audio and video are described (Section 5.1.4).

There are in principle two types of innovations: incremental and radical. While incremental innovations improve key market features on the basis of existing methods and technologies, radical innovations are based on new technologies that either revolutionize an existing market and/or even create a new one. The uncertainty of the consequences of an innovation increases from incremental to radical. For example, the costs and improvements for an incremental innovation can generally be assessed more easily than for a radical innovation. A radical innovation often requires more investment and holds a greater risk of technological failure. The important aspect, however, is that a radical innovation has the chance to change a market so profoundly that – among other consequences – it will leave behind those who did not perform the change (see e.g. [1]).

At the time of writing, there were two automotive innovation fields with potentially far-reaching consequences: alternative drives/electric vehicles and automated driving. For both innovations, networking is extremely important and both require the vehicle to be connected to the worldwide network. Furthermore, both have the potential to change the car related user behavior, significantly more fundamentally than e.g. the introduction of navigation systems did. With the limitations of current battery technologies, the reach of an electric car is shorter than that of a car with a combustion engine. Because of the shorter reach, it is extremely important to be able to correctly predict the remaining reach at any time. Users will then become aware of the difference it makes if they switch off the air conditioning or infotainment and they might develop new behavior patterns. This includes wearing gloves, opening the windows, or accepting a detour if this avoids very hilly terrain. The impact of electric cars will be profound.