Eindhoven University of Technology MASTER Investigation of ...Investigation of time-synchronization...

Eindhoven University of Technology

MASTER

Investigation of time-synchronization over Ethernet In-Vehicle Networks for automotiveapplications

Sridharan, K.

Award date:2015

Link to publication

DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain

https://research.tue.nl/en/studentthesis/investigation-of-timesynchronization-over-ethernet-invehicle-networks-for-automotive-applications(fbf90a73-d27e-4c23-a211-950c45b1bb43).html

Department of Mathematics and Computer Science

Masters in Embedded Systems

Master Thesis

Investigation of Time-Synchronization over Ethernet

In-Vehicle Networks for automotive applications

Author:

Karthik Sridharan

(Student ID: 0869748)

Supervisors:

TU/e:

prof. dr. K.G.W.(Kees) Goossens

NXP:

dr. Nicola Concer

dr. H.G.H.(Bart) Vermeulen

26th October 2015

Public

This page is intentionally left blank.

Preface

This thesis is submitted in partial fulfilment of the requirements for the Master’s Degree in

embedded systems at Eindhoven university of technology, Eindhoven, The Netherlands. The

project was conducted at NXP Semiconductors, Eindhoven and was jointly supervised by prof.

dr. K.G.W.(Kees) Goossens (Eindhoven University of Technology), dr. Nicola Concer (NXP)

and dr. Bart Vermeulen (NXP). It contains work done from 1st March to 30th September 2015.

The thesis has been made solely by myself, with inputs from the supervisors and is based on the

IEEE 802.1AS standard for time synchronization over Ethernet. The research work and papers

of others working on similar topics was used as reference and I have done my best to provide

these references where applicable.

The Eindhoven University of Technology (TU/e) is one of the leading universities in the Nether-

lands. TU/e intends to be a research-driven, design-oriented university of technology, with the

primary objective of providing young people with an academic education within the engineering

science and technology domain.

NXP Semiconductors is a Dutch semiconductor manufacturer. It is one of the worldwide top

20 semiconductor sales leaders. NXP Semiconductors creates a variety of solutions for the

Connected Car, Cyber Security, Portable and Wearable and the Internet of Things etc. NXP

Semiconductors has a number of research and development facilities across the globe.

Acknowledgement

It would not have been possible to complete this thesis without the help and support of the

people around me.

First, I would like to express my gratitude to prof. dr. K.G.W.(Kees) Goossens my university

supervisor for recommending me to this project at NXP. His inputs and guidance guidance

helped me in all the time of research and writing of this thesis

I would like to thank dr. Nicola Concer, dr. Bart Vermeulen and Ms. Clara Otero Perez

for giving me an opportunity to do my master thesis at NXP, Eindhoven.

I would like to express my sincere thanks and appreciation to dr. Nicola Concer for super-

vising my day to day activities and providing invaluable guidance during the project. His

technical inputs and support were extremely helpful during the project.

I would like to thank dr. Bart Vermeulen for his support, feedback and inputs during the

project. His inputs were crucial and helped me explore various dimensions in the project.

I am grateful for the technical help provided by Mr. Han Raaijmakers. I would also like

to express my sincere thanks and appreciation to the Ethernet team at NXP Semiconductors,

Hamburg and NXP Semiconductors, Nijmegen for their technical support.

Finally, I would like to thank my parents. Without their efforts and support this degree would

not have been possible.

Abstract

The challenges faced by the automotive network engineers in multimedia networking like band-

width, Quality of Service (QoS), cost, licensing, scalability etc., has led the automotive indus-

try into considering Ethernet as an In-Vehicle Networking (IVN) standard. Some of the these

multimedia applications include reverse parking assistance, infotainment, night-vision camera

systems etc. Though in the earlier days Ethernet was not used as an IVN standard because

of its non-deterministic nature, recent developments like the Audio Video Bridging (AVB) and

Audio Video Transport Protocol (AVTP) standards developed by the AVnu Alliance (AVnu)

task groups has improved the QoS and reliability of Ethernet.

This thesis presents an analysis of the time synchronization protocol which is a part of the

AVB set of standards. Time synchronization in a distributed network is achieved by exchang-

ing messages. Time synchronization plays a key role in delivering a good QoS. The IEEE

802.1AS standard specifies the protocol and procedures used to establish the synchronization

among distributed nodes in a network. The thesis also summarizes some of the current and

relevant work under progress.

Given AVB (automotive) over Ethernet as the scope, we study the impact of the Synchroniza-

tion parameters like Synchronization interval, delay mechanism, delay measurement interval,

announce interval, time-stamping mechanism, Network parameters like Traffic class, packet size,

message frequency and End node parameters like Processor load, application priority etc., on

the quality of synchronization. We then reason about how and why a parameter affects the

synchronization through relevant measurements, tests and plots.

The thesis describes the set-up of a Ethernet network, the selection of end nodes (hardware

and software) and the design of a software for the Ethernet switch (NXP SJA1105). Parame-

ters that could potentially affect the protocol were selected and experiments were performed on

the network to analyse their impact on the time synchronization protocol.

A synchronization in-accuracy of ±108ns in a 2 hop network, ±141ns in a 3 hop and ±168ns

in a 4 hop network was achieved. Reducing the frequency of the Sync messages improves the

synchronization by a factor of 0.27. The experiments also establish the importance of having

hardware time-stamping and an averaging mechanism for calculating the path delay between

different network entities. The AVB and Best effort (BE) traffic though do not have an impact

on the quality of synchronization, significantly affect other parameters related to synchroniza-

tion. The bandwidth utilized by the protocol is very less of the order of 0.0411% for a low Sync

message interval of 31.25ms. Based on the challenges faced during development of the software

for the switch and the experimental analysis, recommendations were made for the improvement

of the switch. The learnings of the experiments would serve as valuable pointers during the

development of the application.

Key words: Ethernet, IVN,AVB, time synchronization, IEEE 802.1AS, clocks, hardware

time-stamping, switch.

7 Investigation of Time-Synchronization

Contents

Preface 2

Acknowledgement 4

Abstract 7

Glossary 14

Acronyms 17

1 Introduction 21

1.1 Current networking solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

1.2 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.2.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1.2.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

1.2.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

1.3 Motivation - Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.4 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.5 Goals and Research questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

1.6 Thesis overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2 Related work and Background 33

2.1 Audio Video Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.1.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.1.2 Stream Reservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.1.3 Forwarding and Queuing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.1.4 Audio Video Transport Protocol . . . . . . . . . . . . . . . . . . . . . . . 39

2.1.5 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.1.6 Other related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3 Time Synchronization 42

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.2 Synchronization terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.3 IEEE 1588 and IEEE 802.1AS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3.1 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

9

CONTENTS

3.3.2 Clocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.3.3 Comparison of IEEE 1588 and 802.1AS . . . . . . . . . . . . . . . . . . . 47

3.4 Working principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4.1 Best Master Clock Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.2 Time-Stamping Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.4.3 Synchronization Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.4.4 Delay Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.4.5 Rate Ratio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.4.6 Working scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.5 Other related work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4 Experimental setup 59

4.1 End node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.1 Hardware selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.2 Software selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.1.3 Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . 60

4.1.4 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.2 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.3 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

4.4 Software tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5 Experimental Methodology 64

5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.2 Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3 Test Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Experiments, Results and Analysis 69

7 Conclusion 70

7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

7.2 Recommendations for the Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

A Current Solutions 73

A.1 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.2 Local Interconnect Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.3 Media Oriented Systems Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.4 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

B Message formats 77

C gPTP configuration 79


List of Figures

1.1 Point to point networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

1.2 Diagnostics and Error handling over CAN [1] . . . . . . . . . . . . . . . . . . . . 23

1.3 Evolution of automotive networking technologies [2] . . . . . . . . . . . . . . . . 23

1.4 Advanced Driver Assistance System [3] . . . . . . . . . . . . . . . . . . . . . . . . 25

1.5 Example Layout of an Infotainment System[4] . . . . . . . . . . . . . . . . . . . . 25

1.6 Packet switching and simultaneous exchange [2] . . . . . . . . . . . . . . . . . . . 26

1.7 Ethernet as a Backbone network [5] . . . . . . . . . . . . . . . . . . . . . . . . . 27

1.8 Scalability of Ethernet networks by adding Switches [2] . . . . . . . . . . . . . . 27

1.9 BroadRreach technology of NXP PHY TJA1100 [5] . . . . . . . . . . . . . . . . . 28

1.10 Cost Vs Bandwidth for various networking technologies [5] . . . . . . . . . . . . . 28

