Time-Sensitive Networking
Time-Sensitive Networking (TSN) is the collective name for a family of standards and amendments produced by the IEEE 802.1 working group that give ordinary switched Ethernet a property engineers normally assume it cannot have: a worst-case latency that can be computed in advance, defended in a design review, and measured on the bench. TSN is not a protocol in the sense that PROFINET, EtherNet/IP, or EtherCAT is a protocol. It defines no application layer, no device model, and no object dictionary. It changes what happens inside the bridge and inside the endpoint media access controller, in the interval between the moment a frame arrives at an ingress port and the moment its final bit leaves an egress port.
That distinction explains both the appeal and the difficulty of TSN. The appeal is convergence: if standard Ethernet hardware can carry a motion-control update with a guaranteed bound alongside a camera stream and a software download, then the separate control network, the separate video network, and the separate information-technology network can collapse onto one physical infrastructure. The difficulty is that TSN delivers a bound only when the network is configured to produce one. A TSN switch that has been powered on and left at its defaults is a normal Ethernet switch with expensive silicon inside. The determinism lives in the schedule, the reservation, and the policing configuration, not in the part number.
This article works through the toolbox in the order an engineer uses it: why plain Ethernet has no useful latency bound, what a bound would mean, then the standards in functional groups covering time, scheduling and shaping, reliability, ingress control, and configuration. It closes with the profiles, a worked latency budget, and an accounting of what TSN costs.
Why Standard Ethernet Is Not Deterministic
Switched Ethernet is a store-and-forward, best-effort network. A bridge receives a frame, checks its frame check sequence, looks up the destination, and places the frame in an egress queue. If the egress port is idle, the frame departs almost immediately. If the port is busy, the frame waits. Nothing in the base standard bounds how long that wait may be, and several independent mechanisms conspire to make the wait variable.
Interference from a Frame Already in Transmission
An Ethernet transmission cannot be interrupted. When a high-priority frame becomes ready one bit-time after a maximum-length frame has begun to leave the port, the high-priority frame waits for the entire remaining transmission. A 1,522-byte tagged frame, counted with its preamble, start-of-frame delimiter, and interpacket gap, occupies 1,542 byte-times on the wire. At 100 Mbit/s that is about 123 microseconds; at 1 Gbit/s it is about 12.3 microseconds; at 10 Mbit/s it is about 1.2 milliseconds. If the network permits 9,000-byte jumbo frames, the same calculation gives roughly 722 microseconds at 100 Mbit/s. This single term dominates the latency budget of many industrial designs, and it is the term that frame preemption exists to remove.
Queueing and Burst Accumulation
IEEE 802.1Q defines up to eight traffic classes per port, and strict-priority arbitration will always serve the highest non-empty queue first. Strict priority is a useful ordering rule, but by itself it is not a bound. Several talkers sending at the same priority still contend, and their traffic does not stay evenly spaced as it crosses the network. Two streams that arrive at a bridge from different ports and depart on a common port are serialized on departure, which clumps them together. At the next hop the clump interferes with a third stream, producing a larger clump. This burst accumulation means the worst-case delay of a stream grows faster than the number of hops unless something actively reshapes traffic along the way.
Buffer Depth and Overload
Vendors have historically competed on buffer size, because deep buffers reduce frame loss under bursty load. The consequence, widely discussed under the name bufferbloat, is that loss is converted into delay. A megabyte of buffer on a 1 Gbit/s port represents about 8 milliseconds of queued transmission time. For a bulk file transfer that is a good trade. For a control loop closing at 1 kilohertz it is fatal. Plain Ethernet also has no admission control: nothing prevents a misconfigured or failed device from transmitting continuously and saturating the very queue a control stream depends on. A latency bound that assumes well-behaved neighbors is not a bound.
Endpoint Contributions
The network is not the only source of jitter. A general-purpose operating system may hold a frame in a socket buffer for an unpredictable interval before the media access controller sees it, and the receiving application may not be scheduled the moment the frame arrives. TSN addresses the wire; the endpoint software stack must be engineered separately.
What Bounded Latency Actually Means
The phrase "real time" is often used to mean "fast." In network engineering it means something more specific and less flattering: the system's timing behavior is known and bounded, whether or not it is fast. A network that always delivers a frame in between 8 and 10 milliseconds is deterministic. A network that usually delivers in 50 microseconds but occasionally takes 40 milliseconds is not, and it is the occasional case that stops a machine or trips a safety function.
A useful specification therefore names four quantities rather than one. The first is worst-case end-to-end latency, the maximum interval from the talker application handing off a frame to the listener application receiving it. The second is jitter, the difference between the best case and the worst case, which matters for control loops and for media playout because it determines buffer depth. The third is the fault model under which the bound holds: a bound that survives a single link failure is a different and more expensive claim than a bound that assumes no failures. The fourth is the load model, because every bound is conditional on the traffic that other devices are permitted to offer.
Building such a specification is a matter of accounting. The end-to-end interval decomposes into the talker's transmission jitter, the serialization time of the frame on each link, the propagation delay of each cable, the residence time in each bridge, and the listener's processing delay. Residence time is where TSN concentrates: it comprises ingress processing and lookup, the queueing delay caused by other traffic, and the egress serialization of the frame itself. Each of the shaping and scheduling amendments described below is a different technique for making the queueing term calculable, and each buys that calculability with a different currency: synchronization, configuration effort, per-stream state, or bandwidth.
Three analytical traditions are used to produce the numbers. Network calculus derives bounds from arrival curves and service curves and is well suited to the credit-based and asynchronous shapers. Response-time analysis, borrowed from real-time scheduling theory, suits priority-based systems. Exhaustive schedule synthesis, in which every transmission instant is fixed in advance, suits the time-aware shaper and produces the tightest bounds at the cost of the hardest computation. A design that cannot say which method produced its number has not produced a bound.
How the Toolbox Is Organized
TSN is usually discussed using the amendment letters under which each feature first appeared, and those designations remain the common currency of product datasheets and requests for quotation. The underlying documents have largely moved. Most of the bridge-side features were folded into revisions of the base bridging standard, so the current normative text lives in IEEE 802.1Q rather than in the individual amendments; IEEE Std 802.1Q-2018 absorbed the first wave, and IEEE Std 802.1Q-2022 absorbed later ones. An engineer citing 802.1Qbv in a specification is naming a feature, not a document that must be purchased separately.
A second group of TSN standards are freestanding rather than amendments to 802.1Q. IEEE 802.1AS covers timing and synchronization. IEEE 802.1CB covers frame replication and elimination. IEEE 802.1BA, IEEE 802.1DG, IEEE 802.1DP, and IEC/IEEE 60802 are profiles, which select from the toolbox rather than adding to it. A third document, IEEE 802.3br, sits in the Ethernet working group rather than 802.1, because frame preemption requires a change to the media access control sublayer itself.
Grouped by the problem each one solves, the toolbox looks like this. For a common notion of time there is IEEE 802.1AS. For deciding when frames may leave a port there are the time-aware shaper of 802.1Qbv, the credit-based shaper of 802.1Qav, cyclic queuing and forwarding of 802.1Qch, and asynchronous traffic shaping of 802.1Qcr, with frame preemption from 802.1Qbu and IEEE 802.3br removing the interference term that limits all of them. For surviving faults there is 802.1CB. For preventing a misbehaving talker from invalidating everyone else's bound there is per-stream filtering and policing in 802.1Qci. For getting the configuration into the devices there is 802.1Qcc. The IEEE 802.1 Time-Sensitive Networking task group continues to add to the set, with projects in progress on shaper parameters for bursty traffic, priority-based flow control enhancements, enhancements to cyclic queuing and forwarding, source flow control, and traffic engineering for bridged networks that include wireless technologies.
Time: IEEE 802.1AS and the Generalized Precision Time Protocol
Every scheduled mechanism in TSN presupposes that the bridges and endpoints agree on what time it is. IEEE 802.1AS provides that agreement. It defines the generalized Precision Time Protocol, universally abbreviated gPTP, which is a profile of IEEE 1588. IEEE Std 802.1AS-2011 profiled IEEE 1588-2008; IEEE Std 802.1AS-2020, published in January 2020, was a full revision aligned with the 2019 edition of IEEE 1588; and the task group published a further revision, IEEE Std 802.1AS-2025, in 2025.
What the Profile Restricts
IEEE 1588 is a large standard with many options, and interoperability between two conformant implementations is not guaranteed unless both follow the same profile. The gPTP profile narrows the choices sharply. It permits only the peer-to-peer delay measurement mechanism, in which each device measures the delay to its immediate neighbor with a Pdelay_Req and Pdelay_Resp exchange, rather than the end-to-end mechanism in which an endpoint measures the whole path. It requires that every device along the path be time-aware, which is the single most consequential restriction in practice: a legacy switch inserted into a gPTP path does not merely fail to help, it destroys the synchronization of everything behind it, because its variable store-and-forward delay is not measured or compensated. It fixes the transport to specific media mappings, including full-duplex IEEE 802.3 links, IEEE 802.11 wireless, and Ethernet passive optical networks.
Grandmaster Selection
One device in each gPTP domain is the grandmaster, the source of the timebase. Selection uses a best master clock algorithm that compares announced attributes in a fixed order: a configurable priority1 field, then clock class, then clock accuracy, then the variance of the clock's offset, then a second configurable priority field, and finally the clock identity as a tiebreaker. The result is a spanning tree of time-aware systems rooted at the winning device. Because the comparison is deterministic and every device runs it on the same announcement data, the tree converges without negotiation. IEEE 802.1AS also permits external port configuration, in which a management system assigns master and slave roles directly and the algorithm is bypassed. Industrial installations frequently prefer this, because an automatic election that quietly moves the grandmaster to a different device also quietly changes which device's oscillator determines machine timing.
How Accuracy Is Achieved
Two mechanisms do the work. Link delay is measured explicitly by the peer delay exchange, so cable length is compensated rather than assumed. Residence time inside each bridge is measured and accumulated into a correction field, so the store-and-forward delay of the bridge does not accumulate as error. In addition, each device computes the ratio between its own local oscillator frequency and the grandmaster's, a process called syntonization, so that time can be interpolated between synchronization messages rather than stepped. IEEE 802.1AS states a performance goal of time synchronization error not exceeding 1 microsecond across seven hops. Meeting it requires hardware timestamping at or near the media-independent interface boundary; software timestamping in a driver interrupt is typically one to two orders of magnitude worse and its error is load-dependent.
Redundancy in the 2020 Revision
The 2011 edition supported a single gPTP domain, which made the grandmaster a single point of failure whose loss forced every device into holdover on its own oscillator. IEEE 802.1AS-2020 added support for multiple simultaneous gPTP domains, allowing an installation to run two or more independent timebases from different grandmasters over the same network and to fail over between them without a synchronization transient. It also introduced the common mean link delay service, which measures peer link delay once per link and shares the result across all domains rather than repeating the exchange per domain, and it tightened and clarified the performance requirements.
Failure Modes Worth Designing For
Path asymmetry is the classic error source: the peer delay mechanism assumes the transmit and receive directions have equal delay, and any asymmetry appears as an offset of half the difference. Media converters, asymmetric optics, and certain physical layer devices introduce it. Grandmaster loss forces holdover, and the drift rate of the local oscillator then sets how long the schedule remains valid; an ordinary crystal oscillator drifting at 50 parts per million accumulates 50 microseconds of error per second, which will break a microsecond-class schedule almost immediately, whereas an oven-controlled oscillator buys hours. Because the entire scheduled traffic mechanism depends on time, a synchronization audit is the first item on any TSN commissioning checklist.
Scheduling: The Time-Aware Shaper of 802.1Qbv
IEEE Std 802.1Qbv-2015, published as Amendment 25 to the bridging standard and now part of 802.1Q, is the mechanism most people mean when they say a network is "scheduled." It places a transmission gate in front of each of the eight egress queues on a port. A gate is either open, in which case its queue may be selected for transmission, or closed, in which case it may not be, regardless of priority.
The gates are driven by a gate control list, a cyclic sequence of entries. Each entry carries an eight-bit gate state vector, one bit per traffic class, and a time interval for which that vector applies. The list has a total cycle time and an administrative base time expressed in the gPTP timebase, so every bridge in the network opens and closes its gates against the same clock. A minimal list might be two entries: open the gate of the scheduled class alone for 200 microseconds, then open the gates of the remaining classes for 800 microseconds, repeating every millisecond. During the protected window the scheduled stream meets no contention at all, and its delay through the bridge reduces to processing and serialization.
Configuration is deliberately double-buffered. The administrative parameters, comprising the control list, cycle time, base time, and cycle time extension, are staged and then applied at a future instant when a configuration change flag is set, at which point they become the operational parameters. This allows a controller to change schedules across an entire network coherently rather than hop by hop, which matters because a partially applied schedule is worse than either the old one or the new one.
The Guard Band Problem
A gate that closes does not stop a transmission already in progress. If a bridge begins sending a maximum-length best-effort frame just before the protected window opens, that frame is still on the wire when the scheduled frame becomes eligible, and the schedule is violated. The base remedy is a guard band: the bridge stops starting new frames on the unscheduled queues for one maximum frame transmission time before the protected window begins. The guard band is safe and expensive. On a 1 Gbit/s link it wastes roughly 12.3 microseconds of every cycle; with a 250-microsecond cycle that is nearly five percent of the link, and with the short cycles used in motion control it can be far worse. Length-aware scheduling improves matters by using the per-queue maximum service data unit parameter to shrink the guard band to the largest frame that a given queue may actually send, but the fundamental problem remains until preemption is available.
What the Time-Aware Shaper Costs
The time-aware shaper produces the tightest bounds available in TSN, because in the limit it removes contention entirely rather than bounding it. The costs are proportionate. It requires network-wide synchronization, so a synchronization failure is a scheduling failure. It requires a computed schedule, which is the subject of a later section. And it makes the network's behavior a function of a global configuration artifact, so adding one device or moving one cable may require recomputing and redistributing every gate control list in the affected region.
Frame Preemption: 802.1Qbu and IEEE 802.3br
Frame preemption removes the interference term that guard bands otherwise have to absorb. It required changes on both sides of the standards boundary: IEEE Std 802.1Qbu-2016 defines the bridge-side behavior, including which traffic classes are express and which are preemptable, while IEEE Std 802.3br-2016 defines the media access control merge sublayer that performs the interruption. The merge sublayer was subsequently incorporated into the base Ethernet standard.
The merge sublayer presents two media access control interfaces to the layers above: an express interface and a preemptable interface. Frames offered to the express interface may interrupt a frame in progress on the preemptable interface. The interrupted frame is transmitted as a sequence of fragments, each carrying a start-of-mPacket delimiter that distinguishes an initial fragment from a continuation, a fragment count that allows the receiver to detect a lost fragment, and its own cyclic redundancy check. The receiving merge sublayer reassembles the fragments and delivers a single frame upward. Preemption is therefore a link-local mechanism, negotiated and reassembled hop by hop; it is invisible to the network layer and is not related to IP fragmentation.
Two rules limit how finely a frame may be cut. A fragment must be large enough to remain a legal transmission, and the standard sets the minimum fragment at 64 bytes. Equally, the remainder left after a cut must itself be large enough, so a frame cannot be preempted arbitrarily close to its end. The combined effect is that the worst-case non-preemptable residue is 127 bytes: 64 bytes for the minimum initial fragment plus the 63 bytes that cannot be split off the tail. On a 1 Gbit/s link that residue, with framing overhead, corresponds to roughly one microsecond of blocking rather than the 12.3 microseconds of a full-length frame, an improvement of more than an order of magnitude in the dominant term of many latency budgets.
Because both link partners must implement the merge sublayer for it to be used, the standard defines a verification handshake in which one side sends a verify message and expects a response before enabling preemption. A link between a preemption-capable switch and a legacy endpoint simply runs without preemption, which is the correct behavior but also a common source of surprise when a measured latency budget silently reverts to the guard-band case after a hardware substitution.
Shaping Without a Global Schedule
Not every application needs, or can afford, a computed gate control list. Three other shapers in the toolbox trade some tightness of bound for a great deal less configuration effort, and understanding when each is appropriate is one of the more valuable pieces of TSN judgment.
The Credit-Based Shaper of 802.1Qav
IEEE Std 802.1Qav-2009 is the oldest member of the family and the one inherited directly from audio-video bridging. It assigns each shaped queue a credit counter. Credit accumulates at a configured rate, called the idle slope, while the queue has frames waiting but is not transmitting, and is depleted at the send slope while the queue transmits. A queue may transmit only when its credit is not negative, and credit is clamped by high and low limits. The effect is to spread a burst out in time rather than releasing it at line rate, which directly attacks the burst accumulation problem described earlier.
The audio-video bridging profile defines two stream reservation classes on top of this shaper. Class A uses an observation interval of 125 microseconds, class B uses 250 microseconds, and the profile targets a worst-case latency of 2 milliseconds for class A and 50 milliseconds for class B across a maximum of seven hops. Those figures are generous by industrial standards and entirely adequate for professional audio, which is exactly the application the mechanism was designed for. The credit-based shaper requires no synchronized clock and very little per-stream computation, which is why it remains the default choice for media networking.
Cyclic Queuing and Forwarding in 802.1Qch
IEEE Std 802.1Qch-2017 defines cyclic queuing and forwarding, sometimes called the peristaltic shaper. The idea is to use two buffers alternately: frames received during cycle n are transmitted during cycle n plus one, with the gates arranged so that the receiving buffer and the transmitting buffer swap roles every cycle. The consequence is remarkable in its simplicity. End-to-end latency no longer depends on the identity of the stream, the number of streams, or their arrival pattern; it depends only on the cycle time and the number of hops, with a bound of roughly the number of hops plus one, multiplied by the cycle time.
This is the cheapest path to a defensible bound, because the bridge holds no per-stream state and the configuration is one number rather than a synthesized schedule. The price is granularity. The cycle must be at least as long as the transmission of the largest frame plus the necessary guard, so short cycles demand preemption or a restricted maximum frame size, and every stream pays the full per-hop cycle whether it needs it or not. Latency is uniform but not tight. Work continues in the task group on enhancements to cyclic queuing and forwarding to relax the single-cycle constraint.
Asynchronous Traffic Shaping in 802.1Qcr
IEEE Std 802.1Qcr-2020 defines asynchronous traffic shaping, based on the urgency-based scheduler. Each stream is reshaped at every hop using a token bucket emulation that computes an eligibility time for each frame, so a burst that formed at an earlier hop is flattened again before it can compound. The defining characteristic is in the name: the mechanism is asynchronous and requires no synchronized clock at all. Bounds are derived analytically from the token bucket parameters rather than from a schedule.
Asynchronous traffic shaping suits networks with many streams of dissimilar rates and periods, particularly where talkers cannot be synchronized or where the traffic mix changes at runtime. Its cost is per-stream state and a per-frame eligibility computation in the bridge, which is more demanding silicon than a credit counter, and bounds that are looser than a good gate control list would produce. Vendor support has been slower to appear than for the time-aware shaper, so availability should be verified rather than assumed.
Reliability: Frame Replication and Elimination
A latency bound that assumes no faults is of limited use in machinery that must not stop. Conventional Ethernet redundancy protocols reconverge after a failure, and reconvergence takes time; even the fastest ring protocols lose frames during the transition. IEEE Std 802.1CB-2017 takes the alternative approach of sending frames twice over disjoint paths so that a single failure costs nothing at all, a property usually described as seamless redundancy.
The mechanism has three parts. A stream identification function decides which frames belong to which stream, using one of several defined methods: a null identification that keys on destination address and virtual local area network identifier, source address and identifier variants, active and passive destination address variants that also rewrite the address, and an IP stream identification function that keys on higher-layer fields. A sequence generation function then appends a redundancy tag, carried under EtherType 0xF1C1, containing a sequence number. A sequence recovery function at the merge point discards duplicates. Two recovery algorithms are defined: a vector recovery algorithm that maintains a sliding history window and so tolerates reordering, and a simpler match recovery algorithm that accepts only strictly increasing sequence numbers. A latent error detection function periodically compares the counts of frames passed and discarded, which is the only way to notice that one of the two paths failed silently some time ago and the system has been running unprotected ever since.
How This Differs from PRP and HSR
The industrial world already had two seamless redundancy protocols, both defined in IEC 62439-3. The Parallel Redundancy Protocol attaches each doubly attached node to two entirely independent local area networks and appends a redundancy control trailer, carried under EtherType 0x88FB, to every frame. High-availability Seamless Redundancy uses a ring instead, with each node forwarding as well as originating, and inserts its tag under EtherType 0x892F immediately after the source address. Both are proven, widely deployed in substation automation, and simple to reason about.
The differences from 802.1CB are architectural rather than cosmetic. PRP and HSR are topology-bound: PRP requires two complete parallel networks, and HSR requires a ring. FRER works over an arbitrary topology, provided disjoint paths exist. PRP and HSR duplicate all traffic from a protected node; FRER duplicates per stream, so a design can protect a safety interlock while leaving a video feed unprotected on the same wire. PRP and HSR place replication and elimination in end nodes or in dedicated redundancy boxes; FRER allows a bridge to be the point where a stream splits and another bridge to be where it merges, which reduces the endpoint burden. The cost of that flexibility is configuration: FRER has more parameters, and its correctness depends on the paths actually being disjoint, which is a property of the routing configuration rather than of the cabling diagram. In every case the bandwidth of a protected stream is doubled on the segments where both copies travel.
Ingress Control: Per-Stream Filtering and Policing
IEEE Std 802.1Qci-2017 is the least glamorous piece of the toolbox and arguably the most important, because it is what makes an egress bound trustworthy. Every guarantee described so far is conditional on other devices sending only what they said they would send. Per-stream filtering and policing enforces that condition at the ingress port, before a misbehaving talker can consume the resources the schedule reserved for someone else.
The processing chain has three stages. A stream filter matches an incoming frame by its stream handle and priority and directs it to a stream gate and a flow meter. A stream gate is a time-based gate analogous to the egress gates of 802.1Qbv, driven by its own control list against the same gPTP timebase; a frame arriving when its gate is closed is discarded. This is a strong statement: a stream that is supposed to arrive in a particular 50-microsecond window is not merely deprioritized when it arrives outside that window, it is dropped. The stream gate may also assign an internal priority value, allowing the received priority to be overridden by the ingress policy rather than trusted from the sender. A flow meter then applies a bandwidth profile with committed and excess information rates and corresponding burst sizes, marking or dropping frames that exceed contract.
Three classes of problem are addressed by the same mechanism. A failed device that transmits continuously, the classic babbling idiot, is confined to its contracted rate at the first bridge it reaches. A well-intentioned device whose firmware was updated to a shorter cycle time is caught before its extra traffic degrades a neighbor. And a compromised device attempting to disrupt a control network by flooding is limited in exactly the same way, which is why per-stream policing appears in security discussions as well as in reliability ones. The filter state also provides diagnostics: counters for frames dropped because a gate was closed, because a frame exceeded the maximum service data unit, or because the meter marked them, which turn an intermittent complaint into a located fault.
Configuration: 802.1Qcc, the CNC, and the CUC
A network with gate control lists, redundancy tags, stream filters, and reserved bandwidth needs those parameters to arrive in the devices, and the parameters must be consistent across every device on the path. IEEE Std 802.1Qcc-2018 addresses this, both by enhancing the stream reservation protocol inherited from audio-video bridging and by defining an architecture with a user-to-network interface between the applications that need streams and the network that must carry them.
Three configuration models are defined. In the fully distributed model there is no central controller: talkers advertise streams and listeners subscribe using the stream reservation protocol, and each bridge independently accepts or rejects a reservation based on its own resources. This is plug-and-play and requires no engineering tool, which is why audio installations favor it. It cannot, however, compute a global schedule, because no entity has a global view.
In the centralized network configuration model, a centralized network configuration entity, universally abbreviated CNC, holds the topology and the capabilities of every bridge, computes the schedules and reservations, and pushes the resulting configuration into the devices. Management typically uses NETCONF or RESTCONF against YANG data models, which is the same tooling used elsewhere in modern network automation. End stations still make their requests through the distributed protocol, and the CNC intercepts them at the network edge.
In the fully centralized model a second entity, the centralized user configuration or CUC, sits above the applications. The CUC discovers end stations, learns their capabilities and their timing requirements, and presents consolidated requests to the CNC. This is the model that industrial automation profiles assume, because in a machine the application requirements are known at engineering time from the control program, not discovered at runtime by the devices themselves. The CUC also handles the part the network cannot: aligning the application's execution schedule in the endpoint with the transmission schedule in the network, so that a frame is produced shortly before its gate opens rather than a cycle too late.
The trade-off between the models is the familiar one. Distributed configuration is resilient and self-organizing but achieves only the bounds that local admission control can prove. Centralized configuration achieves far tighter bounds but concentrates the design knowledge, and the correctness of the network, in a tool and a database. In a centralized deployment the CNC is part of the machine, and its configuration must be version-controlled, backed up, and revalidated after every topology change with the same rigor applied to the control program itself.
Profiles: Turning a Toolbox into a Specification
The toolbox is too large to specify directly. Two vendors can both claim conformance to TSN and share almost no features. Profiles solve this by selecting a subset of features, options, default values, and procedures for a particular application domain, and by stating conformance requirements that a purchaser can actually test against.
The Audio-Video Bridging Heritage
TSN did not begin as an industrial technology. It began in 2005 as audio-video bridging, an effort to carry professional audio and video over Ethernet with the low, bounded latency that live sound reinforcement requires. That work produced IEEE 802.1AS for time, IEEE 802.1Qav for shaping, IEEE 802.1Qat for stream reservation, and IEEE Std 802.1BA-2011 as the umbrella profile, alongside the IEEE 1722 transport protocol and the IEEE 1722.1 discovery and control protocol. In November 2012 the audio-video bridging task group was renamed the Time-Sensitive Networking task group to reflect the expansion of its scope into automotive and industrial applications. IEEE 802.1BA was revised in 2021. The Avnu Alliance provides device certification for the resulting ecosystem, and in 2018 announced the Milan initiative to sharpen interoperability among professional audio devices, an area in which nominal conformance to a broad standard had proved insufficient in practice.
Industrial Automation: IEC/IEEE 60802
The industrial profile is a joint project of IEC subcommittee 65C working group 18 and IEEE 802, producing a dual-logo standard that is simultaneously an IEC and an IEEE document. It selects the features, options, configurations, defaults, protocols, and procedures of bridges, end stations, and local area networks appropriate to industrial automation networks. IEC/IEEE 60802 was published on 29 June 2026 after an unusually long development period, and its arrival matters commercially as well as technically, because it gives the competing industrial protocol organizations a common substrate. Avnu Alliance, the CC-Link Partner Association, ODVA, the OPC Foundation, and PROFIBUS and PROFINET International have announced a collaboration to produce a single shared conformance test plan for the profile, which is a meaningful commitment given that those bodies otherwise sponsor rival protocol stacks.
Automotive: IEEE 802.1DG
IEEE Std 802.1DG-2025, approved by the standards board on 28 May 2025 and published on 6 June 2025, specifies a profile for secure, highly reliable, deterministic in-vehicle bridged Ethernet networks. The automotive context imposes constraints the industrial one does not: the topology is fixed at design time and never changes in the field, cost pressure is extreme, the physical layer is often a single twisted pair rather than the four-pair cabling of a factory, and the network must start up within the hard deadlines that a vehicle's wake-up sequence imposes. The profile accordingly emphasizes static configuration, careful selection among the shapers, and integration with automotive security provisions. A companion aerospace profile, IEEE 802.1DP-2025, was developed jointly with SAE as AS6675 for onboard aircraft Ethernet.
Protocol Families Riding on TSN
Existing industrial protocols have adopted TSN as a lower layer rather than being replaced by it, which preserves the application-layer investment their users have made. PROFINET defines conformance class D for operation over TSN. CC-Link IE TSN replaces the token-passing arbitration of its predecessor with TSN mechanisms. ODVA has defined EtherNet/IP with TSN, and the OPC Foundation's field-level communications initiative specifies OPC UA over TSN. In each case the protocol contributes the device model and the engineering tooling while TSN contributes the bounded transport.
Building a Determinism Budget
The pieces are only useful when assembled into a number. Consider a representative industrial case: a control stream of 128 bytes produced every 500 microseconds, crossing three bridges on 1 Gbit/s links, sharing the network with best-effort traffic that may include maximum-length frames, in a design that uses the time-aware shaper with frame preemption enabled.
The budget accumulates as follows. The talker's transmission instant is uncertain by the synchronization error plus whatever jitter the endpoint software contributes; with hardware timestamping and a 1-microsecond synchronization bound, a well-implemented endpoint contributes a few microseconds. Serialization of a 128-byte frame with overhead on a 1 Gbit/s link takes on the order of 1.2 microseconds. Cable propagation is about 5 nanoseconds per meter, so 100 meters contributes half a microsecond and is usually negligible against the other terms, though it stops being negligible in a plant with kilometer-scale fiber runs. Each bridge contributes its fixed processing and lookup latency, a figure the vendor must state and that typically falls in the range of one to a few microseconds for a cut-through-capable device, plus the residual blocking from a preempted frame, bounded at roughly one microsecond by the 127-byte rule, plus the frame's own serialization on the outgoing port.
Summing three hops of those terms gives a worst case in the low tens of microseconds, comfortably inside a 500-microsecond cycle, with the largest single uncertainty being the endpoint software rather than the network. Two observations follow. First, the schedule must reserve a window wide enough for the accumulated jitter, not merely for the frame, or a frame that arrives a microsecond late waits an entire cycle. Second, the calculation is only as good as its assumptions: it presumes that no unscheduled talker can inject traffic into the protected class, which is precisely the assumption 802.1Qci exists to enforce. Without ingress policing the number above is an estimate of typical behavior rather than a bound.
What TSN Costs
TSN is frequently presented as a way to get determinism from commodity Ethernet. The commodity part deserves scrutiny, because the technology imposes real costs in three distinct areas.
Schedule Computation
Synthesizing gate control lists for a network of any size is computationally hard. Craciunas, Serna Oliver, Chmelík, and Steiner presented a formal treatment at the 2016 International Conference on Real-Time Networks and Systems that expresses the 802.1Qbv constraints for multi-hop switched networks as a satisfiability modulo theories problem and solves it with a general-purpose solver, together with an incremental approach based on a demand bound test that substantially improves scalability in the average case. The need for such machinery is itself the finding: the general problem admits no efficient exact algorithm, and the closely related no-wait packet scheduling formulation, in which frames may not be buffered between hops, has been shown to be NP-hard. Practical tools therefore rely on heuristics, on decomposition, and on restricting the problem, for instance by forcing all streams onto harmonic periods so that a single hyperperiod remains tractable. The operational consequence matters more than the theory: a schedule that took minutes to compute may take just as long to recompute when a machine is modified, and a network whose schedule cannot be regenerated on site is a network that cannot be maintained on site.
Hardware
The features are not implementable in software at the timescales involved. A bridge must have per-queue transmission gates driven by a clock disciplined to gPTP, hardware timestamping units on every port, sufficient ternary content-addressable memory or equivalent lookup capacity for per-stream identification, and preemption-capable media access controllers. An endpoint needs the same timestamping and, for scheduled transmission, a controller capable of launching a frame at a specified instant rather than when the driver gets around to it. On Linux the corresponding software interfaces exist in the form of the taprio and earliest transmit time queueing disciplines and the socket transmit-time option, but their timing quality depends entirely on whether the underlying controller implements launch time in hardware. A pure software implementation can be functionally correct and still miss every deadline.
Configuration Discipline
The most common failure of a TSN deployment is not a silicon limitation but a configuration drift. A schedule is computed against a topology; someone reroutes a cable during maintenance and the schedule silently no longer matches the paths. A stream is assigned to a priority code point; a virtual local area network change remaps priorities and the stream lands in an unscheduled queue. A redundant pair of paths is engineered to be disjoint; a later addition merges them at one switch and the redundancy becomes decorative, undetectable until latent error detection reports it or until the failure that it was meant to survive actually happens. TSN moves the determinism of the network from a property of the hardware to a property of the configuration, and configurations require the change control, version management, and post-change verification that engineering organizations reserve for source code.
Verification
Conformance testing establishes that a device implements the standard. It does not establish that a network meets its budget. The second requires instrumentation: hardware-timestamped capture at the endpoints under representative load, deliberate injection of the interfering traffic the budget assumed, and fault injection to confirm that redundancy behaves as designed. A latency histogram collected on a quiet network proves little, because the point of the exercise is the tail.
Where TSN Meets Other Domains
TSN operates at the bridging layer, which bounds its reach. Three adjacent efforts extend the idea, and a TSN design of any ambition touches at least one of them.
The IETF's Deterministic Networking working group addresses the layer-3 case, defining an architecture in RFC 8655 for bounded latency and low loss across routed networks, including networks that span more than one administrative domain. DetNet borrows the same conceptual apparatus as TSN, including packet replication and elimination, and is best understood as the wide-area counterpart rather than a competitor.
Mobile networks have been integrated through a bridge abstraction. In the 3GPP architecture from Release 16 onward, the 5G system presents itself to the TSN network as a logical bridge, with translator functions at the device side and the network side that carry gPTP across the radio interface and map quality-of-service flows onto TSN streams. This allows a mobile robot or a rotating machine to participate in a scheduled network without a cable, at the price of latency bounds set by the radio scheduler rather than by an Ethernet queue.
Within IEEE 802 itself, work continues on traffic engineering for bridged networks that include wireless technologies, alongside amendments in progress for shaper parameters under bursty traffic, priority-based flow control, source flow control, and refinements to cyclic queuing and forwarding and to frame replication. The toolbox is not finished, and a specification written today should name the amendments it depends on rather than referring to TSN generically.
Conclusion
Time-Sensitive Networking converts Ethernet from a best-effort medium into one whose worst-case behavior can be calculated, but it does so through independent mechanisms that must be selected and configured deliberately. Time comes from IEEE 802.1AS, whose profile of IEEE 1588 underpins every scheduled feature and whose 2020 revision added the multiple domains that make redundant timing possible. Bounded queueing comes from a choice among four shapers: 802.1Qbv for the tightest bounds at the highest configuration cost, 802.1Qav for media, 802.1Qch for a uniform bound with almost no per-stream state, and 802.1Qcr where synchronization is impractical. Frame preemption from 802.1Qbu and IEEE 802.3br removes the maximum-frame interference term that would otherwise dominate. Reliability comes from 802.1CB, which generalizes what PRP and HSR do for fixed topologies to arbitrary ones on a per-stream basis. Ingress policing from 802.1Qci is what makes any of the resulting numbers a bound rather than an estimate, and 802.1Qcc supplies the architecture through which the configuration is computed and delivered.
The profiles are what make the toolbox buildable. IEEE 802.1BA carries the audio-video bridging heritage from which the entire effort grew, IEC/IEEE 60802 published in June 2026 gives industrial automation a common substrate that competing protocol organizations have agreed to test against jointly, and IEEE 802.1DG-2025 does the same for in-vehicle networks. The honest summary of the technology is that TSN provides mechanisms, not guarantees. The guarantee is produced by an engineer who selects the mechanisms, computes the budget, proves the schedule, enforces the traffic contract at ingress, and then manages the resulting configuration with the discipline that its fragility demands. A TSN network is exactly as deterministic as its configuration, and no more.