A Survey on Time-Sensitive Networking Standards and Applications for Intelligent Driving

Abstract

Stimulated by the increase in user demands and the development of intelligent driving, the automotive industry is pursuing high-bandwidth techniques, low-cost network deployment and deterministic data transmission. Time-sensitive networking (TSN) based on Ethernet provides a possible solution to these targets, which is arousing extensive attention from both academia and industry. We review TSN-related academic research papers published by major academic publishers and analyze research trends in TSN. This paper provides an up-to-date comprehensive survey of TSN-related standards, from the perspective of the physical layer, data link layer, network layer and protocol test. Then we classify intelligent driving products with TSN characteristics. With the consideration of more of the latest specified TSN protocols, we further analyze the minimum complete set of specifications and give the corresponding demo setup for the realization of TSN on automobiles. Open issues to be solved and trends of TSN are identified and analyzed, followed by possible solutions. Therefore, this paper can be an investigating basis and reference of TSN, especially for the TSN on automotive applications.

1. Introduction

The structure of traditional automobile network is relatively simple, where a controller connects with devices in its domain and different controllers do not interfere with each other. With the increase in user demands on various functionalities, the number of electrical control units (ECUs) of automobiles has gradually increased. Information exchange between ECUs has become more complicated and requires high bandwidth. In addition, with the popularization of the automatic data acquisition system (ADAS) for intelligent driving, more and more sensors, cameras and entertainment systems are being integrated into automobiles, which place higher performance requirements on the certainty, latency and jitter of automobile networks. Ethernet has a simple connection mechanism and protocol operation, which can provide 10 G, even 100 G, bandwidth for data transmission. Compared with traditional solutions, such as controller area network (CAN) [1], local interconnect network (LIN) [2], media-oriented system transport (MOST) [3] and FlexRay [4], Ethernet is a promising solution to in-vehicle networks and is more likely to be dominant. However, the definition of Ethernet fundamentally lacks attributes to guarantee deterministic, low-latency and jitter data transmission for time-sensitive and critical applications. Thereby, new networking techniques need to be studied to further develop Ethernet for automobile networks. In this context, time-sensitive networking (TSN) is proposed to enable real-time and deterministic transmission for critical traffic based on Ethernet hardware.

The TSN family of standards is a tool set that offers reliability, determinism and time synchronization for safety-critical automotive communications over Ethernet links. The TSN standards leverage the previous work conducted within the IEEE 802.1 Working Group on IEEE audio video bridging (AVB). TSN is a set of specifications standardized by the Institute of Electrical and Electronics Engineers (IEEE) 802.1 work group (WG), the predecessor of which is audio video bridging (AVB) [5]. AVB was firstly specified to support the real-time transmission of audio/video (A/V) traffic, which includes synchronization specification, simple resource reservation and scheduling specifications. As more time-sensitive applications emerge, AVB standards are not only used for A/V transmissions but also to manufacture automation, automotive, mobile communication network front haul, etc. [6,7]. Thus, EEE 802.1 WG renames AVB as TSN to better reflect the expanded scope and issues more specifications to improve the real-time capability and reliability of Ethernet. Nowadays, TSN provides various synchronization, resource reservation, queuing and scheduling, control and configuration, certainty, security and safety mechanisms. Updated versions and new specifications are still being developed. In addition to standards, both industry and academia also pay attention to the study of TSN, which are usually in terms of the following fields. Firstly, the time-synchronization designs are investigated, which make network devices synchronized to a reference clock with the accuracy between 1 µs and 10 ns. Secondly, resource-management schemes are designed, which reserve bandwidth for critical time-sensitive traffic with guaranteed latency. To further provide the bounded latency, some queuing and forwarding schemes are investigated, which give priority for critical traffic, while trying to reduce the side effects on general traffic to coexist with them. Thirdly, centralized, distributed, hybrid configuration models and configuration languages are studied to provide static or dynamic control on the synchronization, resource management and scheduling. Finally, security and certainty guaranteed schemes are studied, such as filtering, redundancy provision, link aggregation, etc.

In this paper, we present all related standards on TSN, which not only include those specified by IEEE 802.1 WG but also those specified by the Internet Engineering Task Force (IETF), IEEE 802.3 WG and OPEN Alliance (OA). In addition, we discuss related products, and analyze the demo setup and promising techniques of TSN used for intelligent driving applications. The rest of the paper is organized as follows. Section 2 is the related work. Section 3 presents published and ongoing standards of TSN, which can be used for autonomous driving. Section 4 introduces vehicle TSN products, such as switch, endpoint and protocol stack. Section 5 gives a demo setup for the realization of TSN on a car. Then, open issues and trends of TSN are analyzed in Section 6. Finally, Section 7 concludes this paper.

Table 1. A comparison of contribution between our survey and relevant surveys.

Year	Ref.	TSN Related Standards				Products	Demo	Open Issues and Trends
		PHY	MAC	Layer 3	Test
2019	[8]		√			√	√
2020	[9]		√					√
2021	[10]		√				√	√
2022	[11]	√	√					√
2023	[12]	√	√				√	√
2023	This paper	√	√	√	√	√	√	√

summarizes the contribution of our work in comparison to previous relevant surveys.

2. Related Works

Recently, some works have reviewed TSN from different perspectives. For example, the authors in [13] surveyed specified TSN in industrial communication and automotive in detail as well as their applicability to various industries. Nasrallah et al. provided an overview of ultra-low latency communication techniques, including TSN and fifth generation (5G) techniques used in various applications [14]. A survey on techniques for the modeling from AVB to TSN and the recent advances in real-time Ethernet design methodologies from AVB to TSN are presented in [10]. In addition, some works reviewed some key specifications of TSN, e.g., [15,16], who introduced some main specifications on the data link layer. The authors in [17] investigated the use of TSN on wireless systems for real-time industrial communication based on next-generation wireless standards, such as wireless TSN techniques, IEEE 802.11 AX and 5G cellular systems. Kang et al. in [18] reviewed the trend towards the standardization of TSN in 5G networks and provided insights into wireless communication technologies for wireless TSN. There are few works that specifically focus on the TSN for automotive networks. Authors in [19] provided a review of several TSN standards in light of possible future use cases in automotive systems using in-vehicle Ethernet networks. The recent survey in [8] focused on hardware/software solutions for intelligent driving systems, which provided an overview of the current technological challenges in on-board and networked automotive systems, including TSN. The author in [20] investigated a partitioning system for TSN to support in-vehicle communications, which, by design, allows to dynamically add new traffic flows without impacting the flows defined by the carmaker at the design time. However, the detailed TSN towards intelligent driving has not been well addressed until now. Although much research work and investigation have been conducted on TSN, detailed applications of TSN in the area of smart driving have not yet been fully explored.

3. TSN Related Standards

