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.

A mobile device consists of hardware components, such as microprocessors, wireless network interfaces, display and touchscreen, storage, cameras, and sensors; and software including the operating system and applications. To understand and optimize energy consumption, models are needed for the subsystems and components of the smartphone, including the OS and applications.

In this chapter, we give an overview of the smartphone energy consumption and the methodologies that can be used for power modeling and optimization. We aim to answer the question: where is the smartphone energy spent? and its follow-up question: how can we maximize the energy efficiency?

Methodology

To address the above questions, the first thing we need is a well-defined and rigorous methodology.

Energy profiling terminology

For a thorough treatment of a topic, it is generally important that the core concepts are properly named and that the terminology is consistent and well understood. Otherwise, it is difficult to grasp what exactly is software-based energy profiling and optimization. Furthermore, as we will see especially in the profilers section, the literature is rich with plenty of different kinds of solution which are presented as unique tools but are often combinations of different kinds of underlying techniques. Hence, it is necessary to be able to categorize these solutions and to analyze their advantages and disadvantages, which requires a good understanding of the relevance of the different components of an individual energy profiler, such as a specific power-modeling technique. For these reasons, we briefly define here the most important terms that we use in this part.

Our studies of power measurement have revealed that the power consumption of a smartphone varies with the applications in use, the way the device user uses the applications, and the environment where the smartphone is operated. As power measurement only tells us how much energy is being consumed by the whole smartphone or a hardware component such as the display, more information is required for analyzing the factors that affect the power consumption.

Power modeling is a technique that has been developed for quantifying the impact of different factors using mathematical models. A power model can be specified for a certain hardware component, a certain smartphone, or a certain piece of software. The information used for defining the model variables can be provided by hardware, OS, and/or applications, while the coefficients of these variables can be derived from power measurement using deterministic and/or statistical methods. The methodology of deterministic and statistical power modeling is introduced in Section 9.1, followed by three case studies: a deterministic power model of a Wi-Fi network interface (Section 9.2), a statistical model of the overall power consumption of a smartphone (Section 9.3), and a fine-grained energy profiler using system call traces (Section 9.4).

Power models can be used for estimating the energy consumption of the hardware or software component. Examples of model-based energy profilers can be found in Chapter 10. More importantly, power models provide hints on improving the energy efficiency of smartphones and applications.

The last ten years has been the era of personal and social communications, with the rapid proliferation of smartphones that provide always-on connectivity with people and information. The mobile computing environment has changed over the years in many ways. Today's devices are powerful computers and sensing systems that have versatile communications capabilities, and they are capable of running native and web browser-based applications that can tap into system resources such as various onboard sensors. The devices also come in many forms and shapes, such as small and large form-factor phones, tablets, and wristwatches.

Understanding smartphone and mobile device energy consumption is a vital and challenging problem. It is vital, because the remaining operating time of a device should be understood and maximized when necessary. It is challenging, because a device consists of various hardware and software systems that work together. Various modeling, prediction, and optimization techniques are needed to engineer energy-efficient mobile systems.

Overview and the environment

Energy efficiency in mobile computing, especially in the wireless data transmission involved in mobile applications, is one of the challenges that has attracted much attention from mobile device manufacturers, application providers, and network operators. Compared with traditional telephone services, such as voice calls and short message service, executing modern mobile applications consumes much more computing and networking resources and therefore demands much more energy. However, battery technology has not developed as fast as mobile computing technology and has not been able to satisfy the increasing energy demand. This has directly resulted in a dramatic decrease in battery life, that is, the time until the next charge.

The smartphone is a highly integrated and complex device. Its energy efficiency can be optimized in various ways, but the charging behavior and application use pattern have a large impact on battery life and energy efficiency. This section discusses the impact of human behavior on the energy efficiency and battery life of a smartphone. It continues with the other side of the coin: how battery-awareness applications change human behavior. Finally, it lists some techniques for how to get the most of remaining battery life as a smartphone user.

