TIME SYNCHRONIZATION AND COMMUNICATION IN … · IEEE 802.1AS-REV EXAMPLE Page 11 Among other improvements, changes were done with respect to reliability of synchronization Redundancy

© 2019 Renesas Electronics Corporation. All rights reserved. IEEE Ethernet & IP @ Automotive Technology Day

Detroit, September 2019

TIME SYNCHRONIZATION AND COMMUNICATION IN REDUNDANT NETWORKS

IEEE ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY

DETROIT, SEPTEMBER 2019

THORSTEN HOFFLEIT

AUTOMOTIVE NETWORKING COMPETENCE CENTER

AUTOMOTIVE SOLUTION BUSINESS UNIT

RENESAS ELECTRONICS CORPORATION



AGENDA

Page 2

▪ Need for redundancy & time synchronization

▪ Operation of IEEE 802.1CB (Frame replication and elimination for redundancy)

and effects in case of package loss/ link loss

▪ Alternative approach to IEEE 802.1CB

▪ Improvements coming up in IEEE 802.1AS

(Timing and Synchronization for Time sensitive Applications)

▪ Summary and conclusion



IN VEHICLE CONNECTIVITYMOVE TOWARDS ZONE-BASED ARCHITECTURE WITH ETHERNET BACKBONE

Page 3



IN VEHICLE CONNECTIVITYMOVE TOWARDS ZONE-BASED ARCHITECTURE WITH ETHERNET BACKBONE

Page 4

▪ New E/E architectures will use Ethernet as backbone

▪ Limited bandwidth and latency are constraints

▪ Reliable service oriented communication is key

▪ Mechanisms are required to guarantee data delivery

▪ IEEE 802.1CB

▪ IEEE802.1AS-rev



IEEE 802.1CBEXAMPLE CRITICAL STREAMS

Page 5Page 5

Talker Listener

Listener

Sequence generation function

Individual recovery function/ stream splitting

Sequence recovery function

Stream identification

Every stream from a talker

undergoes identification function

Examines sequence numbers and

discards duplicates from single

ingress port. Duplicate frames if

needed to all configured outputs.

Examines sequence numbers

and discards duplicates from

different ingress ports.

Finally only one package is

received by listener system and

removes sequence number

At talker side two “identical”

packages are created (member

streams). “R-Tag” with sequence

number is added.



IEEE 802.1CBSYSTEM CONTEXT

Page 6

▪ Failure models in IEEE 802.1CB

▪ Frame loss

▪ Link loss

▪ Stuck transmitter

▪ Ring architecture also supports component

failure

▪ Redundant path keeps communication

ongoing

▪ Additional system countermeasures required

▪ Redundancy does not come for free

▪ Architectural considerations

▪ Additional cables

▪ Additional ports

▪ Increased communication traffic



SEQUENCE ORDERINGCHALLENGE FOR APPLICATION

Page 7

Challenges:

▪ Package disordering (depends on traffic type )

▪ History list depth

T1 T2 T3 T4 T5 T6

T1’ T2’ T4’ T5’ T6’

T

A

T1’’ T2’’ T3’’ T4’’ T5’’ T6’’B

CC

T7

T7’

T7’’

D T1’’’ T2’’’ T3’’’ T4’’ T5’’ T6’’C

L T1’ T2’ T4’ T5’ T6’ T3’’’ T7’

T L

A

BD

C

Countermeasures:

▪ Avoid bursts by using shapers/ use preemption

▪ Reorder sequence with help of sequence numbers in transport layer

▪ Accept disordered packages and solve in application layer

T3’ CB bridge


Detroit, September 2019Page 8

ALTERNATIVE APPROACH –VLAN SPLITTING


Detroit, September 2019Page 9

▪ Characteristics

▪ Talker and listener are responsible for replication

and elimination in software

▪ Increased traffic on joint paths

▪ Bridges can be realized with standard products

▪ No guaranteed interoperability

− E.g. special redundancy layer in stack

− Redundancy aware application

− Everything vendor specific

ALTERNATIVE APPROACH –VLAN SPLITTING



COMPARISONIEEE 802.1CB VS. VLAN BASED REDUNDANCY

Page 10

▪ IEEE 802.1CB

▪ Special hardware required in bridges

▪ Endpoints can handle in software with low effort