Enabling time-sensitive and deterministic vehicle networks is systematic engineering, which refers to multiple layers with mutual cooperation. For applications of local area network (LAN), most specifications focus on the data link layer (Layer 2, mainly standardized by IEEE 802.1 TSN [21] group) based on switched Ethernet. IEEE 802.3 WG pays attention to the corresponding Ethernet physical layer (PHY) technique. IETF deterministic networking (DetNet) WG cooperates with the IEEE 802.1 TSN group, which provides the network layer (Layer 3) solution to deterministic routing. In addition, IETF defines the general architecture for Layers 2 and 3. OA focuses on the test standardization of TSN. There are several differences and similarities between these two standards. The main difference between DetNet and TSN is the layering in the OSI model. DetNet operates on the Layer 3 protocols, whereas TSN is confined to Layer 2. The data plane of these standards is also different. DetNet nodes can connect to other subnetworks, such as the optical transport network (OTN) and MPLS Traffic Engineering. TSN cannot achieve multi-layer systems, while DetNet can. However, TSN and DetNet share the same features, such as time synchronization, frame replication and elimination. We divided this section into the following four subsections based on the TSN standards within different layers. The first is PHY transmission-related standards. The second subsection is the TSN protocol related to the scheduling and configuration of the data link layer. The third subsection is divided into the standards for the DetNet network. This section is the TSN protocol of the third layer standardized by the IETF. The fourth subsection is the vehicle TSN testing standard developed by OA.

3.1. PHY-Related Standards

Automotive TSN networks based on Ethernet PHY usually use a single-pair twisted pair to reduce the cable weight. The transmission rate can support from 10 Mb/s to 10 Gb/s. There are three related specifications as compared in

Table 2. Related PHY specifications.

	Supported Rate	State	Character	Content
IEEE 802.3bw [22]	100 Mb/s	Published	Reduces the number of wires	Provides 100 Mb/s PHY specifications and management parameters for operation on a single balanced twisted-pair copper cable
IEEE P802.3cg [23]	10 Mb/s	Published	Reduces the number of wires	Supports 10 Mb/s single-pair Ethernet operation in automotive environments
IEEE P802.3ch [24]	10.00 Gb/s	Published	Provides asymmetrical data rates	Provides greater than 1 Gb/s PHY specifications and management parameters for media and operating conditions for applications in the automotive environment

.

IEEE 802.3bw [22] is the first automotive Ethernet specification which specifies 100 Mb/s Ethernet (100 BASE-T1) over a single twisted pair for automotive applications. IEEE 802.3bw [22] targets the reduction of the number of wires in wiring harnesses, which in turn reduces the cost and weight of a vehicle. In addition, IEEE 802.3bw provides a homogeneous in-vehicle network architecture with increased data speed for advanced applications, such as ADAS, infotainment (streaming music, video, DVD and BluRay) and the overall electrification of motorized vehicle functions. The transmission distance can reach 15 m for an unshielded twisted pair (up to 40 m for a shielded twisted pair). Although only a single-pair differential twisted pair is used, 100 Mb/s automotive Ethernet can also perform full-duplex communication by using echo cancellation technology.

Targeting the lower cost and higher performance requirement of critical data, two more specifications are designed by IEEE 802.3 WG [25]. IEEE 802.3cg [23] provides 10 Mb/s bandwidth, which further reduces the cost of network deployment by removing the need for switches and sharing the 10 Mb/s Ethernet medium between multiple devices. Compared with the industrial Ethernet, which generally uses multiple pairs of twisted-pair wires with more wire harnesses, and generally uses RJ45 interfaces, IEEE 802.3cg [23] makes automotive Ethernet have no specific connector, which is usually smaller and compact to greatly reduce the weight of the wiring harness in the car. IEEE 802.3ch [24] considers asymmetrical data rates of physical transmission. For example, 10 Gb/s is used for the forward channel (data from camera for video), and 100 Mb/s to 1 Gb/s for the backward channel (data to camera for control).

3.2. MAC Related Standards

Traditional Ethernet technology cannot satisfy the real-time synchronous transmission of data in audio and video networks. Therefore, the IEEE 802.1 working group established the AVB working group in 2005. Based on the existing Ethernet system, a series of new standards provide service quality guarantee for the transmission of audio and video streaming data through clock synchronization, bandwidth guarantee and traffic shaping. These standards are summarized in this subsection.

Table 3. Application of TSN standards to intelligent driving applications.

Standard	Functionalities	Application Fields of Intelligent Driving
IEEE802.1AS [26]/ASrev [27]	Time and Synchronization	Information fusion
IEEE802.1Qbu [28] and IEEE802.3br [29]	Frame preemption	Key information transmission such as braking
IEEE802.1Qav [30]/Qbv [31] Qch [32]/Qcr [33]	Forwarding and queuing	Traffic scheduling for time-sensitive traffic such as video, controlling signal
IEEE802.1Qca [34]/Qat [35]	Resource reservation	Guaranteed transmission for time-sensitive traffic
IEEE802.1Qcc [36]	Network configuration	Configuration for synchronization among devices, scheduling and resource allocation for traffic
IEEE802.1Qci [37]	Inspection and Security	Automotive remote diagnosis, security of driving
IEEE802.1CB [38]	Frame replication and elimination	Providing redundancy information transmission of key information transmission

lists the TSN standard classifications and their applications.

3.2.1. IEEE Std 802.1AS

802.1AS [26] was developed based on the IEEE 1588 [39] precision time protocol (PTP) [40,41], which specifies the protocols, procedures, and managed objects used to ensure that the synchronization requirements are met for time-sensitive applications, such as audio, video, and time-sensitive control in [23]. The standard defines a best master clock algorithm (BMCA) to select the time reference node, and a generalized precision time protocol (gPTP) to synchronize the clock of nodes, providing them the clock value of the reference node, called the grand master (GM):

$$f_s=f_m\frac{t_{01}^{\prime }-t_{01}}{t{}_{00}^{\prime }-t_{00}},$$

(1)

where $t_{01}$ and $t_{01}^{\prime }$ are the time of receiving sync messages at two interval time at the slave port, while $t_{00}$ and $t_{00}^{\prime }$ are the time of sending sync messages at two interval time at the master port. The other stage is that the slave port sends a delay request and the master port responds the delay request with two signaling messages to transmit the receiving time of delay request message and the sending time of the response of delay request, respectively, as shown in Figure 1. In this stage, the slave port can calculate the shift delay of reference time based on

$$T_{trans}=\frac{(t_4-t_1)-(t_3-t_2)}{2},$$

(2)

where $t_1$ and $t_4$ are the time of the sending delay request and receiving delay request response at the slave port, respectively. $t_2$ and $t_3$ are the time of receiving the delay request and sending the delay request response at the master port, respectively. Then, the slave port can adjust its time to the reference time, i.e., synchronization. The actor of ports, i.e., master or slave, can be designated by the controller in advance or selected based on some algorithms, say, the best master clock algorithm (BMCA).

Through periodically sending the above signallings by devices, AS-aware devices can be synchronized. Thus, 802.1AS [26] enables systems to meet the respective jitter, wander, and time-synchronization requirements of time-sensitive applications, including applications that involve multiple streams delivered to multiple end stations. For autonomous driving applications, time synchronization is a preliminary and important aspect. For example, an ADAS decision is usually made based on the fusion-sensing information of different devices, such as radar and camera. These devices need to be synchronized before the data infusion. Thus, manufacturers choose it as the first realized standard of their TSN products.

3.2.2. IEEE Std 802.1CB