Human–battery interaction

The term human–battery interaction was coined by Banerjee et al. in [1]. It refers to the different ways that the user interacts with the smartphone battery. The interactions happen in both directions with the user determining the charging patterns and power management related phone configuration, and the phone giving feedback on the battery status and power consumption.

The charging pattern of a particular user is of interest because it can give indications about whether the user in fact ever even runs out of battery. For example, a particular user may always charge the phone overnight regardless of the current battery level. The charging behavior guides the power management of the device so that it is neither too conservative nor too aggressive. Coming back to the example user who charges the phone every night, if the battery would last longer than one day with that user's typical usage, there is no need for further energy savings and, instead, more energy could be spent improving the quality of the mobile services they use.

The rapid advancement of the communication and computing capabilities of smartphones has led to batteries depleting faster. The Android and Apple's iOS application ecosystem both include many applications that help their users manage the battery life of their devices. Some of these are automated, and give little or no control to the user, turning off functionality that is not used and reducing the amount of time the phone spends awake. Another class of battery-management applications is informational, providing users with options, indicating how much energy each option will save, and keeping track of the energy use of the phone. These applications are typically called energy profilers or mobile battery-awareness applications. The former is targeted at developers whereas the latter is for users of the smartphones.

The primary goal of these applications is to make the developer or user aware of what consumes energy. They give the user insight into the factors that consume battery power on their mobile device and give advice on how to deal with them.

In this chapter, we consider the state of the art in energy and power modeling on smartphones. Following the terminology presented in Chapter 6, an energy profiler is a system that characterizes the energy consumption of a smartphone. Typically, the profiler relies on power models that represent power draw. An energy profiler can be a separate device or a software component running on the smartphone and using the device's battery interface for energy and power information.

Energy modeling and optimization are very important parts of mobile and wireless application development. Recent studies suggest that the battery life of a smartphone has become a critical factor in user satisfaction. Typical mobile applications today consume much more energy than is strictly necessary because of the suboptimal use of the smartphone's hardware by the software.

This book provides guidelines for smartphone users, methodologies for researchers, and in-depth knowledge of smartphone power management for the public at large. The techniques presented in the book are necessary for developing energy-aware and energy-efficient systems and applications. The book provides the necessary theoretical background and results from the field, and also practical guidance on assessing and optimizing energy efficiency.

In this book we study the following two questions: What is the power consumption of smartphones and applications, and what are the potential solutions for optimizing smartphone power consumption?

Mobile device power management is facing new challenges posed by the revolutionary development of mobile networks, devices, and applications. Smartphones are complex systems, and it is hard to anticipate user behavior and the way the operating system (OS) and applications use the underlying hardware resources. Thus, advanced techniques are needed, first to understand the power-consumption behavior, and then to optimize the hardware/software design to improve energy efficiency.

A seemingly straightforward way to conserve the battery life of a mobile device is to migrate application execution partially to a cloud. This technique is called offloading or sometimes cyber foraging. Offloading computationally expensive processing from smartphones onto more powerful servers has been widely discussed in the literature. In this section, we introduce four frameworks (MAUI [1], Think Air [2], Cuckoo [3], and Clone Cloud [4]) that allow mobile applications to dynamically migrate part of their execution from the smartphone to the cloud. These frameworks have been developed to offload CPU-intensive tasks. We call it computation offloading. Note that most popular mobile applications also involve network communications, which in fact consume a significant part of the overall battery life. Hence, it is justified to ask: Can offloading techniques help save energy, if applied to such applications? To answer this question, we also discuss communication offloading, a technique that focuses on reducing communication costs through offloading.

Computation offloading

Offloading computationally expensive processing (such as speech recognition, face recognition, language translation, and 3D modeling) from smartphones onto more powerful servers has proved to be useful for improving performance and energy efficiency. Take face detection as an example: Simoens et al. [5] implemented a video-sharing application in which faces detected from the video captured by mobile devices were first blurred before the video was shared.