TSN Frame Preemption Meets Stringent Latency Requirements of 5G Fronthaul
By Avik Bhattacharya |
ADOPTION OF 5G GIVING BIRTH TO AN ETHERNET-BASED FRONTHAUL
The operators adopting 5G are interested in moving to flexible Cloud RAN (C-RAN) architecture that enables them to address different application requirements by locating storage and compute resources either at the base of the cell site or at centralized hubs hundreds of kilometers away. The connection in RAN infrastructure between the baseband unit (BBU) and remote radio head (RRH) is called the fronthaul. As new 5G use cases roll out, flexible fronthaul has become an essential ingredient for balancing the latency, throughput, and reliability demands of 5G applications. With 5G operators willing to place the BBU and the RRH in separate locations, the fronthaul is evolving over an Ethernet-based shared network that will need to carry the IQ radio data over a switched network.
WHAT DOES IT REALLY MEAN FOR THE NETWORK?
Latency is a very important characteristic of the fronthaul network. To understand why, let’s look at how the functionality splits are done between the distributed unit (DU) and the radio unit (RU). The IP-based user data flows from the core network to the bottom of the stack where we have the antenna. As we move from the IP to the Radio, the bandwidth requirement increases with more encapsulations being put on the data. The extra encapsulations are to provide redundancy or protection for errors, retransmissions, and the like.
At the same time, as we move down the stack from IP to Radio, we also have lower latency tolerance. For example, an IP packet is not really latency bound. But a radio clocking signal needs to be within a low latency limit. As per 3GPP standards for 5G, the network is designed with a higher-layer split and a lower-layer split of the network functions. The lower-layer split is where we separate the real-time data and the non-real-time data.
BUT CAN A SWITCHED NETWORK GUARANTEE THE LOW LATENCY THAT IS REQUIRED BY THE RADIO DATA?
The fronthaul network is a result of a lower-layer split that divides the radio stack between the DU and the RU. The IEEE 802.1CM standard defines the permissible latency values for the fronthaul traffic. Between the RU and the DU, the one-way latency is 100 microseconds - which means, if a fiber introduces 5 microseconds per kilometers, then this gives a budget of 20 kilometers. But wait, we also need to consider the delay introduced by the switching elements in the fronthaul!
The Time-Sensitive Networking (TSN) Working Group has been working for the last few years to achieve the same goal for low and deterministic latency but for automotive and industrial networks. One such TSN standard is the frame preemption mechanism (IEEE 802.1Qbu), which enables low-priority traffic to be interrupted by time-critical frames of higher priority. The 802.1CM recommends borrowing this concept from TSN and using the Frame preemption mechanism in the 5G fronthaul along with strict QoS priorities. The fronthaul traffic or the eCPRI user data traffic is treated as express and the other traffic present in the network is treated as preemptable. All the switching elements in the fronthaul network need to support the frame preemption capability to ensure end-to-end latency requirements.
THE CHALLENGE FOR THE NETWORK ENGINEERS IS TO ENSURE IT REALLY WORKS IN PRACTICE
Frame preemption (IEEE 802.1Qbu) is a completely new concept for the telecom switches and, at the same time, it is complex in nature. Preempting a frame while it is in transmission at the Phy layer is a hardware implementation. I, as the product manager of Keysight for the TSN test solutions, am working with many fronthaul switch vendors and operators who are adopting the fronthaul concept. The top two questions every network engineer asks are:
- How can I validate that the switch is performing frame preemption - fragmentation & reassembly?
- How do I ensure stringent latency criteria of the express traffic is met end-to-end at a network level? What happens in the presence of other interfering traffic?
WELL, THE ONLY ANSWER IS TO VALIDATE, BUT HOW?
To answer the above questions, one needs to validate - both the expected scenarios and the not expected ones. Of course, to validate a lower-layer technology like frame preemption, we need test methods that are well thought out and capable test tools that can execute the test steps. For example – to test the behavior of a switch in the presence of out-of-order fragments in the network, you need to emulate the scenario using a test tool. Your test tools should provide control over individual fragments that it transmits, send them out of order, alter their checksum, etc. While granular control over fragments is at the one end of the spectrum, you need the ability to measure the latency of express and preemptable traffic on the other end.
Keysight’s IxNetwork frame preemption solution provides an excellent mix of features to cater to both ends of the spectrum. A fronthaul validation engineer working in one of the telecom giants told me recently – “there are traffic generators which claim to generate preempted traffic but there is absolutely no control over the frames”. To him, those tools seem “useless in validating a complex technology like frame preemption”. We, at Keysight, used our vast experience of working on TSN technologies from the industrial and automotive markets for the last 5 years to design the IxNetwork frame preemption solution for 5G fronthaul running on Novus SFP28 25GE interfaces. Also, IxNetwork now has a TSN wizard that makes configuring a frame preemption validation scenario just a matter of clicks. That’s the reason that leading vendors in the fronthaul switch market are using IxNetwork to validate their switches and ensuring end-to-end latency in their network design.