For supplying the deterministic network, 802.1CB [38] supplies transmission redundancy via frame replication at the transmitters and elimination at receivers [38]. This standard supports sequence numbering, the replication of each packet in the source end station or network relay system, and the ability to eliminate duplicate packets in the targeted end system or other relay systems based on the sequence number carried in the frame. In this specification, the main defined functions are the stream identification function, sequencing function, individual recovery function, sequence encode/decode function and stream-splitting function. The stream identification function is mainly used for identifying and extracting the stream number of streams. For each stream, the sequence function orders the packet to recover the right order of received packets and discard repetitive packets. The discarding of packets at the receiver is realized by the individual recovery function. In the individual recovery function, transmitted packets are recovered. The sequence encode/decode function is responsible for adding the sequence number (i.e., the number of packets in a stream) or extracting the packet number from the received packets. The stream-splitting function can make multiple copies for a packet of a stream. In the same time, the stream number of packets are encoded to guarantee that copies of packets can be deleted at the receivers.

Through sending packets on different routings, the successful delivery probability can be improved, especially when there are congestion relay nodes on some route. Thus, IEEE 802.1CB [38] is a major specification of TSN contributing to the transmission certainty. For autonomous driving applications, 802.1CB [38] is important to some critical traffic, e.g., braking and direction control. As we all know, the L4 level autonomous driving requires a redundant processor. With IEEE 802.1CB [38], devices can establish the communication mechanism between the main processing system and the redundant processing system. In addition, IEEE 802.1AX provides a way for aggregating the original link and redundant link [42]. Specifically, 802.1AX enables multiple paths to be merged together as a link aggregation group (LAG), and then the end station can treat the LAG as a link to process. As a result, the bad part of the aggregated multiple links does not affect the correct transmission of data, and the successful transmission probability can be improved. However, the provided transmission certainty of these time-sensitive applications is guaranteed by 802.1CB [38] at the cost of an increase in the occupied bandwidth.

3.2.3. IEEE Std 802.1Qci

This specification mainly filters and suppresses ingress flows, which is realized by controlling ingress gates based on an access table [22]. In detail, a stream filter instance table records an ordered list of stream filters, which defines the filtering and policing actions to be applied to the frames of a specific stream. A stream gate is controlled by a state table, which determines whether a frame is allowed to pass through the gate or not by opening the gate or closing the gate.

With the filtering, IEEE 802.1Qci [37] provides for quality of service (QoS) protection by traffic suppression and traffic blocking. For example, the traffic of denial of service (DoS) attacks usually attacks the network via bursty and abundant traffic. The IEEE 802.1Qci [37] filter performs per-flow filtering by matching frames with permitted stream identifications (IDs) and priority levels. Then, the ingress filter can detect whether the stream rate is larger than its reserved bandwidth or not. If the stream rate exceeds the permitted rate, the filter will suppress the rate to the reserved bandwidth by controlling the ingress gate. In addition, the filter can also prevent network attacks (such as address resolution protocol (ARP) attacks) to keep the attacks out by checking the stream IDs. If the stream ID is unrecognized, the stream will be blocked. For automotive applications, IEEE 802.1Qci [37] can be used for the ingress management and providing security.

3.2.4. IEEE Std 802.1Qav, IEEE Std 802.1Qat, IEEE Std 802.1Qbv, IEEE Std 802.1Qch, and IEEE Std 802.1Qbu

These specifications define different time-aware queuing and forwarding protocols to provide low-latency service for time-sensitive applications [43]. IEEE Std 802.1Qav [30] provides a credit-based shaper (CBS) scheduling scheme for packets with different priorities of time-sensitive traffic. In this method, the transmission time is determined by a credit. When the credit value of frame is not negative, the frame can be transmitted from the egress. Otherwise, the frame is not allowed for transmission. The value of the credit depends on the reserved bandwidth of this stream. IEEE Std 802.1Qat [35] provides a method of bandwidth reservation for time-sensitive streams. The amount of reserved bandwidth is calculated based on the priority of the traffic, frame duration, and maximal data size per frame. Through reserving a certain bandwidth on the end-to-end transmission path of a stream, the transmission latency can be guaranteed, which is critical to time-sensitive traffic. Note that only time-sensitive applications are scheduled by CBS in IEEE Std 802.1Qav [30] and Qat [35]. General applications are default scheduled by the strict priority scheme. In the strict priority scheme, streams are forwarded based on their priority, where higher priority is forwarded more preferentially. For IEEE Std 802.1Qbv [31], it schedules both time-sensitive and general applications by activating or deactivating queues at the egress port, where each queue corresponds to a priority and a gate. Through opening or closing a gate for a queue and controlling the duration time of opening a gate, 802.1Qbv [31] controls the available bandwidth of different queues. The scheduling methods of Qav, Qbv and strict priority scheme can be used together or separately.

IEEE 802.1Qch [32] utilizes two queues at the egress port for cyclic queuing and forwarding. Only a queue transmits at any time. While one queue is enabled, all received messages during this time are allocated to the respective other queues (which are disabled). For further providing the transmission certainty of critical traffic, frame preemption can be used by combining it with the above scheduling methods such as those of Qbv and Qch. The frame preemption is standardized by IEEE Std 802.1Qbu [28]. 802.1Qbu [28] enables a time-critical frame to preempt the transmission time of non-time-critical frames to guarantee low latency.

These TSN scheduling methods provide possible solutions to support future autonomous driving, particularly for tight control applications, such as steering, braking, and propulsion over Ethernet. For example, the delivery of chassis control data should be in accordance with strict latency without room for compromise. The automotive industry generally requires that the chassis system delay does not exceed 5 ms, preferably 2.5 ms or 1 ms. This is also the biggest difference between automotive Ethernet and general Ethernet. Some traffic only requires to do their best, such as the entertainment system data, which can be flexibly controlled. These TSN scheduling methods also provide a coexistent way for critical traffic with general traffic. However, the side effects of the scheduling of critical traffic on that of the best-effort traffic should be further investigated and reduced.

3.2.5. IEEE 802.1Qcc

IEEE 802.1Qcc [36] specifies protocols, programs, and managed objects to configure network resources for time-sensitive applications [36]. It provides network configuration from the speaker to the listener to meet the requirements of applications, such as transmission delay. The configuration can be classified as three models, fully distributed, centralized/distributed, and fully centralized, the former two of which are focused. For the fully distributed configuration, the network is configured by individuals in a completely distributed manner, and there is no centralized network configuration entity. The distributed network configuration is performed by using a protocol that propagates TSN user/network configuration information along the active topology of the flow. As the user needs to propagate in each bridge, the resource management of the bridge is effectively performed locally. This local management is limited to the information known to the bridge, and does not necessarily include the information of the entire network. For the centralized/distributed network configuration, it specifies the management object for the bridge configuration through the centralized network configuration (CNC) component. With CNC, some complicated calculation can be performed on it instead of being performed by each end station and bridge. In addition, it is beneficial for using CNC to collect global information of the whole network; as a result, the performance of some TSN standardizations can be improved based on global scheduling, such as Qat, Qav, Qbv, Qbu, etc.

Current automotive TSN products usually use fixed configuration instead of realizing this standard since the topology and transmission environment is simple and more static compared with that of the industry network. For example, automotive application requirements are usually fixed. For a large class of real-time applications, including many cyber–physical systems (CPSs), much of the time-sensitive network traffic from sensors or actuators is predictable and periodic, whether it is 1 cycle/s or 32,000 cycles/s, which makes a fixed schedule feasible. End stations and bridges do not necessary calculate the configuration, such as reserved bandwidth, for each stream frequently. However, Qcc can also be used for automotive networks, e.g., we can use a pre-configuration based on Qcc for traffic scheduling and transmission certainty.

