Transport Networks for 5G Networks
Same, same, but different
We hear lots of discussion about the fundamental changes to the fronthaul and backhaul transport networks as we move towards 5G mobile networks. However, in my opinion, much remains the same, with some key advances made to support changes in radio technology and provide increased service support and flexibility.
So what is happening with fronthaul?
Fronthaul was first used in 4G to allow baseband units (BBUs) to be remotely located from the remote radio heads (RRH) using the CPRI interface. This allowed BBU functionality to be pooled to provide cost savings and increased flexibility. The downside of 4G fronthaul is that the CPRI interface is a point to point interface that was designed for very short distances i.e. connecting RRHs at the top of the antennas to BBUs at the bottom of the antennas. As such no effort was made in optimizing CPRI for the transmission distances involved in making pooled BBUs viable. This means 4G fronthaul networks need to be very high bandwidth (100s of Mbit/s) with very low latency (less than 75µs).
Things have moved on in 5G and centralized, pooled, resources are now a key part of the C-RAN architecture. Also to achieve the anticipated 5G connection speeds, a MIMO approach is used which requires each radio units (RUs) to communicate with multiple other RUs with very low latency.
Hence much thought has gone into how to optimize the fronthaul interface to meet these needs. The main reason the bit rate on the CPRI interface is so high is the digitization of the baseband RF signal before its transmission through the fronthaul.
In 5G, the BBU has now evolved to become the digital unit (DU). It fulfills several functions, some with strict real-time constraints, others that include software-based protocols:
- Layer 1: Real-time digital RF processing, alarms & error handling (OAM), and error correction (FEC). For the time being, this layer is difficult to virtualize.
- Layers 2 and 3: MAC/RLC and interface protocol software. These layers could run as virtual network functions (VNFs) in the NFV cloud.
Relocating the layer 1 functionality in the RU (using the IEEE option 6 interface), reduces the required bandwidth, reduces latency demands to a few milliseconds and allows Ethernet to be used for fronthaul transport. Relocating the layer 2 functionality in the RU (using the IEEE option 2 interface) further reduces latency to 100s of milliseconds.
However, it is not as simple as just putting more and more functionality in the RU to reduce the bandwidth and latency demands on the fronthaul interface. Increased functionality in the RU reduces the flexibility of the centralized RAN architecture and the benefits gained from pooling DUs. In addition, using a higher-layer split introduces greater latency in the RU and certain proposed 5G applications such as augmented/virtual reality, real-time gaming and autonomous cars are very sensitive to the latency between the RU and the DU. A number of operators are talking about the option 6 split being a good compromise.
And what about backhaul?
If 5G is to deliver on its potential when it is eventually deployed, service providers and vendors alike need to start to understanding the impact of these fundamental changes today.
However like TechXLR8 itself, 5G is extremely complex has a huge number of stakeholders each of which believe they own parts of the story and at the same time are reliant on its success. So the ecosystems being tested must involve all of these stakeholders; from applications and DevOps through to the radio access network and the transmission network.
Given this need, TechXLR8 is a vision of the telecoms network future. With the services and development environments becoming fundamental components of the story.
What does this mean for today’s networks?
There has been much talk about mobile backhaul with discussions mainly centred on Network Slicing, with SDN, NFV and orchestration all being a key enablers for network slicing.
So why all this talk about network slicing?
So far, mobile networks have been optimized for phones, however in 5G they need to support mobile broadband services, massive IoT, and mission-critical services. Each of these services has different requirements in terms of mobility, security, policy control, latency, availability, bandwidth, etc.
It is not cost effective to build a dedicated network for each type of service. Neither is it cost effective to build a single physical network that is able to support all the services by meeting the most onerous requirements from each service.
The solution is Network slicing. This approach allows multiple logical networks (slices) to be created over a single physical network, with each slice built to address a set of service behaviours, e.g. security, latency, availability, bandwidth, etc. By definition, a slice can support multiple services as long as they have the same service behaviours. NFV is important to network slicing as it allows compute and storage to be added to the network when and where it is required by a service. SDN provides the ability to add capacity and connectivity in reatime, so as services move around the network, after all it is a mobile network, capacity and connectivity can follow the services.
Service orchestration is key to making network slicing to operate end-to-end across the entire mobile network. The orchestrator is able to understand the service requirements and translate these, in realtime, into the network requirements for each part of the network i.e. RU, DU, fronthaul, backhaul and Core.
The impact on the backhaul network, is that it must be able to provide the network to support the slices as defined by the service orchestrator. This is nothing new for IP transport, it has supported virtual private networks (VPNs) each with different performance characteristics for over a decade now. NFV although more recent, has been deployed in mainstream networks for the last couple of years. The change is decoupling the control plane from the data plane to allow centralised control of the network from a centralised controller and/or orchestrator.
Same, same but different?
Same: The transport network is still not part of the Mobile Network Operators (MNOs) core business and as such the business model for transport in 5G networks remains the same as it has always been. Although the days when it was just dumb, high capacity, point to point pipes are now long gone. For transport, MNOs will employ a mix of build their own network and network leased from wholesalers, with the decision based purely on commercial and operational constraints.
Same: Backhaul needs to support network slicing, however, in the main, this is utilising functionality already present in the cell site routers and IP equipment. Fronthaul moves from a point to point, to a many to many and needs to support the much higher data rates. However, the bandwidth and latency requirements may actually become less onerous.
But Different: For 5G to become truly service orientated, network slicing with service orchestration must be used to take advantage of the agility already provided by transport networks.