2.1 Audio Video Bridging Stack [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.2 AVB application in Aeronautics [7] . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.3 Ethernet AVB in cars [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.4 Stream Reservation Protocol [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.5 Working of Credit Based Shaper [9] . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.6 Credit Based Shapers [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7 IEEE 1722 AVTP frame [9] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.8 Co-existence of AVB, TTE and BE traffic [10] . . . . . . . . . . . . . . . . . . . . 41

3.1 Idea of Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.2 Synchronization Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.3 Transparent clock [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.4 Boundary clock [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.5 BMCA spanning tree with Master-port Slave-port Disabled-port Passive-port [12] 49

3.6 Software and Hardware time-stamping . . . . . . . . . . . . . . . . . . . . . . . . 50

3.7 Two-step synchronization mechanism [13] . . . . . . . . . . . . . . . . . . . . . . 52

3.8 One-step synchronization mechanism [13] . . . . . . . . . . . . . . . . . . . . . . 53

3.9 Peer delay mechanism [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

3.10 Rate ratio calculation[14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.11 Working Scenario of the IEEE 802.1AS protocol . . . . . . . . . . . . . . . . . . 57

3.12 Effect of Sync interval [12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

3.13 Effect of traffic on Synchronization [12] . . . . . . . . . . . . . . . . . . . . . . . . 58

11

LIST OF FIGURES

4.1 Kontron Board [15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.2 RIoTboard [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.3 Linuxptp working [17] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4.4 Network Topology with 1 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

4.5 Network Topology with 2 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.1 Test procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

A.1 Controller Area Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.2 Local Interconnect Network [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A.3 Media Oriented Systems Transport [2] . . . . . . . . . . . . . . . . . . . . . . . . 75

A.4 FlexRay - Bus topology [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.5 FlexRay - Star topology [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A.6 FlexRay - Hybrid topology [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

B.1 Announce Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.2 Sync Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.3 Follow Up Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

B.4 PDelay Req Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

B.5 PDelay Resp and Pdelay Resp Follow Up Message . . . . . . . . . . . . . . . . . 78


List of Tables

1.1 Comparison of different In-Vehicle wired networks Source:[2] . . . . . . . . . . . 29

2.1 Stream reservation classes [19] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.1 Comparison of different synchronization protocols[20] . . . . . . . . . . . . . . . . 43

3.2 Comparison of E2E and P2P transparent clocks . . . . . . . . . . . . . . . . . . . 47

3.3 Comparison of message usage in IEEE 1588, IEEE 802.1AS and IEEE 802.1AS

(automotive) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.4 Comparison of IEEE 1588, IEEE 802.1AS and IEEE 802.1AS (automotive) . . . 48

3.5 Comparison of time-stamping methods . . . . . . . . . . . . . . . . . . . . . . . . 51

3.6 Comparison of One-step and Two-step synchronization . . . . . . . . . . . . . . . 54

3.7 Comparison between End to End (E2E) and Peer to Peer (P2P) delay mechanisms 54

13

LIST OF TABLES


Glossary

Correction field It is a field in the Follow Up message that contains the path delay experi-

enced by the message. It is 8 bytes in size and has a nanosecond and sub-nanosecond

field.

Disabled-port It is the port that is not IEEE 802.1AS capable[12].

End-Node It is the end point in the Ethernet network. It can either be a grand-master or a

slave.

Ergonomics It is the practice of designing products, systems or processes to take proper

account of the interaction between them and the people who use them.

Ethernet Switch It is a computer networking device that connects devices together on a

computer network, by using packet switching to receive, process and forward data to the

destination device.

Grand-Master This clock is the source of time for all other nodes in the network. It has an

accurate time reference.

Infotainment It is a collection of hardware devices installed into automobiles, or other forms

of road transportation, to provide audio or video entertainment, as well as automotive

navigation systems.

Master-port It is the port closest to the Grand-Master and is the relative source of the Sync

messages [12].

MaxIntervalFrames It is the number of frames in an interval of time.

Passive-port It is a port that is neither master nor slave[12]..

peerDelay It is the path delay between two entities in a network.

preciseOriginTimestamp It is the time of departure of the Sync message from the Grand-

Master. It is inserted in the Follow Up message.

residenceTime It is the amount of time the Sync message spends in the switch.

15

Glossary

Slave-port It is the port that is connected to the Master-port and receives the Sync mes-

sages[12].

StreamID It is the unique identifier for a stream to distinguish from different streams.

Time Synchronization It is the synchronization of internal clocks of several control units to

a reference clock over a network..

Time-stamp It is the time of departure of the Sync message from the Grand-Master.


Glossary


Acronyms

ABS Anti-lock Braking System.

ADAS Advanced Driver Assistance System.

AVB Audio Video Bridging.

AVnu AVnu Alliance.

AVTP Audio Video Transport Protocol.

BC Boundary Clock.

BE Best effort.

BMCA Best Master Clock Algorithm.

CAN Controller Area Network.

CBS Credit Based Shaper.

E-AVB Ethernet Audio Video Bridging.

E2E End to End.

ECU Electronic Control Unit.

EMS Engine Management System.

FSM Finite State Machine.

GPS Global positioning system.

gPTP Generalized Precision Timing Protocol.

IC Instrument Cluster.

IEEE Institute of Electrical and Electronics Engineers.

IVN In-Vehicle Networking.

LIN Local Interconnect Network.

18

Acronyms

MAC Medium Access Control.

MFS Maximum Payload Size.

MIF Max Interval Frames.

MIL Malfunction Indication Lamp.

MOST Media Oriented Systems Transport.

NTP Network Time Protocol.

NXP NXP Semiconductors.

OEM Original Equipment Manufacturers.

OH Overhead.

Open Alliance OPEN Alliance SIG.

OS Operating System.

P2P Peer to Peer.

PCP Priority Code Point.

PHC PTP Hardware Clock.

PHY Physical layer.

PTP Precision Timing Protocol.

QoS Quality of Service.

SMSC Standard Microsystems Corporation.

SPS Strict Priority Scheduling.

SR Stream Reservation.

SRP Stream Reservation Protocol.

TC Transparent Clock.

TSN Time Sensitive Networking.

TTE Time Triggered Ethernet.

TTTech TTTech Computertechnik AG.

TU/e Eindhoven University of Technology.

UTP Unshielded Twisted Pair.

VLAN Virtual Local Area Network.


Chapter 1

Introduction

Automobiles have evolved from just mechanical devices to a combination of electrical, elec-

tronic and mechanical devices. Today’s auto-mobiles contain a number of different electrical

and electronic components which together are responsible for monitoring and controlling the

vehicle. Many components, from the Brake system (Anti-lock braking) to the Instrument Clus-

ter (IC) and the Engine Management System (EMS) can communicate with each other and

other neighbouring systems. Modern automobiles have more than 50 Electronic Control Unit

(ECU)s connected together.

The automotive industry has been revolutionized by the introduction of electronics. The in-

dustry has seen an exponential increase in the number of electronic systems since the mid 20th

century. The developments in the field of electronics have enabled the automotive engineers to

deliver high performant, safe and reliable products to their customers. The constant growth

and improvements in the performance and reliability of hardware, coupled with the flexibility

provided by the software have improved the quality of the vehicles to a great extent.

The main aim of these electronic systems has been to aid the driver and passengers to have a

safe and comfortable ride and to ease the process of controlling numerous devices in the vehicle.

For example the introduction of Anti-lock Braking System (ABS), Airbags etc., have improved

the safety and comfort of the driver and passengers. We also see that many devices in the vehi-

cle like the wipers, headlights, indicators are controlled by electronics. Networking has enabled

the designers to reduce the cabling significantly and place the switches in ergonomic locations.

The ECU was introduced in the car to control a system of sensors and actuators. This consisted

of a micro controller capable of controlling and monitoring these devices. However this proved

to be insufficient due to the introduction of more ECUs into the vehicle and many functions

needed to be distributed across several ECUs. For example the EMS had access to the vehicle

speed sensor typically mounted on the differential of the vehicle and this value calculated by the

EMS is required by the ABS to perform its functionality. If this had to be done independently

by both the systems each ECU should have access to its own sensor. This would prove to be

costly and thus the concept of networking was introduced. This would enable the ECUs to

CHAPTER 1. INTRODUCTION

Communication Channel

Figure 1.1: Point to point networking

share information and distribute information processing across different control units.

Until the beginning of the 90s, the exchange of data between ECUs happened in a point-to-point

fashion as shown in Figure 1.1. However this resulted in complicated systems as each ECU had

to be connected to every other ECU thus making this an inefficient way of sharing data. This

also increased the weight, cost and complexity. Further diagnosing problems in the vehicle was

difficult. These issues resulted in the development of networks where the communications are

multiplexed over a medium shared by all ECUs. This had led to many networking standards

like the K-line, Controller Area Network (CAN), Local Interconnect Network (LIN), FlexRay,

Ethernet etc. The development networks were aided by the advancements made in the field of

software.

The software developed for these ECUs have evolved tremendously and has enabled precise

control of the actuators like the fuel injector and have improved the performance of the vehicles

to a great extent. These software are becoming more and more structured, reliable and are gov-

erned by a number of standards. These developments in software and networking have enabled

effective diagnosis of faults in the vehicles at the service centres. The intelligence has been built

into these ECU, sensors and actuators to detect faults if any and report to the driver so that

the necessary actions can be taken. For example a fault in the fuel injector is detected by the

Engine Management System (EMS) and is communicated over the network to the Instrument

Cluster (IC) and is indicated by illuminating a Malfunction Indication Lamp (MIL) (Figure

1.2). As another example, in case of a crash the air-bag ECU sends a message over to the EMS

ECU to stop to prevent further movement of the car.



PC for diagnostics

Engine Management System

Service Engineer

CAN bus

Error in Sensor

MIL illuminated in cluster

Figure 1.2: Diagnostics and Error handling over CAN [1]

The overall safety of the vehicle depends on communication between these various ECUs.

While communicating with each other, ECUs are responsible for a variety of activities like

predicting crashes, detecting errors, controlling the engine, entertainment and climate control

in car etc. Future automotive applications require higher performance and reliable computing

resources. Both the processing and networking technologies are driven by the market which

redefines the way automotive systems are designed. The different performance requirements

throughout a vehicle, as well as the competition among companies, have led to the design of a

variety of communication networks.

1.1 Current networking solutions

An IVN is a specialized internal communication network that interconnects components inside

a vehicle. Some of the popular networks are listed below. The IVNs have evolved over a period

of time (figure 1.3) . Some of the most common IVN standards include CAN, LIN, FlexRay,

Media Oriented Systems Transport (MOST), k-line with CAN being the most popular among

the networks due to its low cost and simplicity.

Figure 1.3: Evolution of automotive networking technologies [2]



Different applications requires different networking solutions. All functions and systems in

the car need different QoS. Hence the requirements expected from the networks vary based on

the domain its used in. In-car embedded systems is divided into several domains based on their

common goals and performance requirements. For example the Powertrain domain consists

of ECUs that typically control the engine and transmission, chassis domain ECUs control the

dynamics of the vehicle like the suspension and the infotainment domain ECUs handle the

multimedia applications in the vehicle.

Now when we consider the domains, Powertrain domain requires a reliable communication

which can be achieved by CAN. However some applications like controlling doors, windows

etc., do not require the extensive features and advantages provided by CAN. Thus low cost

and bandwidth networking solution like LIN is used. For time critical applications FlexRay is

used. However multimedia applications require more bandwidth and has led to the develop-

ment of networking solutions like MOST and Ethernet. Some of these networks are explained

in Appendix A.

1.2 Ethernet

Consumer and automotive electronics have always been separate worlds due to the differences

in requirements and focus. However recent developments and growing requirements in both

industries have enabled them to converge and reap the benefits of each other.

One of the major challenges faced by network design engineers was the bandwidth provided

by CAN and other networks. These limitations can be overcome by the introduction of Ether-

net as an in-vehicle networking standard. This is necessary for the multimedia applications in

the car. Ethernet standard has proven itself to deliver in the past and has been established for

quite sometime. Ethernet a technology of the past is now becoming the future of automotive

networks with some modifications to it. It is this ability of Ethernet to adapt, evolve and change

to meet the changing bandwidth requirements [2].

The development of Ethernet as an in-vehicle network for today’s cars is broadly being discussed

by many companies and scientific communities. There are many studies being conducted to ex-

plore the capabilities of Ethernet-based automotive networks that can handle mixed-critical

(hard/soft real-time, best-effort) traffic. The in-car infotainment is one of the developing fields

and some of the currently available solutions are costly and are mostly proprietary. Many au-

tomotive manufacturers concentrate on the in-car infotainment as this is one of the factors that

affects the customer perception and adds value to the product. Further with the increasing

competition in the recent times features like navigation, music, video and radio have become a

standard and necessary part of the infotainment package.



1.2.1 Applications

Ethernet can also be used to establish hard real-time audio/video communication between the

ECUs. AVB is a set of communication standards designed for transforming a network into a

real-time streaming capable system. Some of the applications which require high bandwidth

include reverse parking assistance, night vision cameras, blind spot detection, navigation, music

and video systems etc. The Advanced Driver Assistance System (ADAS) typically improves the

safety, risk of damage and connectivity on the move. Figure 1.4 gives an overview of the ADAS.

ADAS is an important feature which would play a key role in the development of autonomous

cars.

Figure 1.4: Advanced Driver Assistance System [3]

Over the period of time entities like Global positioning system (GPS) navigation, multimedia

speakers etc., which were considered a luxury has become a necessity. This has led to the

development of the infotainment domain. infotainment combines entertainment and information

delivered to the customers. This requires a high bandwidth because of its streaming application.

Figure 1.5 shows a typical layout of the in-vehicle infotainment system.

Figure 1.5: Example Layout of an Infotainment System[4]



1.2.2 Benefits

One of the key reasons behind the development of Ethernet as an automotive network is be-

cause of its low cost and the maturity of the technology (as this has evolved over a long period).

However in order to adapt this technology for automotive applications it has to undergo some

restructuring for satisfying the QoS requirements. AVnu is a consortium of professional, au-

tomotive and consumer electronics companies working together to establish and certify the

interoperability of the AVB standards.

Ethernet is currently under development for handling non-critical data. To extend Ethernet

to handle time-critical data a deterministic real-time scheduled Ethernet communication called

Time Triggered Ethernet is under development. This is being actively developed by the Time

Sensitive Networking (TSN) group of AVnu. This is now being actively promoted by TTTech

Computertechnik AG (TTTech) for safely critical applications.

Ethernet is a packet switching network that enables the messages to be broken down into

packets and enable simultaneous transmission of multiple packets. These messages are han-

dled by the Ethernet Switch and are forwarded to the right destinations [2]. For example let

us consider an example as shown in Figure 1.6. If we consider this network messages can be

transferred at 100Mbps in both directions of the links highlighted. Even though the links have

a maximum speed of 100Mbps theoretically an aggregate throughput of 400Mbps is possible.

With the switched network structure the networks are more scalable (Figure 1.8) and make

them a good candidate to be used as an automotive backbone network as shown in Figure 1.7.

A backbone network is one that connects all the ECU domains in a vehicle.

Figure 1.6: Packet switching and simultaneous exchange [2]



Figure 1.7: Ethernet as a Backbone network [5]

Figure 1.8: Scalability of Ethernet networks by adding Switches [2]

BroadR-Reach is an Ethernet physical layer standard designed for automotive Ethernet. It

is developed and maintained by the OPEN Alliance SIG (Open Alliance) consortium. This

standard realizes simultaneous transmit and receive operations on a single unshielded twisted

pair cable. The advantage of BroadR-Reach is that it is low cost, weight, better power saving

modes and robust to all environmental conditions. Figure 1.9 gives the main components of an

automotive BroadR-Reach link.



Figure 1.9: BroadRreach technology of NXP PHY TJA1100 [5]

The OPEN Alliance SIG consortium was formed between Broadcom, NXP, and Harman

and many companies to promote automotive Ethernet. Almost all major Original Equipment

Manufacturers (OEM)s have plans to migrate to Ethernet. Thus Ethernet is becoming the

future of automotive networks.

1.2.3 Comparison

Each of the above mentioned networking technologies have their own advantages and disadvan-

tages. Some of these are restricted by the type of application, performance etc., eg. MOST

is primarily used for media applications and FlexRay is use for time critical applications. To

summarize the Table 1.1 gives a comparison between the above discussed networks based on

different parameters. Further Figure 1.10 summarizes the comparison of the discussed networks

with respect to bandwidth and cost.

Figure 1.10: Cost Vs Bandwidth for various networking technologies [5]



Table 1.1: Comparison of different In-Vehicle wired networks Source:[2]

No Parameter Ethernet CAN FlexRay MOST LIN

1 Max Band-

width

(Mb/s)

100 per link, full-

duplex

1 20 150 0.02

2 Maxi Num-

ber of nodes

Limited by the

number of switch

ports

30 22 64 16

3 Network

Length

15m / link 40 m 24 m 1280 m 40 m

4 MAC Full-duplex Arbitration,

re-

transmission

Time-

Triggered

Time-Triggered Time-

Triggered

5 Cost Relatively high Low Low High Very Low

6 Topologies Star, tree, daisy

chain

Bus Bus, star,

hybrid

Ring Bus

7 Sleep

modes

Yes Yes Yes Yes Yes

8 Standards Open Alliance ISO 11898 FlexRay

consortium

Originally propri-

etary,MOST Co-

operation

ISO 17987

9 Safety criti-

cality

No. Should be

possible with

TTEthernet

Yes Yes No No

10 Availability Multiple vendors Many Few One Many

11 SoC Many Many Many Many Many

12 Cabling UTP UTP UTP Optical 1-wire

13 Error detec-

tion

Strong Strong Strong Strong Weak

14 Applications Infotainment,

backbone,

TTEtherent

in future for

safety critical

General use Safety criti-

cal, drive by

wire

Infotainment Switches,

doors etc

1.3 Motivation - Time Synchronization

The automotive applications require higher performance and reliable computing resources. Mod-

ern cars nowadays have sophisticated multimedia devices for assisting and improving the ride

quality. These include the drivers assistance systems like reverse parking assistance, night vision

cameras and infotainment systems which include navigation, music systems etc. The increasing

bandwidth requirements has led to the introduction of Ethernet as an in-vehicle networking

solution.



As part of the migration to Ethernet IVN, AVB a set of standards developed for media stream-

ing applications has been adopted. One key element of AVB is Time Synchronization among

the distributed control units. This is necessary to ensure a good QoS for media streaming.

For example when we consider the reverse parking assistance system it uses a combination of

cameras to detect rear collisions. In order to display the camera streams in real-time the display

has to be synchronized with the cameras so that it can display simultaneous frames captured

by the cameras.

It is therefore very important to study the time synchronization mechanism, its behaviour and

performance. The importance of studying synchronization can be attributed to the following

reasons:

• To establish a common time reference and alignment of time between distributed nodes.

• Critical for real-time applications, control and measurement systems, and lip sync in voice

and video over network etc.

• Execute coordinated actions, co-ordinate measurement instants, reference events, deter-

mine the age of data items, track security breaches

1.4 Problem Statement

From the above discussion we deduce the problem statement:

Problem Statement

Given AVB (automotive) over Ethernet as scope we study the impact of

• Synchronization parameters (Synchronization interval, delay mechanism,

delay measurement interval, announce interval, time-stamping mechanism

etc.)

• Network parameters (Traffic class, packet size, message frequency etc.)

• End node parameters (Processor load, application priority)

on the quality of synchronization to reason about how and why a parameter

affects the synchronization through relevant measurements, tests and plots.

1.5 Goals and Research questions

We evaluate the problem statement by breaking it down into the following four research ques-

tions / goals:

Question 1: How do the configuration parameters of the synchronization affect the

quality of synchronization?

• How do the various identified synchronization configuration parameters such as synchro-

nization, peer delay interval, delay mechanism etc., affect the quality of synchronization?



• How and what are the inaccuracies affecting the synchronization?

• Why do these parameters affect the quality of synchronization?

• What is the achievable quality of synchronization with automotive AVB specific synchro-

nization configurations?

Question 2: How does the system parameters affect the synchronization process?

• How do network parameters like network traffic, type of network traffic, message priority,

packet size, message frequency etc., affect the synchronization?

• What is the effect of load on the micro-controller running the synchronization protocol?

• What are the system load conditions that cause the synchronization quality to drop?

Question 3: How does the synchronization protocol affect the system?

• What is the effect of the synchronization protocol on the network (Bandwidth utilization,

switch residence time etc.,?

• What is the effect of the synchronization protocol on the micro-controller (end nodes and

switch) running the protocol?

• What is the impact of AVB and automotive AVB specific synchronization configurations

on the system (end nodes and Switches)?

Question 4: What are the potential benefits and bottlenecks of using IEEE 802.1AS

protocol in an automotive environment (if any)?

• What are the potential bottlenecks of the setup used?

• How and why does the implementation of synchronization support on the switch impact

the synchronization between two end nodes?

• How does the loss of synchronization affect the application using synchronization?

1.6 Thesis overview

The thesis is organized as follows:

• Chapter 1: Introduction presents a brief introduction and compares the various in-

vehicle networking solutions currently available.

• Chapter 2: Related work and Background presents the structure and the function-

ality of the AVB stack.

• Chapter 3: Time synchronization explains the time synchronization protocol in detail

along with the related work.

• Chapter 4: Experimental setup presents the hardware and software selection, switch

software implementation and the setup of the complete network.



• Chapter 5: Experimental Methodology explains the experimental methodology and

the steps followed during the experiments.

• Chapter 6: Experiments, Results and Analysis discusses the various experiments,

the results and the analysis of the results.

• Chapter 7: Conclusion summarizes the findings and presents the future work.

• Appendix A gives an account of some of the current networking solutions.

• Appendix B provides the formats of the messages used in the Generalized Precision

Timing Protocol (gPTP) protocol.

• Appendix C contains the gPTP configuration used for linuxptp.

• Appendix D explains in brief how various types of graphs and plots used in the thesis

have to be interpreted.


Chapter 2

Related work and Background

This section gives a brief description about Audio Video Bridging (AVB), its components,

applications and related work.

2.1 Audio Video Bridging

AVB is an emerging standard that extends Ethernet to support multimedia streaming. The

Ethernet Audio Video Bridging standard adds QoS features like time-synchronized low latency

streaming services and bandwidth reservation to make it possible to carry audio and video sig-

nals on a standard Ethernet line.

In 2005 a task group was created in the IEEE 802.1 working group called the Audio video

bridging task group. To introduce the high - bandwidth and established networking solution

like Ethernet into a car the task group has established a number of working specifications [21].

Figure 2.1 gives an overview of these protocol specifications and their usage in the stack. The

various layers of the AVB stack are as follows:

• IEEE 802.3: Ethernet physical layer specifications.

• IEEE 802.1BA: Audio Video Bridging (AVB) Systems.

• IEEE 802.1AS: Generalized Precision Timing Protocol (gPTP).

• IEEE 802.1Qat: Stream Reservation Protocol (SRP).

• IEEE 802.1Qav: Forwarding and Queuing for Time-Sensitive Streams.

• IEEE 1722: Audio Video Transport Protocol (AVTP).

• Application: Streaming media application.

The primary objective of the AVB implementation is to :

a. Provide a common and precise clock reference to the network.

b. Reduce network delays.

c. Avoid interference from non time sensitive traffic.

CHAPTER 2. RELATED WORK AND BACKGROUND

Application

BMCA

Ethernet IEEE 802.3

Time Synchronization

IEEE 1588 / 802.1AS

Stream Reservation

ProtocolIEEE 802.1Qat

TCP/IP

Layer2: Transport

protocol IEEE 1722

Forwarding and queuing

IEEE 802.1Qav

Figure 2.1: Audio Video Bridging Stack [6]

These standards together address the drawbacks in the existing systems such as synchro-

nization of different streams of audio and video, buffering delay because of the network, and

resource reservation. AVB addresses the shortcomings and provides a highly flexible and af-

fordable Ethernet-based solution. In the following section we will discuss the different layers of

the AVB in detail.

2.1.1 Applications

AVB is used for many application like Aeronautic Ethernet networks (Figure 2.2) for passenger

addressing, crew telephones, cabin video monitoring system etc., [7].

Figure 2.2: AVB application in Aeronautics [7]

Some of the other applications of AVB include the home entertainment system, stadium

entertainment system, studios etc. The focus of this thesis is towards the application of AVB to



automotive Ethernet networks especially for infotainment and ADAS [8] purposes. In order to

use AVB for this purpose it must be possible to synchronize multiple streams so that they are

rendered correctly in time, the network delays experienced by the streams must be minimal and

deterministic and the network resources are available as and when the application requires it [22]

[23]. Figure 2.3 shows a typical Ethernet network layout in a car that is used for infotainment

and driver assistance.

Figure 2.3: Ethernet AVB in cars [8]

2.1.2 Stream Reservation

The Stream Reservation Protocol (SRP) [IEE 802.1Qat] is one of the core functionality of the

AVB stack. It allows the talkers to advertise their content to the listeners. The SRP establishes

a path from the talkers to the listeners through a bridge. It also is used to allocate and release

bandwidth in an AVB network. The SRP allows two stream reservation classes(items 1 and 2

Table 2.1 ). The current Ethernet Audio Video Bridging (E-AVB) supports only two intervals

and these intervals place a constrain on the uncompressed audio streams that result in odd data

block sizes [24]. With this limitation in mind the automotive AVB introduces two additional

classes (items 3 and 4 of Table 2.1).

Table 2.1: Stream reservation classes [19]

S.No Class Network delay (max) Interval

1 Class A 2ms 125µs

2 Class B 10ms 250µs

3 64 Sample, 48kHz 15ms 1333 µs

4 64 Sample, 44.1kHz 15ms 1451 µs

The maximum bandwidth that can be allocated to the Stream Reservation (SR) classes is

75%. So in a 100 Mbits/s network the maximum bandwidth that can be allocated to the SR

class is 75 Mbits/s. The stream reservation protocol according to IEEE 802.1 Qat functions is

shown in Figure 2.4.

1. The talker first generates an advertise frame with a StreamID, MaxFrameSize and Max-



Figure 2.4: Stream Reservation Protocol [9]

IntervalFrames. The frame is multi-cast onto an AVB network. The stream bandwidth

(streamBW ) is calculated [9] as:

streamBW = (MFS +OH) ∗MIF/IntervalT ime (2.1)

Where,

• Maximum Payload Size (MFS)

• Max Interval Frames (MIF)

• Overhead (OH)

The interval time is dependent on the AVB streaming class which is determined by the

priority value of the Virtual Local Area Network (VLAN).

2. Once the streamBW is calculated and the output port of the switch has resources, the

frame is forwarded through the port and if sufficient resources are not available the frame

is modified to a talker failed frame state and forwarded to listeners along with the failure

information.

3. Once the listener has received the advertise frame from the talker without any error, it

can register to it. The listeners to subscribe to the specific stream transmit a listener

ready frame and allocate the required bandwidth along the path. In case of a resource

shortage or a problem in the bridge the listener ready frame is modified to listener asking

frame. It is then sent to the talker along with the error information.

4. A stream being sent by a talker can be stopped by sending a de-register stream frame

with the streamID to the listeners. This tells the listeners that the stream will no longer

be available and the bandwidth reservations are released.

5. Similarly a listener can de-register from a stream by sending a de-register attach frame to

the talker and release the network bandwidth reservations.



2.1.3 Forwarding and Queuing

Traffic shaping is a key technique in ensuring a good QoS. A priority based system would work

fine in a network where the high priority traffic is significantly less because the chances of col-

lision between the higher and lower priority traffic is less. This type of technique does not suit

a system where audio/video traffic is predominant and occupies a significant amount of the

bandwidth [21]. Earlier buffer sizes were increased to handle this. This is ok as long as the

application does not require a low latency. However current situations demand low latency for

both audio and video streams. This latency of the network also plays a significant role as it

decides the memory requirements of the bridges. The primary goal of AVB is to have a delay

less than 2ms over 7 hops for a SR Class A traffic and less than 50ms over 7 hops for SR Class

B traffic. In order to achieve these goals the Credit Based Shaper (CBS) was developed [IEEE

802.1Qav].

The CBS algorithm is used to select AVB frames for transmission. The algorithm defines

credits associated to each of the SR classes (Class-A, Class-B). A transmission is only allowed

when the credits are greater or equal than zero and no other frames are transmitted at the

same time. An AVB frame is dequeued and transmitted with the credits decreased at a rate

equal to the value of the sendSlope. The credits are increased at a rate equal to the value of

the idleSlope when a frame from the SR-Class is not transmitted. The algorithm limits the

maximum and minimum number of credits that can be accumulated by using the parameters

hiCredit and loCredit. Figure 2.5 gives an example [9] of the working of the CBS.



Figure 2.5: Working of Credit Based Shaper [9]

1. An AVB frame (Frame-A) arrives and is queued due to conflicting frames. The credits

are increased as per the idleSlope.

2. As soon as the transmission of the current frame is finished. Frame-A is selected for

transmission. The credits are reduced as per the sendSlope parameter.

3. Credits are set to 0 when there are no frames for transmission and the credits are positive.

4. Frame-B arrives and is transmitted immediately as there are no conflicting frames and

the credit value is greater than or equal to 0. The credits are decreased according to the

sendSlope parameter.

5. On the completion of transmission the credits are increased according to the idleSlope

parameter.



Figure 2.6: Credit Based Shapers [10]

Figure 2.6 gives an overview of the transmission selection scheme according to IEEE 802.1Qav.

The AVB traffic has the highest priority and can be transmitted only when its available credits

is greater than or equal to 0. The best-effort traffic has a priority based selection process [10].

2.1.4 Audio Video Transport Protocol

The Institute of Electrical and Electronics Engineers (IEEE) 1722 is a Layer-2 transport pro-

tocol that allows a type of encapsulation of audio and video frames. This enables the system

to improve the QoS. The protocol time-stamps the frames as a pointer to the receiver node so

that it can play the audio/video at a particular time. IEEE 1722 ensures that different listeners

are synchronized in addition to the IEEE 802.1AS. Figure 2.7 [9] shows the IEEE 1722 Audio

Video Transport Protocol (AVTP)frame.

The IEEE 1722 frame payload maximum frame size is limited to 1476bytes. The Ethernet

frame in addition to the payload also has other information such as the Header, StreamID,

AVTP Time-stamp, GatewayInfo and PacketInfo. The StreamID is used to identify and to

distinguish a stream. The AVTP Timestamp gives information about the presentation time

of a frame. It represents the time-stamp when the media sample was generated at the Talker

plus a constant time, Max Transit Time, to compensate for network latency. The Max Transit

Time represents the worst case network latency. The task group specifies two main and two

additional SR classes based on the transit(Table 2.1).

Figure 2.7: IEEE 1722 AVTP frame [9]



2.1.5 Time Synchronization

Time is a very important and critical physical quantity. This is so because the impact of time

is significant on the human perception of audio and video and this perception is expected to be

pleasant. Traditional systems render audio/video as a single device. With the advancements

in technologies there arose a need to stream this over a network. To achieve a good quality of

streaming a time synchronization was a key necessity. As a result it led to the development of

the IEEE 1588 - Precision Timing Protocol (PTP) [13]. Time synchronization is the key focus

of this thesis so this will be explained dedicatedly in Chapter 3.

2.1.6 Other related work

AVB traffic analysis

The paper [9] presents and evaluates AVB network by using simulation. The observations made

were as follows:

• The Payload size of AVB frames impacts the performance. The latency is improved by

reducing the frame size. The latency of both classes of AVB remains the same except for

the fact that the jitter is improved for class A.

• The application requirements are achievable for AVB streaming even over 7 hops and

network traffic.

• Control data injected as a non-AVB frame is not significantly influenced by the network

traffic.

Extending AVB with Time Triggered Ethernet (TTE)

Efforts are being made to enable the co-existence of AVB and TTE. This would enable the

critical and non-critical traffic to co-exits. The introduction of TTE would serve as a replacement

for the FlexRay network which are designed for time critical applications [10][25]. As per the

papers [10] [25] the main challenge in achieving this type of system is arriving at an optimal and

compact schedule (one without gaps). The experimental analysis [10] shows that scheduling of

TTE frames has a significant impact on AVB frames especially in case of a compact schedule

with consecutive TTE frames. However by reducing the Maximum transmission unit (bytes) and

optimizing the schedule by changing the gap size, the performance of AVB and BE traffic can be

improved. Additionally [25] describes a software architecture and analysis for the co-existence

of AVB and TTE traffic.



Figure 2.8: Co-existence of AVB, TTE and BE traffic [10]


Chapter 3

Time Synchronization

3.1 Introduction

This section gives a brief description about the time-synchronization, its need, the IEEE 1588

and IEEE 802.1AS standard, the working principle and related work.

The need for time-synchronization depends on the application being developed. For exam-

ple a person during airport transit has to have a close eye on the time displayed in the airport

clock so that he does not miss his flight. Many systems require a precise sense of time. In a

manufacturing plant which is completely automated a common notion of time is very essential

for the effective functioning of the plant. With the emergence of distributed processing there

has been more emphasis on time-synchronization.

To give an intuitive idea, consider a bunch of computers with their own clock as shown in

Figure 3.1. The computers are inter-connected by a network. In order to synchronize these

clock they need to exchange time through messages. IEEE 802.1AS (gPTP) is nothing but a

specific way of doing this. gPTP is a specification of messages and the mechanism of exchang-

ing these messages to accurately pass on the time of a reference clock to all the entities in the

network. The synchronization process does not end with just exchanging this information once.

These clocks experience drift and hence this has to be done frequently. The analysis of the

gPTP is the key focus of this thesis. We will discuss this in detail in the following sections.

42

CHAPTER 3. TIME SYNCHRONIZATION

Clock1

Clock2

Network

Clock1

Clock2 Clock 4

Network

Clock3

Synchronization

Clock3

Clock4

Figure 3.1: Idea of Time Synchronization

There are many ways of achieving time-synchronization which include the Network Time

Protocol (NTP), the Precision Timing Protocol (PTP), the pulse per second input from Global

positioning system (GPS) receiver etc. Table 3.1 shows the comparison between different syn-

chronization methods.

Table 3.1: Comparison of different synchronization protocols[20]

S.No Parameter NTP PTP GPS

1 Network size Large area Few subnets Large area

2 Cost Low Low High

3 Accuracy millisecond sub-microsecond sub-microsecond

4 Time source Internet Network (Grand-Master) Satellites

5 Computation requirement Low Moderate Moderate

3.2 Synchronization terminology

We consider a network with two nodes and connected by a switch. Figure 3.2 gives a graphical

representation of the various and frequently used terminology related to the synchronization

protocol.


Sync

Node aPort_in

Switch bPort_out

Node c

Sync

Time at Node a

Time at Node C

Ingress

Egress

(a) Slave Offset

(c) Residence Time

Sync

Sync

Egress

Ingress(b) Slave

Peer Delay

Egress

Ingress(b) Switch Peer Delay

(d) Sync Interval

(e) Peer Delay interval

Pdelay_Req

Pdelay_Req Pdelay_Req

Pdelay_Req

Figure 3.2: Synchronization Terminology

a. Slave offset: The Slave offset is the calculated time offset of the slave with respect to

the Grand-Master. This calculated value is used to correct the clock. The slave offset is

calculated in nanoseconds.

b. Peer delay: It is the measured propagation delay on the link between two clocks at both

ends of the link. It is measured in nanoseconds. The slave peer delay is the propagation

delay between the switch and the slave. The switch peer delay is the propagation delay

between the switch and the Grand-Master. It is calculated by exchanging peer delay

messages.

c. Residence time: It is the measured time spent by the Sync message on the switch. In

case of a network with more than one switch this is calculated by each switch on the path.

This is measured in nanoseconds.

d. Sync interval: It is the interval between successive Sync messages.

e. Peer delay interval: It is the interval between successive PDelay Req messages (mea-

surement period of peer delay).

3.3 IEEE 1588 and IEEE 802.1AS

IEEE 1588 is a synchronization protocol which is used to establish a common time reference

between different nodes in a network. This defines a master-slave architecture for clock distri-


bution among different clocks in the network. The IEEE 802.1AS which is part of the AVB

standards is a profile of the IEEE 1588. The IEEE 802.1AS is further simplified for use in

automotive E-AVB networks.

3.3.1 Messages

The following messages are defined as part of the IEEE 1588 / IEEE 802.1AS standard. Event

messages:

1. Sync : Message that is used as a reference for passing the reference time from the Grand-

Master to all the slave nodes.

2. Delay Req : Message that is sent by the slave node to the Grand-Master during the

calculation of the path delay using the End-to-End delay mechanism.

3. Pdelay Req : Message that is exchanged between peers to calculate the path delay using

Peer delay mechanism.

4. Pdelay Resp : Message that is exchanged between peers to calculate the path delay using

the Peer delay mechanism. This message contains the arrival time of the Pdelay Req

message.

General messages:

1. Announce : Message used to exchange clock properties with other nodes in the network

as part of the Best Master Clock Algorithm (BMCA).

2. Follow Up : Message that contains the Time-stamp of the Sync message.

3. Delay Resp : Message that is sent by the Grand-Master during the calculation of the path

delay using End-to-End delay mechanism. It contains the arrival time of the Delay Req

message.

4. Pdelay Resp Follow Up : Message that is exchanged between peers to calculate the path

delay using the Peer delay mechanism. This message contains the departure time of the

Pdelay Resp message.

5. Management : Management messages are used to access attributes and to generate certain

events.

6. Signaling : It is a message used to adjust the rate of reception of messages.

3.3.2 Clocks

The different types of clocks associated with the time-synchronization protocol can be broadly

classified into:

a. Ordinary clock.

b. Transparent clock.

c. Boundary clock.



Ordinary clock

The ordinary clock can be one of the following three types:

• Slave only This type of clock can act only as a slave as the name suggests which adjusts

its time based on the master.

• Master / Slave clock This type of clock can behave either as a master or slave. This type

of clock acts as a slave when there are other clocks in the network which have better clock

properties than itself. It acts as a master when there are no other clocks capable of being

a master.

• Grand-master clock This type of clock acts only as a master and never assumes the role

of a slave. It has a good clock quality and has an accurate source of time like GPS etc.

Transparent clock

This clock performs the time-stamping operation whenever a Sync message arrives or departs.

A Sync message enters the transparent clock device and a hardware time-stamp is generated.

It then enters the core switching element and departs through a different network port. While

in the core switching element it may be queued due to a busy port. The departure and arrival

timestamps are used to update the correction field in the Follow Up message in case of a two-

step synchronization. If the transparent clock is a one-step clock, it has to update the Sync

message, which also has a correction field, on the fly.

Figure 3.3: Transparent clock [11]

The Transparent Clock (TC) comes in two flavours, E2E and P2P. Each of these has its

own advantages or disadvantages. Table 3.2 gives a comparison between the E2E and P2P.



Table 3.2: Comparison of E2E and P2P transparent clocks

S.no Parameter E2E-Transparent Clock

(TC)

P2P-TC

1 Visibility Master sees all slaves Hierarchical

2 Scalability Linear Linear

3 Calculation Calculates residenceTime Calculates residenceTime and

peerDelay for every connected

port

4 Architecture limitations None One:One connection on each

link

5 Delay calculation New calculation on master

change

All peerDelays are computed

beforehand so Grand-Master

change does not affect much.

Boundary clock

A boundary clock has one port which is in a slave state and gets time from a master clock.

All other ports are in a master state which spread time to downstream slaves. So instead of

tracking Sync messages and updating correction fields it absorbs Sync messages in the slave

port, sets its clock, and then generates new Sync messages through all the master ports.

Figure 3.4: Boundary clock [11]

3.3.3 Comparison of IEEE 1588 and 802.1AS

The IEEE 802.1AS (gPTP) is a profile of the IEEE 1588 (PTP) protocol and hence it is

important to understand how the IEEE 802.1AS protocol differs from the IEEE 1588 protocol.

The IEEE 802.1AS has been adopted for automotive applications with some modifications.



Table 3.3 gives comparison of the availability of the messages in IEEE 1588, IEEE 802.1AS

and IEEE 802.1AS (automotive) respectively. Table 3.4 gives a brief comparison between the

features of IEEE 1588, IEEE 802.1AS and IEEE 802.1AS (automotive) respectively.

Table 3.3: Comparison of message usage in IEEE 1588, IEEE 802.1AS and IEEE 802.1AS

(automotive)

S.No Message IEEE 1588 IEEE 802.1AS IEEE 802.1AS (auto)

1 Announce X X 7

2 Sync X X X

3 Follow up X X X

4 Delay Req X 7 7

5 Delay Resp X 7 7

6 Pdelay Req X X X

7 Pdelay Resp X X X

8 Pdelay Resp Follow Up X X X

9 Signaling X X X

Table 3.4: Comparison of IEEE 1588, IEEE 802.1AS and IEEE 802.1AS (automotive)

S.No Parameter IEEE1588 IEEE802.1AS IEEE802.1AS (auto)

1 Sync message 1-Step, 2-Step 2-Step 2-Step

2 Delay mechanism E2E,P2P P2P P2P

3 Best Master

Clock Algorithm

(BMCA)

Yes Yes (Different

from IEEE 1588)

No

4 Sync Interval Not-specified 125ms 31.25ms, 125ms, 1s

5 Delay interval Not-specified 1s 1s - 8s

6 Path trace Not-specified Yes Yes

7 End node Clocks Slave only,

TC,BC, ordinary

TC, BC, ordinary TC, Slave only, Grand-

Master

8 Peer delay calcu-

lation

Not-specified done on all port of

TC

Sufficient to calculate

port connected to

Grand-Master

3.4 Working principle

The IEEE 802.1AS (gPTP) protocol has many mechanisms to achieve the synchronization

among the nodes in the the network. In the following section these mechanisms are explained

in brief.



3.4.1 Best Master Clock Algorithm

The synchronization hierarchy is created from the available nodes using the BMCA. The BMCA

algorithm determines a spanning tree for the synchronization and sets the Grand-Master as its

root [9]. The algorithm involves the exchange of Announce messages and results in the selection

of a Grand-Master which would then serve as the reference for all other clocks in the network.

The Announce messages contain information about the respective properties of the clock that

enable all other nodes to compare these properties and select a Grand-Master.

Figure 3.5: BMCA spanning tree with Master-port Slave-port Disabled-port Passive-port [12]

The IEEE 802.1AS (gPTP) BMCA differs from the IEEE 1588 (PTP) BMCA in the follow-

ing ways [26]:

• In gPTP a time-aware system cannot be a slave only clock where as this is possible in PTP

and hence all time-aware systems are required to participate in best master selection.

• In gPTP there is no foreign master configuration as in PTP.

• In gPTP there is no pre-master state of a port determined as a master as in PTP.

3.4.2 Time-Stamping Mechanism

Time-stamping is an important aspect of the time synchronization. This is one of the properties

that decides the quality of synchronization. All the messages that are sent over the Ethernet

are time-stamped. Figure 3.6 shows the various levels of the stack where time-stamping can be

performed. The Time-stamping accuracy depends on how close the Time-stamp is acquired to



PHY

MAC

Drivers

IP gPTP

UDP

gPTP

MII

Software – lowaccuracy

Hardware assisted – High accuracy

Hardware –Highest accuracy

Inaccuracy

High

Low

Least

Figure 3.6: Software and Hardware time-stamping

the physical layer. The closer the source of Time-stamp to the physical layer and the lesser is

the jitter [27].

Software Time-stamping solutions take the Time-stamp at either the application or driver

level. The inaccuracy associated with this is very non-deterministic. This is primarily due to the

jitter associated with the software stack. This jitter depends on various factors like operating

system, other applications running along with gPTP, other applications using the network stack,

external interrupts etc. However Time-stamping at the driver level would significantly reduce

the jitter this requires the drivers to be changed.

Hardware-Assisted Time-stamping solutions take the Time-stamp from the link between

the Medium Access Control (MAC) and the physical layer. The MAC is combined with a time-

stamping module to support precise time-stamping of incoming and outgoing gPTP frames.

It has a very low inaccuracy compared to the Software Time-stamping. In order to read the

Time-stamps the gPTP application would require an interface to the Time-stamping unit. In

case of Linux this provided by the SO TIMESTAMPING socket option of the kernel.

The paper [28] presents the performance analysis of the IEEE 802.1AS using hardware-assisted

Time-stamping. The average offset achieved was 5µs. This is not sufficient for automotive

networks. The standard also requires the in-accuracy to be maximum 1µs.

Hardware Time-stamping solutions Time-stamps the messages in the physical layer external

to the micro-controller. This is the most accurate Time-stamping solution as the jitter associ-

ated is the least with respect to the software and hardware assisted time-stamping solutions and

the time-stamp acquired in the Physical layer (PHY) is the actual time of egress of the message.



The DP83640 from Texas instruments is a device that supports this. Since the Time-stamping

is done outside the micro-controller it reduces the cost of the micro-controller. In that case a

simple micro-controller without any dedicated hardware for time-stamping can be used. Table

3.5 shows the comparison of the different Time-stamping methods discussed above.

However the accuracy of the time-stamp generated in the PHY also depends on the frequency

of the clock of the PHY. From the above discussed time-stamping solutions I would expect the

Hardware-Assisted time-stamping to have more accuracy than the other solutions as the clock

used is within the micro-controller which would typically have a higher frequency of operation

than the PHY.

Table 3.5: Comparison of time-stamping methods

S.No Parameter Software Hardware-assisted Hardware

1 Jitter High Low Least

2 Platform Independent Dependent Dependent

3 Resources None Software routine to read

time-stamps

Software rou-

tine to read

time-stamps

4 Implementation Simple Complex Complex

5 Sources of Error applications,

OS,interrupts etc.

Incoming and outgoing

network traffic

Incoming and

outgoing network

traffic

6 Complexity Simple relatively complex complex

7 Slave offset µs to ms ns ns

8 Cost Less High relatively low

3.4.3 Synchronization Mechanism

Two Step

A Sync message is frequently sent from the master to the network to announce its time. In case

of the two step mechanism (Figure 3.7) the Sync is sent and the Time-stamp of its egress time

is recorded, fetched and sent to the slave through the Follow Up message. Once the Sync is

received by the slave it initiates the E2E delay mechanism to find the path delay with respect

to the Grand-Master. The Follow Up message contains [26]

• The preciseOriginTimestamp of the Sync message.

• The Cumulative rate Ratio.

• The Correction field.



The offset is calculated as per the Equation 3.1 and the path delay is calculated as per the

Equation 3.2 [13].

Offset =t2 + t3 − t1 − t4

2(3.1)

Delay =t2 + t4 − t1 − t3

2(3.2)

t1 current = preciseOriginT imestamp+ Correctionfield+ peerDelay (3.3)

Where

• t1 and t2 are the egress and ingress times of the Sync respectively.

• t3 and t4 are the egress and ingress times of Delay Req and Delay Resp messages respec-

tively.

Note: The current time of the Grand-Master clock calculated by the slave is as mentioned in

Equation 3.3.

t2

t3

t4

Sync

Delay_Request

Delay_Response

t1

Master Slave

t1

t4

Follow_Up

Figure 3.7: Two-step synchronization mechanism [13]



One Step

The one-step synchronization (Figure 3.8) is similar to the two-step mechanism but the difference

is that an accurate time-stamp is placed in the Sync message on the fly. Even though one-step

synchronization is economical it is expected to be less precise than the two-step synchronization

as the time-stamping will not be accurate as it has to be inserted into the message while it is

leaving. Further the One-step implementation requires the PHY to support Time-stamping.

Table 3.6 gives a comparison between one and two step mechanisms.

t2

t3

t4

Sync

Delay_Request

Delay_Response

t1

Master Slave

Time stamp

inserted

t1

t4

Figure 3.8: One-step synchronization mechanism [13]

3.4.4 Delay Mechanism

The selection of a delay measurement mechanism is based on the application and gPTP ca-

pability of the devices. The Peer-to-peer delay measurement mechanism is best in a network,

where all switches are PTP capable, i.e. they are either transparent clocks or boundary clocks.

If there are going to be any non-PTP aware switches, then we may want the end-to-end delay

measurement [29].



Table 3.6: Comparison of One-step and Two-step synchronization

S.No Parameter One-step Two-step

1 Time-stamp Accuracy Less accurate More accurate

2 Time-stamping PHY Software, MAC, PHY

3 Time-criticality Correction field update is time

critical - done on the fly.

Correction field update is not

time critical -done in Fol-

low Up.

4 Messages per interval 3 4 (with E2E) - 5 (with P2P)

In Figure 3.7 we can see the E2E delay measurement mechanism. Once the Sync and Fol-

low Up messages are received the slave clock initiates a Delay Req which reaches the master

and is time-stamped. The master then sends a Delay Resp with the arrival time of the De-

lay Req message. There is however a catch to this, The link is assumed to be symmetric i.e.

the forward delay is equal to the reverse delay.

Figure 3.9 shows the Peer to Peer (P2P) delay measurement mechanism. In this type of mea-

surement a clock sends a Pdelay Req message and the departure time is noted. The clock that

receives the Pdelay Request message responds with a PDelay Resp message with the arrival time

of the PDelay Req message and a PDelay Resp Follow up message with the departure time of

PDelay Response message. With the available time stamps the delay is calculated as per Equa-

tion 3.4. Note: A one-step version of P2P is also possible with the time-stamps incorporated in

the message [30].

peerDelay =t2 − t1 + t4 − t3

2(3.4)

Where

• t1 and t2 are the egress and ingress time-stamps of the PDelay Req message respectively.

• t3 and t4 are the egress and ingress time-stamps of the PDelay Resp message respectively.

Table 3.7 gives a comparison between the E2E and P2P delay mechanisms.

Table 3.7: Comparison between E2E and P2P delay mechanisms

S.No Parameter E2E P2P

1 Number of messages 2 3

2 Dependence Arrival of Sync message Independent of Sync Message

3 Connection type One to many One to one

4 Slave Visibility All slaves visible to master Master does not see all the

slaves

5 Standard IEEE 1588 IEEE 1588 and IEEE 802.1AS

6 Synchronization traffic Relatively high at the link

connected to master

Less



t3

t1

PDelay_Req

PDelay_Resp

Clock1 Clock2

Timestamp

PDelay_Resp_Follow_up

t2

t4

Timestamp

t3

t2

Figure 3.9: Peer delay mechanism [13]

3.4.5 Rate Ratio

The neighborRateRatio is ”the measured ratio of the frequency of the Local Clock entity of the

time-aware system at the other end of the link attached to this port, to the frequency of the Local

Clock entity of this time-aware system”[14]. The cumulative rateRatio is the ratio of frequency

of the Grand-Master to the local entity of the time-aware system[14]. It is the product of the

most recently received rateRatio multiplied by the neighborRateRatio. This will enable us to

do all calculations with reference to the Grand-Master time base.

The neighborRateRatio is calculated by using the departure and arrival times of a frequently

received message as per Equation 3.5. Figure 3.10 shows how rate ratio is calculated. The Sync

or the PDelay Resp message can be used as a reference for calculating the rate ratio as both

are frequently arriving messages.

neighborRateRatio =(t1n − t1)

(t2n − t2)(3.5)

Where

• t1n and t1 are the previous and current egress times of the message.

• t2n and t2 are the previous and current ingress times of the message.



t2

t1

Clock 1 Clock 2

t2_n

t1_n

Figure 3.10: Rate ratio calculation[14]

3.4.6 Working scenario

Figure 3.11 gives a brief overview of the working scenario of the time synchronization in a

system.



Sync

Node a

Switch

Controller

t1

Phy / MAC

Port_in

Switch b

PTP

Application

Follow_up (t1,Ca,Ro)

Ti

me

st

am

p

Port_out

Node c

t1_a

t1_b

t1_a

t1_b

Cb = Ca + (t3 –

t2)*rR + Pd * rR

Follow_up (t1,Cb,Ro’)

Sync

Ti

me

st

am

p

Ti

me

st

am

p

Phy / MAC

Ti

me

st

am

p

Ti

me

st

am

p

t2

PDelay_Request

PDelay_Response

PDelay_Response

_Follow_up

t1_p

t2_p

t3_p

t4_p

t3_p

Ti

me

st

am

p

Ti

me

st

am

p

Ti

me

st

am

p

PTP

Application

PDelay_Request

PDelay_Response

PDelay_Response

_Follow_up

t1_p

t2_p

t3_p

t4_p

t3_p

Ti

me

st

am

p

Ti

me

st

am

pT

im

es

ta

mp

Ti

me

st

am

p

Pd = (t2_p -

t1_p + t4_p -

t3_p) /2

Figure 3.11: Working Scenario of the IEEE 802.1AS protocol

• The Master node sends the Sync message. The Switch receives the Sync message and

forwards it on all its ports.

• The ingress and egress times are recorded by the switch for each of the ports and the

residence time of the Sync is calculated.

• The Correction field is calculated for each port using the residenceTime, peerDelay and

the rateRatio.



• The correction field on the Follow Up message is updated and forwarded to all the respec-

tive ports.

• The peerDelay of the link connected to the master is calculated by the switch as mentioned

in Section 3.4.4. Similarly the peerDelay of link connecting the switch and the slave is

calculated by the slave. In this all network delays are accounted.

• With the information from the Sync and the Follow Up message information the slave

calculates the offset with respect to the master and corrects its time.

3.5 Other related work

Paper [12] presents the results of the IEEE 802.1AS simulation model. The evaluation gives the

following information:

• The Synchronization process is not influenced by high network load (refer figure 3.13).

• The Grand-Master synchronization interval has a significant influence on the performance

(Figure 3.12).

• An averaging filter for propagation delay improves the synchronization performance.

Figure 3.12: Effect of Sync interval [12]

Figure 3.13: Effect of traffic on Synchronization [12]


Chapter 4

Experimental setup

This chapter describes the selection of hardware and software for the end-nodes, the software

development for the switch and the topology of the network.

4.1 End node

4.1.1 Hardware selection

The first step in setting up a network was the selection of the End-Nodes. The development

boards (end-nodes) selected for the implementation use a Freescale i.MX6Solo processor. The

i.MX6 based device was selected because the i.MX6 has a MAC combined with a time-stamping

module to support precise time-stamping of incoming and outgoing frames [31]. The Kon-

tron board (Figure 4.1) was selected initially but lacked the support for a kernel that had the

SO TIMESTAMPING socket implementation which was required for hardware assisted Time-

stamping.

We then selected the RIoTboard (Figure 4.2) which also uses a i.MX6Solo processor. Fur-

ther this had Yocto support with Linux kernel that supports hardware time-stamping. The

Yocto Project [32] is an open source collaboration project that provides templates, tools and

methods to create custom Linux-based systems for embedded products. The following are the

key features of the RIoTboard:

1. Freescale iMX6 solo processor (ARM Cortex A9 MPCore 1GHz).

2. Yocto Linux (kernel 3.10) with hardware time-stamping support.

3. HDMI, Audio out, Camera support etc.

4. 10M/100M/Gb Ethernet Interface

5. IEEE 1588 compliant MAC.

4.1.2 Software selection

The next step was the selection of the PTP application that would run on the RIoTboards

to establish synchronization between them. A number of open-source solutions were available

CHAPTER 4. EXPERIMENTAL SETUP

Figure 4.1: Kontron Board

[15]Figure 4.2: RIoTboard [16]

which included ptpd, ptpd2 [33], linuxptp [34], openptp [35] etc.

Linuxptp was selected because of its support for both one and two step synchronization. The

linuxptp application uses the SO TIMESTAMPING socket to retrieve the time-stamps gener-

ated by the MAC. SO TIMESTAMPING is an interface that generates timestamps on reception,

transmission or both and supports multiple time-stamp sources, including hardware [36].

Figure 4.3 gives an overview of the functioning of linuxptp. The linuxptp application ptp4l

on the Grand-Master sends the Sync and Follow Up messages through the network. The slave

on receiving these messages time-stamps them and the ptp4l application running on the slave

calculates the offset and corrects the PTP Hardware Clock (PHC). The phc2sys application is

then used to update the Linux system time using a servo mechanism [37]. We consider the PHC

as our reference.

Figure 4.3: Linuxptp working [17]

4.1.3 Installation and Configuration

After the selection process the next step was to get the Yocto image with the Linuxptp (V1.5)

and hardware Time-stamping enabled running on the RIoTboards. A Linux (Ubuntu) environ-

ment was used for the compilation. The images generated were mounted onto an SD card with

the RIoTboards configured to boot from the connected SD card.

Once the two boards were flashed a IEEE 802.1AS (gPTP) configuration had to be created. The

gPTP configuration was available as part of the Linuxptp source which needed modifications in

order to get the boards up and running.



4.1.4 Challenges

Installing the Linuxptp (V1.5) was a small challenge as a new recipe had to be created for Linux-

ptp and the image was re-compiled [38]. The pre-compiled image available from the RIoTboard

community had linuxptp (V1.3). This version was prone to bugs and hence a migration to V1.5

was necessary. Moreover V1.5 had many additional configurable features and was verified for

gPTP functionality.

A sanity check was performed by connecting the two nodes back to back and running the

synchronization software. During this phase initially when the application was started the

nodes did not start the synchronization process. On analysis it was found that the two nodes

were exchanging only the peer delay messages. A gPTP node would start synchronization only

if it is connected to another gPTP capable port. A port is marked as gPTP capable only if

the peer delay is less than the neighbor propagation delay threshold. This parameter was then

identified and increased to a larger value and synchronization was established.

4.2 Switch

Removed due to confidentiality.

4.3 Topology

The topology of the setup is a simple star topology as seen in figure 4.4. The two nodes (Grand-

Master and slave) are connected to two ports (ports 1 and 3). The grandmaster clock is the

primary time source, the switch acts as a TC and enables the slave clock to synchronize with the

Grand-Master clock. Port 4 is configured to be the host port and is connected to the on-board

micro controller.



Port 1 Port 2 Port 3

Port 0

SJA1105

Port 4

LPC 1788

Ethernet

End Node 2End Node1

PC (Logging)

Serial

Port

Serial port access

Figure 4.4: Network Topology with 1 Switch

Figure 4.4 shows a star topology with two switches cascaded together with the Grand-Master

connected to one switch and the slave connected to the other. This is another topology that

was explored to see the impact of network scaling on the synchronization. Further a 2 bridge/3

hop would be typical for automotive networks [24].



Switch1

Slave1

Slave2

Ethernet

Ethernet

Slave3

Ethernet

GMEthernet

Switch2

Slave4

Ethernet

Slave5

Ethernet

Figure 4.5: Network Topology with 2 Switches

4.4 Software tools

The following software tools were used for the set-up and experiments.

• TeraTerm for communicating with the end nodes and reading switch serial output.

• VmWare for running Ubuntu 12.04 (Compiling images for RIoTboard)

• Python for post-processing.

• Win32Diskimager for mounting the image on SD card

• Matlab for post-processing.

• Keil µVision for switch software development.

• Ostinato an open source traffic generator was used to generate the traffic for the experi-

ments.


Chapter 5

Experimental Methodology

5.1 Introduction

To study the performance of the synchronization protocol we basically try to understand the

following:

a. Effect of Synchronization parameters on the Quality of synchronization.

b. Effect of System and network parameters on Quality of synchronization.

c. Effect of Synchronization parameters on the System and network.

To study the above mentioned effects and properties of the synchronization protocol we first

identify the parameters that would affect the synchronization process, define experiments and

perform them. The following are the identified key parameters:

Sync Interval: It is the interval between successive Sync messages. The Sync interval plays

a key role in the performance of the synchronization protocol. Varying the Sync interval would

affect the frequency of the offset calculation. This would affect offset of the slave with respect

to the master.

Peer delay interval: Similar to the Sync interval the Peer delay interval also plays a signifi-

cant role as the calculated peer delay is used in the offset calculation. Further an accurate peer

delay calculation would increase the accuracy of the offset calculation.

Time-stamping: The time-stamping mechanism affects the offset calculation to a great ex-

tent. This is an interesting parameter to study as the egress time-stamp of the Sync message

depends on the time-stamping mechanism and in-accuracies in this could tamper the synchro-

nization process.

Number of switches: Varying the number of switches would significantly increase the net-

work delay and jitter associated with it thus affecting the offset calculation.

CHAPTER 5. EXPERIMENTAL METHODOLOGY

Traffic: The traffic on the network should however not impact the synchronization but would

affect the synchronization message queuing at the switch. Further in real world applications

the synchronization traffic co-exists with the AVB traffic and hence it would be interesting to

study the impact of network traffic.

Processor Load: The effect of processor load is important as this is close to the real world

applications also this will will also affect the generation of the Sync messages at the master and

the calculation of the offset at the slave.

5.2 Metrics

The following are the performance metrics selected for the analysis of the synchronization:

Slave offset

The slave offset is the best measure to study the quality of synchronization. The slave offset

can be characterized by the following metrics:

• Deviation range: It is the maximum difference in time of the slave clock from the reference

clock (Grand-Master). It is calculated at the slave and expressed in nanoseconds. It is

expressed as a combination of positive and negative peak values of the offset.

• Standard deviation: The standard deviation of the offset gives information on how much

the slave’s time deviates from the mean offset value. It is expressed in nanoseconds.

• Offset distribution: It is a distribution plot (histogram) of the slave offset. This gives us

information about the level of spread of the offsets.

The calculation of the slave offset is affected by three main parameters :

1. The Residence time.

2. The Slave and Switch peer delays.

3. The egress timestamps of the Sync message.

Peer delay

The peer delay is calculated by the slave with respect to the switch and by the switch with

respect to the master. This is an important factor as in-accuracies in this calculation can affect

the accuracy of the offset calculation at the slave. It is expressed in nanoseconds.

Residence time

Residence time is the amount of time spent by the Sync message on the switch. It is an

important parameter which also affects the offset calculation at the slave. It is expressed in

nanoseconds.



Synchronization time

It is the time taken from the start of the synchronization to the point after which the slave

offset value remains within a the deviation range. It is expressed in in seconds.

BMCA time

It is the time taken to elect a master among a number of Grand-Master capable end-nodes in

a network. It is expressed in seconds.

Note: This parameter is not applicable for the automotive E-AVB because the

automotive E-AVB does not have the BMCA functionality.

Time-stamping inaccuracy

The time-stamping is one of the key factors that affect the offset calculation as this is used to

calculate the current time of the master at the slave. It is calculated as the difference between

successive timestamps of the Sync message with respect to the Sync interval. This parameter

is purely dependent on the stack and not the time-stamping mechanism.

Bandwidth utilization

This is the bandwidth utilized by the synchronization protocol in the network.

5.3 Test Procedure

This section defines the step by step testing process that will be followed to see the impact of

various parameters on the quality of synchronization. The Figure shows the various steps of the

process that will be followed during the testing. The various steps are tagged to the respective

sections below.

A. Network and Power Connections

End Nodes: The end nodes are connected the switch via the twisted pair Ethernet cables.

The end nodes are connected to a PC via RPI cables and are powered up through a 5V adapter.

Switch: The switch is powered up using a 12V supply.

B. Basic Configuration

End Nodes The IP is set in the Linux environment using the following command

ifconfig eth0 169.254.2.11x netmask 255.255.0.0

The IP can also be set statically in the /etc/network/interfaces file as follows:

iface eth0 inet static



address 192.168.1.10

netmask 255.255.255.0

Switch: The switch software contains the configurations necessary for the switch to function.

C. Test Configuration file

The configuration file is divided into sections. Each section starts with a line containing its

name enclosed in brackets and it follows with the settings. Each setting is placed on a separate

line, it contains the name of the option and the value separated by white space characters.

Empty lines and lines starting with # are ignored.

The global section (indicated as [global]) sets the program options, clock options and default

port options. Other sections are port specific sections and they override the default port options.

The name of the section is the name of the configured port (e.g. [eth0]). Ports specified in the

configuration file don’t need to be specified by the -i option. An empty port section can be used

to replace the command line option. The configuration file used is given in the Appendix C.

D. Logging

End Nodes: The inbuilt logging function of Teraterm will be used to log data displayed in the

terminal. On stopping the log the log file is saved by default on the Desktop folder of the PC.

Further Wireshark will be used to log the network traffic and to access the timestamps/data

in the Follow Up messages. Using Wireshark we can see individual packets and their contents.

The ptp4l application displays the Offset with respect to master in ns and Path delay with

respect to the switch in ns.

Switch: The residence time, rate ratio and peer delay measured by the switch are made available

through the serial interface. This is logged using Teraterm.

E. Test

After configuring the desired parameters the ptp4l application is started on all the end nodes

using the command:

ptp4l -f gPTP.cfg

F. Termination

The applications are terminated after a desired period or on completion of the test.



Network and

Power

Connections

Start

Nodes power

up

Basic

Configuration

Test

Configura

tion file

Application

Launch

Logging-start

End

Stop process

Logging-stop

Test

Completed

No

(A)

(B)

(C)

(D)

(E)

(F)

Figure 5.1: Test procedure


Chapter 6

Experiments, Results and Analysis


69

Chapter 7

Conclusion

7.1 Overview

The study was set out to explore the performance of the synchronization protocol, a part of

the E-AVB stack. The synchronization protocol has been standardized by the IEEE 802.1AS

standard and adopted with modifications for automotive applications. To achieve our goal of

understanding the synchronization protocol we framed research questions. The answers to these

questions have improved our understanding of the synchronization protocol. The current re-

search work associated with the synchronization protocol are mainly simulation based and this

analysis of the synchronization protocol provided a much clearer picture of the same.

To study the synchronization protocol a gPTP capable network was assembled and the missing

pieces were built. End nodes with good time-stamping capabilities and an open source gPTP

application were selected. The network was in-complete without a switch/bridge. A transpar-

ent switch serves the purpose of handling the network delays differentiating it from traditional

Ethernet switches, thereby improving the accuracy of the synchronization over Ethernet based

in-vehicle networks. In order to realize the transparent switch the gPTP software was developed

for the NXP SJA1105 switch. This switch being developed at NXP will take a critical place in

their product catalog for automotive solutions. Once assembled the network was verified and a

variety of tests were performed.

All the experiments were conducted in a lab and the key findings are summarized:

• The synchronization quality achieved with a normal switch between two nodes under no-

traffic conditions was within acceptable limits of the standard but the network cannot be

scaled beyond two nodes. Further with additional traffic the synchronization fails. Thus

a need for a special switch capable of handling the messages was established.

• The addition of a gPTP transparent switch between two nodes actually reduces the syn-

chronization accuracy by a factor of 4 with respect to the two nodes connected directly.

This has to be accepted for scaling the network. However on further scaling the network

by adding another switch the synchronization accuracy is deteriorated by a factor of 0.27.

70

An offset in-accuracy of ±141ns was achieved for a three hop network (which would be

the typical size of automotive networks [24]).

• Varying the sync interval has a significant impact on the synchronization process. With

low sync intervals of 31.25ms a better in-accuracy and reduced initial time synchronize

was achieved. Further a sync interval of 1s was able to maintain the synchronization

within the bounds required by the standard but with reduced performance (factor of 0.27

less). A similar behaviour was observed in the paper [12]. However the time to achieve

the Sync interval was more. Thus from an application developer point of view it would

be efficient to start the synchronization at an interval of 31.25ms and later maintain it at

a 1s Sync interval.

• The impact of the peer delay interval though not significant improves the synchronization

performance at higher intervals. Thus maintaining the peer delay interval at 8s would

yield a better performance. Further adding a moving average filter to calculate the peer

delay as mentioned in [12] improves the synchronization performance.

• Considering both the cases the bandwidth consumed with lower intervals of Sync and

peer delay intervals is high. Though utilized bandwidth is very low in comparison with

the available bandwidth increasing the Sync interval reduces the gPTP processing to be

done on the switch. Thus making the high intervals of Sync and peer delay intervals

apt choices when the network is fully operational. Further the AVnu specifications also

provides initial and operational ranges for these message intervals.

• Traffic in the network does not affect the synchronization. This was established through

our experiments. Though it affects the time-stamping in-accuracy and the residence time.

The accurate time-stamping ensures that these additional delays are properly accounted

for in the offset calculation. This establishes the findings of the paper [12].

• The Time-stamping mechanism plays a key role achieving a desired quality of synchro-

nization. This is the major source of in-accuracy for the calculation of offset as the offset

calculation is purely based on time-stamps. The hardware time-stamping is more accurate

and achieves the best quality of synchronization. However the software application can

be used for applications that do not require higher QoS. Further from our experiment we

have established that different time-stamping mechanisms can co-exist in a network with

deteriorated quality of synchronization. This would be a cost effective solution for the

initial migration from traditional system to the Ethernet networks.

• The priority of the gPTP traffic also plays a significant role. Lower and same priority

with respect to other traffic causes the synchronization to break and hence the priority of

the gPTP messages should be the highest in the network.

7.2 Recommendations for the Switch


CHAPTER 7. CONCLUSION

7.3 Future work



Appendix A

Current Solutions

This chapter describes some of the networking solutions currently in use in the automotive

industry.

A.1 Controller Area Network

The most popular automotive network is CAN. This is one of the commonly found networks

in today’s cars. It was developed by BOSCH GmbH and is governed by a number of standards

(ISO 11898). The Physical medium is a twisted pair copper wires. The most common network

speeds used in a CAN network are 250 or 500 Kbps. The access to the network is by arbitration

based on the CAN data identifiers which are either 11 or 29 bits in length. The CAN uses

a non-zero-return bit representation. Bit ”0” is the dominant bit and bit ”1” is the recessive

bit. Thus message with the lowest identifier has the highest priority. The CAN bus uses a

differential voltage mechanism for distinguishing between the dominant and recessive bits.

120Ω 120Ω

CAN H

CAN L

Figure A.1: Controller Area Network

What is typical about CAN is that it is based on the multi-master concept that allows all

the nodes to transmit their messages. It is robust, low cost and communication delays are

bounded. The CAN network has only two layers with respect to the OSI model: the physical

layer and the data link layer thus making it simple from implementation point of view. Further

CAN is a well established standard that has been in the automotive world for over 30 years.

One of the greatest benefits of CAN is the flexibility it provides. It enables the network design

73

APPENDIX A. CURRENT SOLUTIONS

engineers to introduce new ECUs in the network without much changes. The growing bandwidth

limitations are one of the limitations of CAN as it can support up to 1Mbps. Further there is

also a limitation on the length of the network. Further the bus architecture limits the ECUs

from simultaneous transmission. The bus architecture provides flexible wiring options but with

the disadvantage of having a termination in the bus and without this termination the network

does not function.

A.2 Local Interconnect Network

LIN is a serial communication protocol. It is cheap as well as slower than CAN. It was intended

to complement the CAN networks in cars to establish a hierarchical network. The LIN network

is used where the bandwidth requirements are less. A LIN cluster consists of a master and many

slave nodes connected to a common bus. For achieving a low-cost implementation, the physical

layer is defined as a single wire with a data rate limited to 20Kbit/s. In LIN networks similar to

CAN the logical 0 is dominant and a logical 1 is recessive. The LIN is a shared medium where

only one message can be transmitted at a time. Its disadvantages include a low bandwidth,

basic diagnostic capabilities, the master-slave architecture. Some of the typical applications

include controlling switches, windows etc.

LIN bus

Figure A.2: Local Interconnect Network [2]

A.3 Media Oriented Systems Transport

MOST is primarily used for infotainment in a car. It is a proprietary product of Standard

Microsystems Corporation (SMSC). It is one of few networks that enables audio video network

streaming. It has a ring network which fails to function even if one of the links is down. This

solution is costly, proprietary and non-deterministic. This led to the emergence of Ethernet as

a network for automotive application.



Figure A.3: Media Oriented Systems Transport [2]

A.4 FlexRay

FlexRay is one of the effective and accurate networking solutions. It can have data rates up to

10Mbits/s. The bus is based on a flexible time division multiplexing. There are two parts to the

time cycle: static and dynamic. The static segment offers real-time guarantee by providing a

fixed schedule where as the dynamic segment is more event based. The static segment consists

of slots which are assigned to the nodes in which it can transmit without any contention. The

static and dynamic structure of slots gives more flexibility.

The FlexRay network is very flexible with respect to topology (Figures A.4,A.5,A.6) and trans-

mission support redundancy and was designed with safety critical applications in mind. It also

has dual redundant channels (possible in Ethernet but not others). It can be configured as a

bus, a star or a multi-star network. With respect to CAN it is more deterministic, composable,

fault tolerant, flexible and it has a higher baud rate. It has some disadvantages like lower

operating voltage levels and asymmetry of the edges, which leads to problems in extending

the network length, cost and less bandwidth availability for less critical streaming media ap-

plications (maximum bandwidth of FlexRay is 10Mbps). Despite the advantages FlexRay was

more complicated to implement than CAN [2]. Ethernet will replace FlexRay for bandwidth

intensive, non-safety critical applications.



Channel A

Channel B

Figure A.4: FlexRay - Bus topology [18]

Channel A Channel A

Channel BChannel A

Channel B Channel B

Figure A.5: FlexRay - Star topology

[18]

Channel A

Channel A

Channel B

Channel A

Channel B

Channel B

Channel A

Channel B

Figure A.6: FlexRay - Hybrid topology [18]


Appendix B

Message formats

The following figures show the message formats as per [13]:

Figure B.1: Announce Message

Figure B.2: Sync Message

Figure B.3: Follow Up Message

77

APPENDIX B. MESSAGE FORMATS

Figure B.4: PDelay Req Message

Figure B.5: PDelay Resp and Pdelay Resp Follow Up Message


Appendix C

gPTP configuration

[global]

#

# Default Data Set

#

twoStepFlag 1

gmCapable 1

priority1 248

priority2 248

domainNumber 0

clockClass 248

clockAccuracy 0xFE

offsetScaledLogVariance 0xFFFF

free_running 0

freq_est_interval 1

#

# Port Data Set

#

logAnnounceInterval 1

logSyncInterval -3

logMinPdelayReqInterval 0

announceReceiptTimeout 3

syncReceiptTimeout 3

delayAsymmetry 0

fault_reset_interval 4

neighborPropDelayThresh 20000000

min_neighbor_prop_delay -20000000

#

# Run time options

#

assume_two_step 1

79

APPENDIX C. GPTP CONFIGURATION

logging_level 6

path_trace_enabled 1

follow_up_info 1

tx_timestamp_timeout 1

use_syslog 1

verbose 0

summary_interval 0

kernel_leap 1

check_fup_sync 0

#

# Servo options

#

pi_proportional_const 0.0

pi_integral_const 0.0

pi_proportional_scale 0.0

pi_proportional_exponent -0.3

pi_proportional_norm_max 0.7

pi_integral_scale 0.0

pi_integral_exponent 0.4

pi_integral_norm_max 0.3

step_threshold 0.0

first_step_threshold 0.00002

max_frequency 900000000

clock_servo pi

sanity_freq_limit 200000000

ntpshm_segment 0

#

# Transport options

#

transportSpecific 0x1

ptp_dst_mac 01:80:C2:00:00:0E

p2p_dst_mac 01:80:C2:00:00:0E

uds_address /var/run/ptp4l

#

# Default interface options

#

network_transport L2

delay_mechanism P2P

time_stamping hardware

delay_filter moving_median

delay_filter_length 10


APPENDIX C. GPTP CONFIGURATION

egressLatency 0

ingressLatency 0

boundary_clock_jbod 0

[eth0]


Bibliography

[1] “Beautiful gauges.” http://forums.thecarlounge.com/showthread.php?6983059-Beautiful-

Gauges/page4, 2015.

[2] C. M. Kozierok, C. Correa, R. B. Boatright, and J. Quesnelle, “Automotive Ethernet: The

definitive guide,” 2005.

[3] “Advanced Driver Assistance System.” http://millionstartups.com/index.php/2015/06/26/asia-

pacific-advanced-driver-assistance-system-market-is-expected-to-reach-15-5-billion-by-

2020/, 2015.

[4] W. Saleem, “1394 automotive network enables powerful, cost-

efficient in-vehicle networks for infotainment, navigation, cameras.”

http://m.eet.com/media/1052951/infotainment.jpg, 2015.

[5] P. Hank, T. Suermann, and S. Muller, “Automotive Ethernet, a holistic approach for next

generation in-vehicle networking standard.” http://itersnews.com/?p=10541, 2015.

[6] D. Olsen, “Audio video transport protocol AVTP,” http://avnu.org/wp-

content/uploads/2014/05/AVnu-AAA2C Audio-Video-Transport-Protocol-AVTP Dave-

Olsen.pdf, 2015.

[7] E. Heidinger, F. Geyer, S. Schneele, and M. Paulitsch, “A performance study of Audio

Video Bridging in aeronautic Ethernet networks,” in Industrial Embedded Systems (SIES),

2012 7th IEEE International Symposium on, pp. 67–75, June 2012.

[8] L. Bello, “Novel trends in automotive networks: A perspective on ethernet and the IEEE

Audio Video Bridging,” in Emerging Technology and Factory Automation (ETFA), 2014

IEEE, pp. 1–8, Sept 2014.

[9] H.-T. Lim, D. Herrscher, M. J. Waltl, and F. Chaari, “Performance analysis of the IEEE

802.1 Ethernet Audio/Video Bridging Standard,” in Proceedings of the 5th International

ICST Conference on Simulation Tools and Techniques, SIMUTOOLS ’12, (ICST, Brussels,

Belgium, Belgium), pp. 27–36, ICST (Institute for Computer Sciences, Social-Informatics

and Telecommunications Engineering), 2012.

[10] P. Meyer, T. Steinbach, F. Korf, and T. Schmidt, “Extending IEEE 802.1 AVB with

time-triggered scheduling: A simulation study of the coexistence of synchronous and asyn-

chronous traffic,” in Vehicular Networking Conference (VNC), 2013 IEEE, pp. 47–54, Dec

2013.

82

BIBLIOGRAPHY

[11] D. Arnold, “What Are All of These IEEE 1588 Clock Types?.”

http://blog.meinbergglobal.com/2013/10/21/ieee-1588-clock-types/, 2015.

[12] H. T. Lim, D. Herrscher, L. Volker, and M. Waltl, “IEEE 802.1AS time synchronization in

a switched Ethernet based in-car network,” in Vehicular Networking Conference (VNC),

2011 IEEE, pp. 147–154, Nov 2011.

[13] “IEEE standard for a precision clock synchronization protocol for networked measurement

and control systems,” IEEE Std 1588-2008 (Revision of IEEE Std 1588-2002), pp. 1–269,

July 2008.

[14] “IEEE standard for local and metropolitan area networks - timing and synchronization

for time-sensitive applications in bridged local area networks,” IEEE Std 802.1AS-2011,

pp. 1–292, March 2011.

[15] “Kontron smarc-samx6i.” http://www.kontron.com/products/boards-and-standard-form-

factors/smarc/smarc-samx6i.html, 2015.

[16] “Riotboard.” http://riotboard.org/, 2015.

[17] K. Ichikawa, “Precision time protocol on Linux Introduction to linuxptp,” 2014.

[18] N. I. Corporation, “Flexray automotive communication bus overview,” 2015.

[19] G. Bechtel, B. Gale, M. Kicherer, and D. Olsen, “Automotive E-AVB profile,”

http://standards.ieee.org/events/automotive/2014/17 Automotive E-AVB Profile.pdf,

2015.

[20] C. Gordon, “White paper introduction to IEEE 1588 transparent clocks,” 2009.

[21] M. Johas Teener, A. Fredette, C. Boiger, P. Klein, C. Gunther, D. Olsen, and K. Stanton,

“Heterogeneous networks for Audio and Video: Using IEEE 802.1 Audio Video Bridging,”

Proceedings of the IEEE, vol. 101, pp. 2339–2354, Nov 2013.

[22] A. Gothard, R. Kreifeldt, and C. Turner, “AVB for automotive use,” AVnu Alliance White

Paper, 2014.

[23] M. J. Teener, “No - excuses Audio/Video networking: the technology behind AVnu,” AVnu

Alliance White Paper, 2009.

[24] G. Bechtel, B. Gale, M. Kicherer, and D. Olsen, “Automotive Ethernet AVB Functional

and Interoperability Specification, Revision 1.4,” 2015.

[25] S. Rumpf, T. Steinbach, F. Korf, and T. Schmidt, “Software stacks for mixed-critical ap-

plications: Consolidating IEEE 802.1 AVB and time-triggered ethernet in next-generation

automotive electronics,” in Consumer Electronics ??? Berlin (ICCE-Berlin), 2014 IEEE

Fourth International Conference on, pp. 14–18, Sept 2014.


BIBLIOGRAPHY

[26] G. Garner and H. Ryu, “Synchronization of audio/video bridging networks using IEEE

802.1AS,” Communications Magazine, IEEE, vol. 49, pp. 140–147, February 2011.

[27] A. Dopplinger and B. Seitz, “Who doesn’t need Ethernet timestamps?.”

http://www.embedded.com/design/mcus-processors-and-socs/4008245/Who-doesn-t-

need-Ethernet-timestamps-, 2015.

[28] Y. J. Kim, J. H. Kim, B. M. Cheon, Y. S. Lee, and J. W. Jeon, “Performance of IEEE

802.1AS for automotive system using hardware timestamp,” in Consumer Electronics

(ISCE 2014), The 18th IEEE International Symposium on, pp. 1–2, June 2014.

[29] D. Arnold., “End-to-End versus Peer-to-Peer.” http://blog.meinbergglobal.com/2013/09/19/end-

end-versus-peer-peer/, 2015.

[30] D. Arnold., “One-step or Two-step?.” http://blog.meinbergglobal.com/2013/10/28/one-

step-two-step/, 2015.

[31] F. Semiconductors, “i.mx 6solo/6duallite applications processor reference manual,”

[32] Y. project. https://www.yoctoproject.org/, 2015.

[33] PTPdaemon. http://ptpd.sourceforge.net/, 2015.

[34] R. Cochran, “Linuxptp.” http://linuxptp.sourceforge.net/, 2015.

[35] Openptp. http://sourceforge.net/projects/openptp/, 2015.

[36] “Linux kernel archives Timestamping Control Interfaces,” 2015.

[37] R. Cochran, C. Marinescu, and C. Riesch, “Synchronizing the Linux system time to a

PTP hardware clock,” in Precision Clock Synchronization for Measurement Control and

Communication (ISPCS), 2011 International IEEE Symposium on, pp. 87–92, Sept 2011.

[38] T. Panda, “Riotboard Yocto: Part1: Environment setup and initial build,” 2015.

***********End of Document***********


Eindhoven University of Technology MASTER Investigation of ...Investigation of time-synchronization...

Documents

Transcript of Eindhoven University of Technology MASTER Investigation of ...Investigation of time-synchronization...