3.3. Layer 3 Related Standards

Layer 3 networking for the QoS guarantee (also called as DetNet networking) is standardized by IETF, which collaborates with TSN WG to provide flows with extremely low packet loss rates, an upper bound of the out-of-order packet delivery and assured maximum end-to-end delivery latency. Three techniques are used for providing these QoS requirements, i.e., resource allocation, service protection and explicit routes [44]. In general, DetNet focuses on extending the TSN data and control plane into the Layer 3 domain, thus expanding the scope of TSN beyond LANs. For automotive applications, this explanation is useful for deterministic vehicle-to-everything (V2X) transmission.

3.3.1. Data Plane Framework

We firstly discuss related specifications on the data plane of Layer 3. The architecture of related data plane functions can be decomposed into two sub-layers, a service sub-layer and a forwarding sub-layer as shown in Figure 2 [45]. The service sub-layer provides service protection, such as packet replication, elimination, and packet ordering. The frame replication and elimination for reliability (FRER) is realized by transmitting packets and their duplicates along different paths and routers, which is similar to that of 802.1CB, while 802.1CB [38] performs frame replication and elimination within a LAN. We note that frame duplication, routing, and elimination are non-trivial tasks that will likely require centralized management. Hence, such protocols can be combined with other standards, e.g., 802.1Qcc [36] and 802.1Qca [34], to ensure seamless redundancy and fast recovery in time-sensitive networks. For the ordering function, it uses the sequence number, which is added to each packet to order the packets. The sequence number can be encoded into existing standardized headers. With the aid of the sequence number, it can enable a range of the packet order by dropping out-of-order packets or reordering some out-of-order packets with a tolerable time delay.

The forwarding sub-layer guarantees the QoS of flow based on existing queuing techniques and traffic engineering methods of internet protocol (IP) networks and multi-protocol label-switching (MPLS) networks. For example, the forwarding sub-layer encodes specific flow attributes (flow identity and sequence number) into packets to provide low loss and assured latency. DetNet routers ensure that DetNet service requirements are met per hop by allocating local resources and mapping the service requirements of each flow to appropriate sub-network mechanisms. The forwarding sub-layer can also use underlaying connectivity, such as TSN, to guarantee the QoS [45]. Some further functions of the forwarding sub-layer are also considered in this specification. Firstly, the resource reservation can be used for a prioritized end-to-end flow. Secondly, the explicit route which pre-configures a path with a certain bandwidth can be used for controlling the latency of a flow. Thirdly, service protection can be studied, which uses multiple packet streams with multiple paths, based on which network coding at different routers can be easily implemented for further flow security and transmission efficiency.

3.3.2. Control Plane and Configuration

Although the current DetNet WG focuses on the data plane, some preliminary concepts and requirements of control plan are briefly described. IETF specifies that the control plane should instantiate flows in a DetNet domain in [45]. For a flow, corresponding control should be instantiated both in terms of the requirements of the service sub-layer and forwarding sub-layer. For the forwarding sublayer, the control plane refers to the determination of explicit routing, resource reservations, queuing, etc. For example, the control plane can advertise link resources, such as capabilities and adjacency to control nodes for resource reservation. For the service sub-layer, the control plane refers to the flow ID, flow aggregation, etc. For example, it can insert flow ID and packet ID by managing the allocation and distribution of the S-Label and F-Label of MPLS. In addition, the control plane can provide flow identification information at each of the nodes along the path. These control plane services can be implemented by using distributed control protocol signaling, centralized network management provisioning mechanisms or hybrid mechanisms. How to perform control is independent of the data plane. The concern of the data plane is only the control results of control plane. However, the implementation method of control will affect the efficiency of the data plane. For example, the centralized control can take advantage of global tracking of resources in the DetNet domain for better overall network resource optimization, while the distributed control is more scalable.

For the configuration, a YANG model is specified, which describes the parameters needed for DetNet flow configuration and flow status reporting [46]. By using this model, the configuration can be acquired by nodes along a flow transmission path. As a result, these nodes can allocate resources, queue and forward packets, and replicate and estimate order packets according to the configuration information. These actions thereby provide a bounded latency and zero congestion loss end-to-end service along the path without any signaling protocols. In detail, this model defines application flow configuration, service sub-layer configuration, and forwarding sub-layer configuration. For the application flow configuration, it maps the application flow (the payload carried over a DetNet service) to the DetNet flow (a sequence of packets with an unique flow identifier, and to which the DetNet service is to be provided) at the ingress node and then maps the DetNet flow to the application flow at the egress node. For the forwarding sub-layer configuration, it is specified to support congestion protection and the explicit route. For the congestion protection, resource reservation, flow shaping, filtering and policing are usually used, which need to know the information of packets. Therefore, the forwarding sub-layer configuration defines some traffic specification attributes, such as the transmission duration of traffic, the maximum number of packets per transmission duration, and the maximum data size of the packet. For the explicit route, the configuration depends on the employed routing schemes. With a designated routing scheme, the configuration node can then calculate the delivery path of flow. For service sub-layer configuration, the model configures the flow identification and service function indication, which are used for identifying a flow and a service function invoked at a DetNet node, respectively.

3.3.3. IP over TSN

To enable Layer 3 to cooperate with TSN, IETF specifies related works on IP over TSN, which describes how IP is used by DetNet nodes, i.e., hosts and routers, to identify DetNet flows and provide a DetNet service [47]. From a data plane perspective, DetNet IP only supports the forwarding layer, which is used for providing congestion protection, such as low loss, assured latency and limited out-of-order delivery. The service protection of service sub-layer, such as packet replication and elimination, can be provided by technologies such as MPLS and IEEE 802.1 TSN [21]. To enable IP to identify deterministic flows and provide a deterministic service based on an IP data plane, existing IP and higher-layer protocol header information is used without DetNet-specific encapsulation. Figure 3 illustrates such a scenario, where two IP nodes are interconnected by a TSN sub-network [48].

