Seize the Ethernet TSN Opportunity
By Comcores
Accelerate time-to-market with reliable Ethernet TSN solutions using Comcores IP
Ever since its introduction in 1973, the Ethernet protocol has expanded and evolved to support every conceivable connectivity application. Ethernet is designed to be a non-deterministic packet-based network, but this also means that Ethernet cannot satisfy the needs of applications that require time-critical, fail-safe operation. These short-comings are targeted by the Ethernet Time-Sensitive Networking (TSN) group of standards.
Time-sensitive applications require strict control of latency and jitter, which is not possible with conventional Ethernet. Ethernet TSN provides additional features and mechanism that address time synchronization, latency and reliability, which enables applications with time-sensitive, fail-safe requirements to use the same infrastructure as other Ethernet-based services.
Comcores is a pioneer in Ethernet TSN offering a comprehensive portfolio of Intellectual Property (IP) components that can be used by equipment manufacturers to accelerate development of Ethernet TSN end-points, switches and gateways. With a a dedicated program for continuous development of Ethernet TSN IP solutions, Comcore ensures supports for the latest Ethernet TSN standards, profiles and feature extensions.
Ethernet TSN Advanced Switch 10M/100M/1G/10G/25G for 5G/ORAN and other applications Ethernet TSN MAC 10G/25G | Related |
What is Ethernet TSN?
Ethernet TSN is not a single standard, but a group of extensions to the existing Ethernet IEEE 802.3 standard that address time-sensitive and fail-safe applications. The work was started in 2012 with the formation of the IEEE 802.1 TSN task force, who were previously engaged in adapting Ethernet for audio/video bridging applications. The task force is focused on extending existing IEEE 802.1Q standards to accommodate the needs of time-sensitive networking as well as defining TSN profiles for mobile fronthaul, service provider network sharing, industrial automation and invehicle communication.
Figure 1: Ethernet TSN Components
Each of the extensions to the existing standards is designed to address a specific issue with conventional Ethernet. Figure 1 shows the four main components of Ethernet TSN addressing Ethernet challenges with respect to time synchronization, reliability, latency and resource management. In combination, they enable Ethernet TSN to be a viable solution for applications that previously could not be addressed with Ethernet.
The following sections will take a look at the major Ethernet performance issues and how the extensions address those shortcomings. This will be followed by an overview of the applications of TSN for 5G, industrial automation, automotive invehicle communications and avionics. The paper will conclude with a description of Ethernet TSN solutions offered by Comcores.
Figure 2: Generalized Precision Time Protocol
Time synchronization
The first challenge to be addressed is that Ethernet is not a time synchronized network. The answer to this is Precision Time Protocol (PTP) defined in IEEE 1588-2008 as PTP version 2.0 and recently updated with a backward compatible version 2.1 in IEEE 1588-2019. In Ethernet TSN, an adaptation of PTP called Generalized PTP (gPTP) is used, which is defined in standard IEEE 802.1AS. Both use a hierarchical master-slave architecture to distribute clock synchronization and correction information in the physical network.
PTP is based on a network whose devices synchronize their time references using synchronization messages sent over the Ethernet Local Area Network (LAN). The connected clocks communicate and elect a grandmaster clock to be the ultimate reference and synchronize their time using messages from the grandmaster.
Figure 2 shows an Ethernet network supporting gPTP. PTP v2 introduced the concept of a “transparent clock”, which enables devices relaying PTP messages to support their own clock and send follow-up messages that adjust for the delay through the device. This is called two-step synchronization. gPTP has taken this concept further and required all network nodes to support transparent clocks. In gPTP, the grandmaster first sends a synchronization message and then a follow-up message indicating the precise time the synchronization message was sent. While PTP v2 supports one-step synchronization where a follow-up message is not required, gPTP requires two-step synchronization.
On each device, the receiving port is considered a clock slave port while all other egress ports then act as clock masters to other nodes in the network. Each master port propagates the synchronization message and also sends a followup message indicating the path delay from the grandmaster to the node plus the delay through the bridge. With the sync message and the delay information, each node can compensate and correct their clocks ensuring reliable time synchronization.
Latency
One of the main challenges when using conventional Ethernet for time-sensitive applications is latency. The absolute latency is an issue, but the variability and unpredictability of latency is of much more concern. If the latency and jitter in a network could be held within limits, or bounded, then it could be possible to support time-sensitive applications.
In Ethernet TSN, a number of extensions to existing standards have been proposed to address the latency challenge. The goal is not to eliminate
Figure 3: Time-Aware Scheduling
latency or jitter, but to reduce the latency as much as possible and, above all, guarantee maximum limits for latency and jitter performance. Two solutions, in particular, go a long way towards meeting this goal; time-aware scheduling and preemptive forwarding.
Time-aware scheduling
In conventional Ethernet, frames are sent in their entirety. In other words, when the switch begins to send a frame, other frames will have to wait until it is finished. For a maximum length Ethernet frame of 1518 bytes at 10 Gbps, it takes 1.23 microseconds to send the frame. This might not sound like much, but when latency is bounded typically in nanoseconds, 1 microsecond is a lot. Most of the applications using Ethernet are not time-sensitive and can afford the wait, but timesensitive applications cannot afford this kind of delay.
Ethernet TSN introduced the concept of a timeaware scheduler in IEEE 802.1Qbv to address this issue by ensuring that high priority frames are always given preference in transmission. The time-aware scheduler is based on time-division multiple access concepts where time is divided into discrete time intervals of equal length called cycles. It relies on gPTP time synchronization to ensure that all nodes in the Ethernet TSN network are time-synchronized.
Within each cycle, a number of time-slots can be allocated for transmission of data. At each port, the time-aware scheduler decides, which Ethernet frame is to be transmitted, as shown in Figure 3. It uses Class of Service (CoS) information, such as the Priority Code Point (PCP) from the VLAN tag, to prioritize frames for transmission in CoS queues. For each CoS queue there is a time-aware gate that controls whether the next frame in the CoS queue can be sent or not. The gate can be open for transmission or closed and this allows the scheduler to control which CoS priority will be transmitted in the next time-slot. With this mechanism, higher priority frames can be prioritized for transmission.
Preemptive forwarding
With time-aware scheduling, best-effort frames are only transmitted when no other higher priority frames are scheduled for transmission. However, while a best-effort frame is being transmitted, a higher priority frame could arrive. This frame could be supporting a time-sensitive application, which cannot tolerate delay.
With preemptive forwarding, defined in 802.1Qbu, the transmission of a lower priority Ethernet frame can be interrupted so that the higher priority Ethernet frame can be expedited. This, in effect, means that the higher priority express Ethernet frame supporting the timesensitive application experiences very little delay at the expense of other applications, which are not time-sensitive, as shown in Figure 4.
Figure 4: Preemptive Forwarding
The combination of time-aware scheduling and preemptive forwarding means that Ethernet frames supporting time-sensitive applications will be transmitted with the lowest possible latency.
Reliability
Internet protocols including Ethernet were designed to be tolerant to changes in the network. However, mechanisms for reestablishing paths through the network, such as Spanning Tree Protocol, can take a significant amount of time to converge on a new network state. There is therefore a need for reliably delivering Ethernet frames without significant delays to support time-sensitive applications. A network that has to support time-sensitive applications also needs to be tolerant to faulty distributed applications.
Ethernet TSN introduced the Frame Replication and Elimination for Reliability (FRER) mechanism in IEEE 802-1CB. To address faulty communications, Ethernet TSN also introduced the Per-Stream Filter and Policing (PSFP) mechanism first defined in IEEE 802.1Qci and matured in IEEE p802.1Qcr.
Frame Replication and Elimination for Reliability (FRER)
As the name suggests, FRER allows each transmitting Ethernet node to replicate Ethernet frames to provide multiple paths to the destination, as depicted in Figure 5.
Each replicated frame is provided with a sequence number. This allows receiving nodes to use the sequence numbers to remove duplicates received at the same ingress port. By using replication and elimination, there is a high likelihood that Ethernet frames will reach their destination without introducing any extra delay.
Per-Stream Filter and Policing (PSFP)
The goal of PSFP is to ensure that the failure of a single node is not propagated throughout the network. Ethernet TSN provided an amendment to IEEE 802.1Qci, which specifies objects and functions for limiting the bandwidth or timing resources that can be used by a stream of data. This means that if an Ethernet frame of a stream enters a switch and exceeds the allocated resources, it will be dropped.
Figure 5: Frame Replication and Elimination for Reliability
Figure 6: Ethernet TSN Configuration Models
Resource Management
Ethernet TSN uses dedicated time slots to transport frames, but reservation of these time slots and coordination of transmission over the network needs to be configured end-to-end. This means that new configuration and resource management mechanisms need to be introduced to support these enhancements.
In IEEE 802.1Qcc, three different models are defined for configuration and resource management; fully centralized, distributed and a hybrid model.
Fully centralized model
The fully centralized model proposes centralized control of resource allocation, similar to Software Defined Networks (SDN). Senders of Ethernet frames, called “talkers”, communicate with a Centralized User Configuration (CUC) instance to provide the requirements for the stream of Ethernet-based communication that they want to transmit. Receivers of this stream, called “listeners”, notify the CUC that they want to receive the stream, as can be seen in Figure 6.
The CUC communicates these requirements and configuration parameters to a Centralized Network Configuration (CNC) instance that is responsible for configuration of the network nodes that will support the path(s) that the stream will take through the network. This includes calculation and selection of the time-slot that is to be used for communication, which needs to be synchronized with all the nodes in the path. Ethernet TSN does not specify the protocols for configuration and network management, but allows exiting solutions to be used for implementation, such as Netconf and Yang.
De-centralized and hybrid models
The de-centralized model does not rely on centralized control to setup the path, but on message exchange between nodes in the network. In Ethernet TSN, a modified version of the Stream Reservation Protocol (STP) is defined in IEEE 802.1Qcc, which is used by the end-points to advertise their requirements and for the exchange of information for synchronization on reservation of time slots and paths.
In the hybrid model, both centralized and decentralized mechanisms are combined. The endpoints still use SRP to advertise their requirements, which removes the need for a CUC instance. However, network nodes can either use SRP or a CNC instance to coordinate reservations.
Figure 7: 5G Ultra-Reliable Low Latency Use Cases
Ethernet TSN opens new market opportunities
The Ethernet TSN extensions now make Ethernet a viable option for a number of market challenges that previously could not be addressed by Ethernet networks. Because the enhancements are implemented as extensions rather than totally new standards, Ethernet TSN is fully compatible with conventional Ethernet, allowing all of the associated Ethernet tools, solutions and management protocols to be exploited. It also means that time-sensitive and “best-effort” network traffic can be supported on the same network.
While Ethernet TSN work first began as a solution for audio/video bridging, there are a number of other applications that can benefit from Ethernet TSN today that open new and interesting market opportunities.
Ethernet TSN for 5G mobile fronthaul
5G mobile networks are now being deployed across the world. While the fifth-generation reference would seem to suggest an incremental improvement in performance compared to 4G, this is misleading. 5G is dramatically different to 4G with an ambition to support a much broader range of applications than previous generations. This includes applications and services that require Ultra-Reliable Low Latency Communication (URLLC) as shown in Figure 7.
The 5G Remote Access Network (RAN) is based on a virtualized architecture where functionality can be split and deployed either centrally at telecom data centers or remotely close to the antennae, as shown in Error! Reference source not found.. This enables network planners to achieve the most appropriate trade-off between latency and backhaul bandwidth requirements per service.
The interfaces between the split functionality nodes are called fronthaul interfaces and it is here that Ethernet TSN can play a significant role. For example, the interface between the Radio Unit (RU) and the Distributed Unit (DU) is based on Enhanced Common Public Radio Interface (eCPRI), which relies on Ethernet, while the interface between the Central Unit (CU) and DU is Ethernet based. Both of these interfaces can be based on Ethernet TSN.
Support for Ethernet TSN would require that current Ethernet nodes are upgraded or replaced to support Ethernet TSN mechanisms and time synchronization, but this is not as demanding a requirement as it first might appear. The increased performance requirements of 5G require time synchronization support in Ethernet nodes to assure end-to-end latency and jitter performance. The centralized management model using CUC and CNC instances is compatible with the SDN controller management models used in 5G where existing management protocols and models, such as NetConf and Yang can be used.
Figure 8: Ethernet TSN for 5G Fronthaul
IEEE 802.1CM Time Sensitive Networking for Fronthaul is a standard defining the Ethernet TSN features and protocols that need to be supported for transporting front-haul streams. It includes two profiles, A and B, which are designed to meet the requirements of Class 1 and Class 2 networks respectively. Class1 networks are based on the Common Public Radio Interface (CPRI) fronthaul interface used between the 4G RAN Baseband Unit (BBU) and Remote Radio Head (RRH), while Class 2 networks are based on the eCPRI fronthaul interface. In addition, four categories (A+, A, B and C) of time synchronization requirements are described defining the time error budget for each category.
Ethernet TSN for 5G mobile network sharing
The IEEE Ethernet TSN task force has an active project exploring the applicability of Ethernet TSN in 5G networks (https://1.ieee802.org/tsn/802- 1df/) called TSN profile for Service Provider Networks in IEEE802.1DF. There is an expectation that providers of mobile services will need to share 5G network infrastructure given the density of cells and number of devices in the 5G RAN.
5G network slicing can be used to reserve virtual resources in the 5G RAN to support services offered by a third party to their customers over the 5G network. However, it will be critical in these circumstances that Service Level Agreements (SLAs) are maintained, particularly for URLLC services and other time-sensitive applications. The ability of Ethernet TSN to support both best-effort and time-sensitive applications on the same Ethernet-based network infrastructure makes it very attractive as a means of supporting network sharing.
Ethernet TSN for industrial automation
One of the applications with most interest in Ethernet TSN is industrial automation. “Industry 4.0” is currently transforming production facilities into “Smart Factories” with the capability to reconfigure themselves automatically based on continuous feedback from a network of digital sensors on the factory floor. The sensors can be independent or agents in factory machines providing real-time feedback on status and events.
In order for Smart Factories to achieve automatic reconfiguration, it is vital that data from sensors is delivered as quickly as possible in a time synchronized manner. Feedback delays can cause incomplete or delayed responses to critical events or even misinterpretation of data leading to unintended consequences, which can be costly or even dangerous.
Figure 9: Ethernet TSN for Industrial Automation
While factories today already have implemented a great deal of automation, it can often involve different networks requiring interconnection with costly gateways. This is an additional cost and complexity that can be avoided if a single network could be used.
For example, ISA-95 level 1 field buses, such as Profibus, often handle the low-level communication between real-time production process sensors while Ethernet and IP networks are used for the larger and less frequent communication at higher ISA-95 levels for supervisory control and scheduling.
With Ethernet TSN, it is possible to replace level 1 buses with a network that is compatible with higher level Ethernet networks negating the need for gateways, as shown in Error! Reference source not found.. Ethernet TSN can provide the reliability and latency control that industrial sensor networks require and can be used to reliably deliver data to supervisory control entities. In addition, the resource management models provide flexibility in configuring and managing Ethernet TSN networks in a manner that is compatible with other management systems required in industry 4.0.
The Ethernet TSN task force is working on a profile for industrial automation (https://1.ieee802.org/tsn/iec-ieee-60802/) in collaboration with IEC in IEEE/IEC 60802.
Ethernet TSN for in-vehicle communication
Vehicles are increasingly relying on a network of sensors to provide real-time feedback on the driving experience as well as ensure safety. Invehicle networks have typically relied on industrial bus systems such as CAN and MOST buses for communication, but as sensors and in-vehicle computing resources become more sophisticated, there is a need to scale bandwidth, which is a challenge for bus systems.
CAN and LIN buses are designed for low-speed communication and control. Buses like FlexRAY provide speeds up to 10 Mbps but are more costly. The extensive use of high-fidelity sensors and cameras as well as infotainment systems has led to the adoption of higher speed bus systems like MOST and physical layers such as LVDDS and CML, but implementations of these technologies can be proprietary.
Ethernet was first introduced to scale bandwidth, but now automotive companies are considering Ethernet TSN as a basis for all in-vehicle communication as it can provide the reliable and real-time communication that modern vehicles require, as shown in Error! Reference source not found.. For example, the ultimate goal of autonomous vehicles requires a high-bandwidth and reliable communication network for real-time delivery of time-sensitive sensor information, both in the car and also over 5G mobile networks to central control centers.
An additional consideration is cost. The ubiquitous implementation of Ethernet along with welldefined standards promises to reduce cost by simplifying in-vehicle networks and replacing more costly proprietary components.
The Ethernet TSN task group is defining a profile for automotive Ethernet in standard IEEE 802.1DG (https://1.ieee802.org/tsn/802-1dg/).
Ethernet TSN for avionics
While IEEE has defined profiles for 5G fronthaul, service provider networks, industrial automation and automotive in-vehicle communications, a similar profile for avionics has not been defined.
However, avionics is one market segment that can greatly benefit from Ethernet TSN. Avionics has similar challenges to automotive in-vehicle communication and could therefore use Ethernet TSN in a similar way to simplify avionic networks and provide a single, cost-efficient network for communication.
Avionics networks today use Time Triggered Ethernet (TTEthernet), a time-critical network evolution of Avionics Full Duplex Switched Ethernet (AFDX). It is standardized in SAE AS6802 and provides strict timing transmission of data based on an off-line schedule table and global synchronization.
In October 2019, the SAE standards organization established a workgroup called Aerospace TSN Profile (AS6675) to develop a profile of Ethernet TSN that is applicable to Avionics cases. The SAE organization is cooperating with IEEE 802.1 on the development of a TSN profile for aerospace. In the 2020 July plenary, it was agreed that work should begin on this profile. The Project Authorization Request (PAR) for IEEE 802.1DP: TSN Profile for Aerospace is now under development. We can therefore expect this profile to be added to the official IEEE list of Ethernet TSN profiles by 2021.
Figure 10: Ethernet TSN for in-vehicle communication
Figure 11: Comcores Manticore Ethernet TSN Switch
Comcores Ethernet TSN IP
With a dedicated program for Ethernet TSN development that covers both RTL and software, Comcores provides Ethernet TSN IP components that are continuously updated to take advantage of the latest standard extensions. This enables accelerated development of time sensitive Ethernet solutions that can be upgraded to take advantage of the latest improvements. The current Ethernet TSN IP portfolio includes:
- Ethernet TSN MAC IP
- Supports data rates from 10 Mbps to 25 Gbps
- Supports IEEE 802.1AS gPTP hardware timestamping
- Supports IEEE 802.1 Br interspersing express traffic
- Supports IEEE 802.1Qbu preemptive forwarding and IEEE 802.1Qbv time-aware scheduling
- Low-latency cut-through implementation
- Fully configurable core with optional VLAN, PCS and DMA integration
- Manticore Ethernet TSN Switch IP
- Supports data rates from 10 Mbps to 25 Gbps
- Fully configurable selection of port interface speeds
- Quality of service guarantees for timesensitive switching
- No starvation by lower priority classes
- Bounded processing and queuing delays
- Supports IEEE1588 PTP transparent clock and IEEE 802.1AS gPTP
- IEEE 802.1CB FRER and IEEE 802.1Qci PSFP support are also available as optional features
- Software controller for optimal routing
- Generalized PTP IP
- Full support for both IEEE 1588 and IEEE 802.1AS for Ethernet TSN
- Sub-nano second precision
- Enhanced redundancy using several masters and spanning tree protocol
Comcores Ethernet TSN IP supporting industry needs
The following matrix provides an overview of approved Ethernet TSN standards relevant for each industry that can be delivered by Comcores.
Ethernet TSN Profiles | Time Synchronization | Resource Management | Latency and Jitter | Reliability | |
5G Mobile Fronthaul | IEEE 802.1 CM | IEEE 1588 IEEE 802.1AS | IEEE 802.1 Br | IEEE 802.1Qbv IEEE 802.1 Qbu IEEE802.1Qav IEEE 802.1Qch IEEE 802.1Qcr | IEEE 802.1CB IEEE 802.1Qci |
5G Mobile Network Sharing | IEEE 1588 IEEE 802.1AS | IEEE 802.1 Br | IEEE 802.1Qbv IEEE 802.1 Qbu IEEE802.1Qav IEEE 802.1Qch IEEE 802.1Qcr | ||
Industrial Automation | IEC/IEEE* 60802 IEEE | IEEE 802.1AS | IEEE 802.1 Br IEEE 802.1Qcc | IEEE 802.1Qbv IEEE 802.1 Qbu | IEEE 802.1CB IEEE 802.1Qci |
In-Vehicle Communications | P802.1DG* | IEEE 802.1AS | IEEE 802.1 Br IEEE 802.1Qat IEEE 802.1Qcc | IEEE 802.1Qbv IEEE 802.1 Qbu IEEE802.1Qav IEEE 802.1Qcr | IEEE 802.1CB IEEE 802.1Qci |
Avionics | SAE AS-1A2* | IEEE 802.1AS | IEEE 802.1 Br | IEEE 802.1Qbv IEEE 802.1Qcr | IEEE 802.1CB IEEE 802.1Qci |
* Profiles that are not yet standards, but targets for future support
Stake your claim in Ethernet TSN with Comcores
Comcores provides the fundamental IP implementations that enable equipment vendors to get a running start on pursuing the emerging Ethernet TSN opportunity. This is a broad opportunity that cuts across industry boundaries and yet these disparate industries are becoming more connected by virtue of 5G.
5G was specifically designed to support solutions for network sharing, industrial automation and autonomous vehicles. The current deployment of 5G should prove to be a catalyst for increased interest in how 5G can support industrial automation and in-vehicle communications. The ability of Ethernet TSN to address 5G fronthaul, network sharing, industrial automation and in-vehicle communication needs with a common communications infrastructure that is also scalable, flexible and compatible with conventional Ethernet networks provides a compelling case for adoption.
Comcores is committed to supporting Ethernet TSN and will remain at the forefront of development with continuous releases of proven and reliable Ethernet TSN IP supporting the latest Ethernet TSN standards. This ensures that our equipment vendor partners and their customers can take quickly take advantage of the latest Ethernet TSN developments with as low risk as possible.
For more information on Comcores IP solutions and access to Ethernet TSN IP visit: www.comcores.com
If you wish to download a copy of this white paper, click here
|
Comcores Hot IP
Related Articles
New Articles
Most Popular
E-mail This Article | Printer-Friendly Page |