▪ Tooling support for bridge configuration

▪ Standard, industry will support

▪ VLAN based approach software based

▪ No special hardware features required

▪ Can tune requirements of application (disordering)

▪ Increased traffic on joint paths

▪ No guaranteed interoperability

▪ Same failure modes

▪ Same targets achievable with both methods

▪ Both methods are applicable for routable protocols only



REDUNDANCY FOR LINK-BASED PROTOCOLSIEEE 802.1AS-REV EXAMPLE

Page 11

▪ Among other improvements, changes were done with respect to reliability of synchronization

▪ Redundancy and reliability considerations in IEEE 802.1AS-rev

▪ Multiple timing domains

▪ Multiple “active” grand masters (GM)

▪ Smooth transition from one GM to another

▪ Improved failure detection mechanisms

▪ Slave port monitoring

▪ To operate these features, devices in system needs to support new standard



REDUNDANCY FOR LINK-BASED PROTOCOLSIEEE 802.1AS-REV REDUNDANT PATH

Page 12

Principle:

▪ One clock source used for multiple domains

▪ Link redundancy

Clock master

gPTP

gPTP

Clock slave

gPTP

gPTP

gPTP

gPTP

Clock slave

Notes

▪ GM single point of failure



REDUNDANCY FOR LINK-BASED PROTOCOLSIEEE 802.1AS-REV REDUNDANT SOURCE

Page 13

Clock master

gPTP

Clock master

(standby)

gPTP

gPTP

gPTP

gPTP gPTP

Clock slave

Principle:

▪ Independent back-up GM (hot standby)



REDUNDANCY FOR LINK-BASED PROTOCOLSIEEE 802.1AS-REV REDUNDANT SOURCE

Page 14

Clock master

gPTP

Clock master

(standby)

gPTP

gPTP

gPTP

gPTP gPTP

Clock slave

Principle:

▪ Independent back-up GM (hot standby)

▪ Two independent timing domains

Notes

▪ Link failure would split into two independent

timing domains (no link redundancy)



REDUNDANCY FOR LINK-BASED PROTOCOLSIEEE 802.1AS-REV REDUNDANT PATH & SOURCE

Page 15

Clock master

gPTP

gPTP

Clock master

(standby)

gPTP

gPTP

gPTP

gPTP

gPTP

gPTP

gPTP

gPTP

gPTP

gPTP

Clock slave

Principle:

▪ Independent back-up GM (hot standby) with

two independent timing domains

▪ Time synchronization over

redundant path

Notes

▪ No domain split when link failure



SUMMARY IEEE 802.1AS-REV RELIABILITY ENHANCEMENTS

Page 16

▪ IEEE 802.1AS:2011 is based on IEEE1588

▪ Redundancy can be achieved already using IEEE1588

− For automotive use-cases, tailoring is still required

− Interoperability could be issue

▪ IEEE 802.1AS-rev gives a standardized way to improve reliability of timing synchronization

▪ Redundant network paths can be used for time synchronization

▪ “Hot standby” grandmasters

▪ Improved diagnostic functions

▪ Tooling and industry support

▪ Interoperable



REDUNDANCY FOR LINK-BASED PROTOCOLSIEEE 802.1AS-REV + IEEE 802.1CB

Page 17

Clock master

gPTP

gPTP

Clock slave

gPTP

gPTP

gPTP

gPTP

Clock slave

Principle:

▪ Use 802.1CB for critical traffic and 802.1AS-rev

for time synchronization

Notes

▪ No interference



SUMMARY

Page 18

▪ We cannot rely on the network by default

▪ Redundancy does not come for free

▪ IEEE 802.1CB only for routable protocols

▪ For link-based protocols different solutions are required

▪ IEEE 802.1AS-rev has several reliability mechanisms available

▪ When using IEEE 802.1CB keep in mind that

▪ packets may arrive out of order

▪ packets may jitter when paths are switched

▪ Custom solutions are possible (and used)

▪ Infinite ways to solve the problem

TSN toolbox can help

No issue in mixing approaches

Interoperability risk

Reliability considerations required



Renesas.com

Documents

TIME SYNCHRONIZATION AND COMMUNICATION IN … · IEEE 802.1AS-REV EXAMPLE Page 11 Among other improvements, changes were done with respect to reliability of synchronization Redundancy