As shown in Figure 3, the TSN sub-network can be seen as a hop of the end-to-end path from the IP perspective. In order to use a TSN sub-network between IP nodes, two problems should be solved. Firstly, the forwarding path of packets in the sub-network should be known. Secondly, flow-related parameters or requirements should be converted to those of the packet sequence in the sub-network. For the first problem, it can be solved by mapping an ingress unicast IP flow to a specific Layer 2 multicast destination media access control (MAC) address and a virtual local area network (VLAN). Then the packet can be forwarded in a TSN sub-network. At the other end of the TSN sub-network, the destination address is converted to an IP address to make the packet transmit through a LAN. One method of mapping between IP flow identifiers and TSN stream identifiers is provided explicitly by configuration. The other method is performed by a TSN-aware IP node via information provided for configuration of the TSN stream identification functions (e.g., IP stream identification, mask-and-match stream identification and active stream identification function provided in 802.1CB [38] and 802.1CBdb [49].

For the second problem, Ethernet encapsulation is performed to encode flow-related parameters and requirements. Then, the TSN node can obtain the service requirements, such as successful transmission probability by decoding the encapsulation. To guarantee service requirements, TSN methods are used, such as FRER provided in 802.1CB [38]. In addition, centralized or distributed resource allocation and the scheduling method can be used from a general perspective by regarding a TSN sub-network as an IP node in the IP networks.

3.3.4. MLSP over TSN

When integrating TSN with MPLS, a TSN sub-network can also be seen as a single-hop connection between MPLS nodes. At the current state, interworking across the DetNet MPLS network and the TSN network is not available. Similar to IP over TSN, the TSN edge port converts an ingress unicast MPLS flow to use a specific Layer 2 multicast destination MAC address and a VLAN, to direct the packet through a specific path inside the bridged network. A similar interworking function pair at the other end of the TSN sub-network will restore the packet to its original Layer 2 destination MAC address and VLAN [48]. In detail, the mapping between a MPLS flow and a TSN stream can be operated at the frame level via passive or active stream identification functions. In the passive stream identification function, the MPLS label of MPLS flow is cached for the mapping. For example, IEEE P 802.1CBdb defines a mask-and-match stream identification function that can be used as a passive function for MPLS flows. In the active stream identification function, the Ethernet header is modified according to the ID of the mapped TSN stream. For example, IEEE 802.1CB [38] defines an active destination MAC and VLAN stream identification function, which can replace some Ethernet header fields, i.e., the destination MAC address, the VLAN ID and priority parameters with alternate values.

IETF standardization focuses on the TSN-aware MPLS node and splits the TSN-aware MPLS node into a TSN-unaware talker/listener and a TSN relay. Before the transmission and reception of a stream to/from a TSN sub-network, TSN subnetwork-specific Ethernet encapsulation should be inserted or removed for a MPLS flow, which is usually performed by an edge node located at the boundary of a domain. These MPLS edge nodes not only perform transformation between the MPLS flow and TSN flow but also are service sub-layer aware. Flow requirements within the TSN sub-network can be guaranteed by Layer 2 time-sensitive techniques. Outside the TSN sub-network, MPLS nodes can also use PRER to enhance the reliability of delivery.

3.4. Test Standards

To evaluate the effects of TSN on time-sensitive applications and general traffic, test specifications are gradually worked out. The main contributor is OA, which was jointly established by related companies such as NXP, Broadcom and BMW in 2011 and currently has more than 340 members. To apply Ethernet-based communications and TSN to automotive networks, OA formulates and unifies the physical layer, protocol consistency and interoperability specifications of IEEE 100 base-t1, 1000 base-t1 and 1000 base-rh communication methods. OA presents some specifications on the tests of the wiring harness, switch, ECU and other functional requirements, e.g., ECU-level physical layer, data link layer, TCP/IP protocol layer, SOME/IP test specifications formulated by the technology committee (TC) 8, and the automotive wiring harness and connector test specifications formulated by TC 2, and interoperability, compliance, and electro-magnetic compatibility (EMC) requirements and test methods for 10 BASE-T1 PHYs standardized by TC 14.

Most of the 14 TCs of OA focus on the PHY layer, protocol consistency and interoperability, which are the basis of TSN implementation. The TC focusing on the TSN protocol test itself is TC 11, which creates specification and qualification requirements for Ethernet switches. In detail, TC 11 defines functional features for switch semiconductors (standalone or built-in), and gives the interfacing, configuration diagnostics and monitoring of switches, which can be used for TSN test. In addition, TC 11 specifies tests on TSN requirements and characteristics, such as QoS requirements, queuing, time stamping, policing, and filtering [50]. In TC 11 [50], the requirements and test points of switches are specified. For example, it indicates that the Ethernet switch shall support at least eight different levels of priorities according to IEEE 802.1Q and provide a queue for each priority on each egress port to support different QoSs of TSN. The Ethernet switch can overwrite the priority of a frame at an ingress port independent of the incoming priority (i.e., support global priority overwrite). Incoming priorities shall be freely mapped to internal queues by the ingress filter. Frames of internal queues shall be freely mapped to priorities according to IEEE 802.1Q [43] on the egress port. For each queue at the egress port, it has a shaper to schedule frames. The shaper supports strict priority scheduling and the CBS algorithm according to IEEE 802.1Qav [30]. And each queue can deactivate each shaper individually to cancel TSN scheduling. For time synchronization, TC 11 specifies that the Ethernet switch should support both the PTP 1588 protocol and IEEE 802.1AS [26] protocol. In addition, each port should synchronize with each other. For the diagnostics and robustness, the Ethernet switch shall provide at least the following counters individually for each port: number of received frames, number of received bytes, number of dropped frames after reception, number of sent frames, number of unsuccessful sent frames, number of sent bytes, and maximum fill level of the queues since clearing the counter.

In [50], TC 11 also provides a collection of all test cases which are recommended to be considered for automotive use cases and should be referred by car manufacturers within their quality-control processes. In detail, it presents the test procedures of time synchronization based on TSN, which checks the 1-step frame forwarding mechanism, including the correct implementation of residence time measurement. The test station sends sync frames to the PTP slave port and receives frames on all PTP master ports of the device under test (DUT). The corresponding time stamps of the test station are recorded. The correction time of the sync message is checked if the value correlates to the timestamp measurements of the test station. In addition, it checks whether the switch supports priority-based QoS or not by using all eight possible values. The strict priority algorithm is utilized as a forwarding selection mechanism in order to verify that forwarding is based on priorities.

4. TSN-Related Products

Early TSN products were generally used for industrial automation with the realization of main protocols, such as EEE 802.1AS [26], IEEE 802.1Qav [30], and IEEE 802.1Qat [35]. With the development of TSN and autonomous driving, some TSN products for automotive are designed. Active manufacturers in this area mainly include TTTech, Microchip, NXP, Excelfore, Broadcom, Marvell’s, Spirent, etc. In this section, we briefly review some typical TSN products for intelligent driving during recent years.

In terms of TSN switch chip, a NXP product, NXP sja1110, is the first automotive Ethernet switch, which was designed to solve the huge challenges faced by current in-vehicle networks, including scalability, reliability, security, and high-speed traffic engineering. This switch complies with the AVB/TSN synchronization standard. In addition, NXP designed the SJA1105T chip, which is a core of multi-functional product. This switch chip supports a network with standard Ethernet, which not only supports best-effort business but also QoS-required traffic by using TSN for clock synchronization and time-aware shaping. The Microchip Corporation designed a series of Ethernet switches, such as KSZ8565, KSZ8765 and KSZ8842, which support TSN characters, including IEEE 1588 v2 PTP. Broadcom BCM8956X series devices are Broadcom’s fifth-generation fully integrated L2+ multilayer switch solution, which supports AVB protocol stack (IEEE 802.1AS [26] time synchronization and IEEE 802.1Qat [35]). Except for the realization of the basic specifications of AVB, Marvell developed a series of products with more TSN specifications. For example, the switches 88Q5072 and 88Q6113 of Marvell addeds TSN features to achieve the filtering and control of data streams (IEEE 802.1Qci [37]) and frame preemption (IEEE 802.1Qbu [28]). The integrated L3 hardware accelerator allows a gigabit routing throughput of up to 10 Gbps to be achieved without internal processor intervention. To promote big data transmission in the vehicle network, these devices provide efficient sleep/wake functions that support the TC 10 standard, reducing the overall power consumption. Marvell 88Q5050 is an eight-port, high-security automotive gigabit Ethernet switching chip, which has advanced security features to prevent cyber threats, such as DoS attacks. The eight-port Ethernet switch chip has four fixed IEEE 100 BASET1 [22] ports and four configurable ports. The switch chip provides local and remote management functions, and users can easily access and configure the device.

In terms of the TSN protocol stack, Excelfore eAVB/TSN now runs in cameras, video displays, head units and ECUs from numerous vendors. The Excelfore eAVB/TSN has already been ported to automotive-grade operating systems, including Linux, Mentor automotive open system architecture (AUTOSAR) and Green Hills Software INTEGRITY [51]. The Excelfore protocol stacks integrated and optimized for use with the safe and secure INTEGRITY RTOS from Green Hills Software [51], including support for Ethernet AVB/TSN Talker/Listener, DoIP, SOME/IP, and RTP/RTCP (including IEEE 1733) and 802.1AS [26] slave/bridging.

In terms of TSN testing, TTTech designed a combination switch ECU called DESwitch Hermes 3/1 BRR, which is used for evaluating a variety of communication standards, including AVB, TSN and time-triggered Ethernet (SAE AS6802). With these technologies, users can evaluate the convergence of Ethernet control traffic, including security applications and the vehicle backbone architecture. Polelink developed a TSN test tool for automotive Ethernet called the TSN box. This TSN box is a network interface and gateway for TSN network. It was developed based on field programmable gate array (FPGA) technology to serve as a data collection medium for TSN tools, which supports nanosecond timestamps for time synchronization among multiple TSN boxes.

In addition, the TSN box provides rich functional support for AVB and TSN protocols commonly used in automotive Ethernet architectures, which can be used for exploring PTPv2, 802.1ASrev [27] and different TSN shaping algorithms, such as CBS, time-sensitive or asynchronous shaping. Xinertai launched an automotive Ethernet test program based on the proprietary BigTao hardware test platform. Cooperating with Xinerta’s software Renix [52], the Ethernet test program can realize Layer 2–7 traffic test and protocol simulation for automotive Ethernet, support 100/1000 Base-T1 port connectivity test, RFC2889/RFC2544/RFC3918 standard test suite, routing and switching protocol testing, AVB/TSN protocol testing, distributed denial-of-service (DDoS) attack testing, long-term (such as $10*24$ h) stability and streaming testing, etc. Spirent issued the AUTOSAR conformance test suite pack, which provides different protocol conformance test suites according to the OA test specification. Through this test suite, automotive Ethernet tests can be run on Spirent C1 and C50 devices, which supports testing on clock synchronization and 802.1 Qav [30] scheduling of TSN.

For the vehicle Ethernet PHY chip, it must firstly meet the IEEE 802.3bw or IEEE 802.3bp protocol, and then must pass the AEC-Q 100 standard. The existing semiconductor manufacturers that have launched automotive Ethernet PHY chips include BCM 89610, BCM 89611, BCM 8988X, BCM 89810, BCM 89811 and BCM 89820 of Broadcom, AR 8031 of Artheros, TJA 1100, TJA 1101 and TJA 1102 of NXP. For example, NXP TJA 1101 is based on the IEEE 100 BASE-T1 standard, with the single-port Ethernet PHY transceiver. NXP TJA 1101 meets the needs of automotive applications and supports 100 Mb/s transmission, and its receiving capacity is over 15 m of the unshielded twisted pair. TJA 1100 can achieve the lowest system cost, and meet the strict restrictions on area and heat dissipation of the sensors of the new generation of ECU and ADAS. It complies with AEC-Q 100 level 1, and the original design intention has the smallest package size, the lowest external component overhead and low power consumption.

5. Demo Setup of TSN

To realize basic functions of TSN and provide a deterministic network for autonomous driving, the least complete set of standards to be realized should be considered. The complete set of most TSN products is usually constructed by standards of AVB, i.e., 802.1AS [26], 802.1Qav [30], and 802.1Qat [35], which are mainly used for A/V streams. Here, we further consider some recent TSN specifications for the basic set. Before studying the least complete set, we firstly present the traffic classes and requirements of vehicular applications, which are shown in

Table 4. Traffic classes and requirements of vehicular applications.

Traffic class	Application Example	Character	Requirement
Safety control	Braking, power train data	Event-driven traffic, aperiodic burst	Real-time constraints, guaranteed delivery, latency < 1 ms
Safety media	ADAS fusion data, data of sensors	Periodic traffic	Real-time constraints, guaranteed delivery, latency < 10 ms
Network control	Dynamic Qcc comment, signaling of synchronization	Periodic traffic	Guaranteed delivery, high-priority, bounded latency
Inter-vehicle control	Event or alarm of V2I, V2V and V2N	Event-driven traffic, aperiodic burst	Guaranteed delivery, medium-priority, bounded latency
Safety-irrelevantcontrol	Control of light entertainment system	Event-drive traffic, aperiodic burst	Medium priority, latency < 50 ms
Safety-irrelevant media	Entertainment system	Periodic traffic	Medium-priority, latency < 300 ms
Best effort	Update data record data	Periodic traffic, event-driven traffic	Low-priority, no guarantees, performance is statistical

.

Safety-relevant devices, such as multiple kinds of sensors, need synchronization with each other to infuse them. In addition, synchronization is the preliminary step of many scheduling and management schemes. Thus, the 802.1AS [26] specification needs to be realized first. To provide deterministic transmission for critical traffic, such as the control comment, bandwidth reservation is needed. On the other hand, the traffic class is finite and fixed, compared with that of industry. Thus, a preferred bandwidth reservation method is pre-allocating the bandwidth for different application traffic instead of 802.1Qat [35] to reduce the signaling overhead and related information storage brought by the stream register of 802.1Qat. Correspondingly, a scheduling method is needed for bridges and end stations to queue and forward frames with different classes. 802.1Qav [30] is preferred for data transmission within a domain. For data transmission among multiple domains, 802.1Qbv [31] is an alternative method. In addition, 802.1CB can provide a baseline for giving redundant paths and supporting robustness. 802.1Qcc [36] can provide corresponding configuration for these protocols. Other specifications can be further realized for a more robust and deterministic network. The basic TSN protocol stack model of the switch of in-vehicle networks is shown in Figure 4, where blue blocks construct a minimum complete set of standards to be realized for a TSN-supported bridge of automotive networks. The end station can be seen as a bridge with a port.

For the TSN demo set up, the above functions are expected to be examined and displayed. Here, we give a demo setup for some typical functions, such as that of 802.1AS, 802.1Qbv, and 802.1CB, which is shown in Figure 5.

As shown in this figure, synchronization is examined by observing whether two A/V traffic generators are synchronized or not. They can be two AVB cameras recording the same view. In Display 1, it shows the views of two cameras, respectively. When they are synchronized, the displayed views of the two cameras are the same. This is an intuitive show. More accurately, it can be tested by using time-record software. Two cameras photograph the software with the time display and transmit them to DCU 1. Then, we can see whether the transmitted pictures with time are the same or not. 802.1Qbv [31] is checked by using three traffic generators, i.e., A/V traffic, best-effort traffic and control traffic. With the interfering traffic (BE traffic and A/V traffic), the delay and jitter performance of control traffic can be observed, which should not be affected by the interfering traffic and have guaranteed latency and low jitter based on Qbv. For the 802.1CB demo, redundant routing is used for critical traffic. The robustness of the traffic transmission can be observed by allowing routing congestion with abundant traffic.

We simulated the time-synchronization effect of 802.1AS [26] and the traffic-scheduling performance of 802.1Qbv [31]. The simulation environment developed here is based on FPGA, and the PHY chip is Realtek RTL8201CP, which has a clock frequency of 25 MHz at 100 Mbps, i.e., the clock accuracy is 40 ns. The corresponding waveforms were obtained and analyzed experimentally.

As shown in Figure 6, the vertical coordinate time offset represents the time deviation between nodes measured at each time in $\mathsf{\mu }$s, and the horizontal coordinate time represents the time-synchronization interval, which is 1 s. After a short period of jitter at the beginning of the time synchronization, the time deviation between nodes tends to converge; the final value of this time-synchronous convergence converges to 14.5 $\mathsf{\mu }$s. The simulation experimental results show the effectiveness of the time synchronization, which shows that AS is feasible in the demo setup.

In Figure 7, the vertical axis end-to-end latency represents the total time it takes for a data packet to be sent from the sender to the receiver, measured in microseconds ($\mathsf{\mu }$s). The horizontal coordinate sampling times indicates the number of times the data are sampled at the same time interval. The impact of enabling the time-synchronization feature on the traffic-scheduling performance of the TAS algorithm is verified by comparing with and without enabling time synchronization, and the results show that the end-to-end delay of traffic is reduced by an average of 80 $\mathsf{\mu }$s when time synchronization is enabled. In addition, simulation experiments show that Qbv achieves end-to-end low latency performance under time synchronization, which also validates the effectiveness and feasibility of the demo setup.

6. Open Issues and Trends

In general, TSN is an emerging technology, for which many problems need to be solved. In this section, several promising research directions with respect to TSN are discussed as follows. This section discusses the challenges and open issues in time-sensitive networking (TSN), first highlighting the need for a grand master and a comprehensive resource allocation and scheduling plan and discussing the advantages and disadvantages of centralized and distributed scheduling methods, as well as highlighting the importance of an efficient and flexible network solution to support real-time applications in the automotive industry.

6.1. Synchronization

An open aspect of time synchronization is the efficient choice of the grand master (GM). GM provides the reference time for other devices of the network. However, the standardized BMCA needs frequent information exchange and comparison to select the best clock among all devices and ports. This will bring much overhead cost and it is against the reduction in latency. Specially, the main current forwarding and queuing schemes are dependent on the synchronization time. Therefore, this GM selection ultimately affects the efficiency and results of scheduling. For the automotive network, it usually has simple and static topology with known clock accuracy of its devices. It is an alternative method to pre-designate a GM. However, the damage of GM under this situation will lead to non-synchronization and failure to implement TSN. Preparing some alternative GMs may be a potential approach to solve this problem. How to specify a GM and determine the number of alternative GMs need to be further studied.

6.2. Resource Management

The main specified bandwidth reservation protocol is provided in 802.1Qat [35], which gives a decentralized stream registration and resource reservation procedure. However, any new arrival, leaving, or new requirements of streams will lead to signaling exchanges along the transmission path of the streams. This overhead becomes significant with the increases in hops. Thus, it cannot provide strict transmission latency for critical traffic. To overcome this shortage, 802.1Qcc [36] provides a way to control the network globally. But it is still unclear as to how to appropriately allocate resources to all traffic with different priorities in the network from a global view instead of only allocating resource to critical traffic. A comprehensive resource allocation plan is conducive to the efficient use of all resources and minimizing the loss of non-critical services. In addition, although 802.1Qcc [36] provides a possibility of allocating resources with the consideration of scheduling, a joint resource allocation and scheduling approach needs to be further studied. Without considering scheduling, the resource allocation scheme cannot be efficiently realized by queuing and forwarding. Last but not the least, efficient resource allocation should consider the link state and the traffic character. Static resource allocation for different traffic classes with fixed allocated bandwidth ratios not only induces resource waste but also is harmful for guaranteeing the transmission latency of critical traffic, especially for bursty data or busy networks.

6.3. Scheduling

Scheduling methods are the core of current TSN specifications and studies. With scheduling, it not only eases bursty traffic and reduces the network congestion but also queues and forwards different traffic reasonably according to their importance. Related scheduling methods can be divided as centralized and distributed. Distributed scheduling will not strictly schedule traffic by obeying the allocated bandwidth. Therefore, its scheduling only obeys the reserved bandwidth, softly leading to latency exceedance, especially for a topology with multi-hops. In addition, information exchange also brings abundant overhead for dynamic topology or long path. For automotive applications, some unexpected traffic, such as the braking command, requires urgent transmission, which also brings the program of resource allocation and scheduling. A distributed scheduling is not efficient in such cases. In contrast, centralized scheduling can schedule traffic without frequent information exchange and schedule all nodes along the path simultaneously. However, the selection, deployment, and robustness of the central node will affect the scheduling results significantly. How to balance the advantages of both types of scheduling methods is an open issue. In addition, the queuing of different traffic are separately which may use different scheduling schemes. A unified scheduling is better for improving the scheduling efficiency. For example, we study how to unify the Qav, Qbv, Qch, strict priority and asynchronous schemes used in the egress port. Thirdly, different types of traffic have different latency requirements. Although the TAS is a novel feature for the ultra-low-latency transmission of time-critical traffic, it has high implementation complexity and additional overhead due to the GCL schedule generation/deployment and time synchronization. Moreover, it is unsuitable for aperiodic traffic flows. Different scheduling methods should be used for different types of traffic. For example, for periodic traffic, more static scheduling, such as time-triggered scheduling, can be used. For sporadic periodic traffic, how to efficiently schedule is a study direction. Lastly, the current time-triggered scheduling can be preempted by time-sensitive applications designed in the specification. However, the efficiency of this preemption should be investigated especially for the busy network scenario. In the resource allocation method, non-critical traffic is originally allocated less bandwidth. The preemption of the guarded bandwidth by critical traffic may be trivial. Hence, an important future work direction is to develop traffic transmission schedules with reduced numbers of guard band occurrences in order to prevent wasted bandwidth and to keep latencies low. Scheduling based on traffic predication and being more flexible may be expected.

6.4. Configuration

The configuration models can be divided into centralized and distributed groups. The hybrid configuration which also supports existing distributed resource allocation methods, such as the stream registration of 802.1Qat as a research direction. In the hybrid configuration, the centralized node can provide configuration in time and optimize performance from a global view, while distributed nodes can cooperate the configuration in case the centralized node is out of work. Even so, the configuration cost and time still need to be studied for reduction. This is because that higher configuration cost will occupy higher limited bandwidth, and longer configuration time induces longer time delay for critical traffic. Therefore, the communication and computation requirements should be considered for the configuration node design and selection. In the future zone architecture of the car, the domain controller may be a candidate for the configuration node. Traditionally, the in-vehicle network is configured statically at the designed time to guarantee the quality of service (QoS) requirements of the applications. Due to the static network configuration, it is normally difficult to introduce new applications during the lifetime of the vehicle. The need for an IVN supporting dynamic traffic will increase as the number of features and functionalities requiring dynamic traffic handling in the vehicle increases. Some of the dynamic applications are vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) and vehicle-to-network (V2N), adaptive cruise control, truck trailer systems and over-the-air (OTA) software updates [53]. Therefore, automotive applications require dynamic reconfiguration facilities to meet the requirements of new evolving features. Several studies suggest that complementing TSN with a networking concept, such as software-defined networks (SDNs) is a beneficial configuration solution [54,55,56]. With additional protocols (e.g., Netconf and Openflow), SDN allows for the instant configuration of routes and transport schedules based on a central control plane. It also allows splitting up flows for transmission on multiple paths for load balancing, using the available bandwidth more efficiently, and making network-wide configurations, such as time synchronization.

6.5. Robust and Certainty

It is clear that there is a trade-off between transmission certainty and resource cost. For example, 802.1CB [38] uses redundant transmission to improve the successful transmission probability of critical traffic. The obtained end-to-end topologyis helpful for the relay to determine the redundant paths. This topology cannot be obtained by each relay of 802.1CB. Although 802.1Qca can pre-define redundant paths for each stream, it cannot intelligently determine the redundant paths based on the available bandwidth and the requirements of other applications. This will lead to a lack of enough conditions for executing redundant transmission. This problem is especially serious for distributed redundancy schemes, such as 802.1CB due to the lack of topology information. On some congestion paths, the replication of packets will bring more burden to some links, leading to uncertainty and high latency. Although some alternative links may successfully transmit packets of stream, packet transmission on the congestion link only aggregates this condition without improving the robustness.

6.6. Ongoing TSN Standards

There is a special standard draft, IEEE P802.1DG [57], which describes the TSN profile for automotive Ethernet communications. This standard specifies profiles for secure, highly reliable, deterministic latency, automotive in-vehicle bridged IEEE 802.3 Ethernet networks based on IEEE 802.1 TSN standards and IEEE 802.1 security standards [21]. This standard provides profiles for designers and implementers of deterministic IEEE 802.3 Ethernet networks [53] that support the entire range of automobile applications including those requiring security, high availability and reliability, maintainability, and bounded latency.

In addition, scheduling independent of synchronization is also an open issue. Current standardized scheduling methods need synchronization among network nodes, while the synchronization affects the scheduling performance. IEEE P802.1Qcr [33] is a specification draft on asynchronous traffic shaping (ATS), which operates asynchronously, i.e., bridges and end stations need not be synchronized in time. The ATS is originated from the urgency-based scheduler (UBS) [58], which implements a per-flow interleaved regulator [59] based on rate-controlled service disciplines, providing deterministic latency with low implementation complexity. In the provided asynchronous traffic shaping method, it prioritizes urgent traffic over relaxed traffic. Thus, ATS can utilize the bandwidth efficiently, even when operating under high link utilization with mixed traffic loads, i.e., both periodic and sporadic traffic. By using these queuing and forwarding schemes, not only the latency of time-sensitive traffic can be reduced and guaranteed but also the stream arrival can be smoothed, as a result of which the network congestion can be reduced. As future research direction, one relevant one is the IEEE 802.1Qcr-2020 [33] standard, which is very promising, as it offers bounded latency asynchronous shaping with robustness properties (e.g., integrated policing) and permits compositional timing analysis.

This draft also specifies an information model for the capabilities of asynchronous traffic shaping. It further specifies a YANG data model and management information base (MIB) modules to support configuration and status reporting. Additionally, it provides an informative framework for the delay analysis of the worst case in static networks with static configurations. It also addresses errors and omissions in the description of the existing functionality.

IEEE P802.1Qdd [60] specifies protocols, procedures, and managed objects for a resource allocation protocol (RAP) that uses the link-local registration protocol (LRP). It supports and provides backwards compatibility with the stream reservation and QoS capabilities, and controls and protocols specified in IEEE Std 802.1Q [43]. RAP provides support for accurate latency calculation and reporting, which can use redundant paths established by other protocols and is not limited to bridged networks.

IEEE P802.1Qdj [61] provides configuration enhancements for TSN. In this specification, it defines procedures, interfaces, and managed objects to enhance the three models of TSN configuration. It specifies enhancements to the user/network interface (UNI) to include new capabilities to support bridges and end stations in order to extend the configuration capability. It preserves the existing separation between configuration models and protocol specifications.

IEEE P802.1ASdm [62] amends 802.1AS to specify the hot standby protocol, process and management objects that do not use the BMCA for the time-aware system. P802.1ASdm includes the function of converting the synchronization time of the two general precision time protocol (gPTP) domains into a synchronization time for the application programs, the function of directing the synchronization time of one gPTP domain to another gPTP domain and a mechanism to determine whether the gPTP domain has sufficient quality for hot standby.

For the transmission redundancy, IEEE P802.1CBcv amends IEEE Std 802.1CB [38], which provides FRER extended stream identification functions, including process and management objects for adding new stream recognition functions.

6.7. TSN Based on Wireless Channel

Except the research points specified in published and ongoing standards, TSN based on wireless channel is attracting more attention, especially for Industry 4.0 since wireless connectivity can enable flexibility, scalability, and lower costs in next-generation factories. The 802.1AS [26] time synchronization based on wireless channel has been designed, while more designs are needed for the accuracy and timeliness of the synchronization. Currently, because a 5GS does not provide time synchronization between the user equipment (UE), radio access network (RAN), and user plane function (UPF), a new time-synchronization mechanism is required. In addition, a new buffering and scheduling mechanism is required for processing TSN traffic because guaranteeing a deterministic delay as well as a low delay is necessary. In addition, different from wire communications, the broadcast character of wireless communications will bring interference among nodes. Therefore, the reduction in robustness should be considered. Correspondingly, resource management, channel access, scheduling, configuration and security need to be future investigated. The WLAN can be used for TSN besides 5GS. However, because WLAN cannot detect collisions, it uses a random back-off counter to avoid collisions. The random back-off mechanism increases the transmission delay and causes high jitter. Thus, maintaining the delay within a particular range is challenging.

For automotive applications, since Ethernet is the most promising in-vehicle backbone network technology, the TSN based on wireless communication may be future work. For the deterministic and low-latency transmission of inter-vehicle networks, TSN investigation is needed for wireless and 5G techniques.

6.8. TSN Products

Although many TSN products, from the physical layer to the application layer, were designed, most of them are used for the deterministic transmission of Industry 4.0. For automotive networks, some preliminary products were developed, most of which realized standards of AVB, such as 802.1AS, 802.1Qav and 802.1Qat. For TSN, some products realized the protocol stack for testing. More products with integrated TSN characters are needed, which can be used for automobiles to guarantee deterministic transmission for the critical traffic of intelligent driving.

7. Conclusions

In this paper, we presented an in-depth survey of time-sensitive networking (TSN) for intelligent driving. We introduced TSN-related standards specified by the Institute of Electrical and Electronics Engineers (IEEE) 802.3 work group (WG), IEEE 802.1 WG, Internet Engineering Task Force (IETF) and OPEN Alliance (OA) from the physical layer to the network layer to enable Ethernet to provide deterministic, low-latency and high bandwidth data transmission for emerging applications brought by intelligent driving. Furthermore, we revealed corresponding automotive products based on these TSN specifications. In addition, we analyzed a minimum set of specifications that should be considered to realize TSN functions for automotive applications, based on which we presented a demo setup. Based on our survey, we concluded the existing techniques of TSN, and identified corresponding solutions and proposed potential solutions to address these issues. We also gave some promising techniques and ongoing standards of TSN, including new designs of synchronization, configuration, robustness, resource allocation and the TSN based on the wireless channel, followed by a discussion of its feasibility for automotive applications. With the aid of this survey, researchers can obtain a quick understanding of the contents, progress and challenges of TSN on automotive networks. Furthermore, developers of TSN can draw lessons from solutions provided in this paper both in term of theory and practice.