“5G is here!” How do mobile transport providers get ready?
It is no news to anyone in our industry that 5G is the number one investment priority for MNOs — both for their initial and their long-term deployments. But if you are a mobile transport provider currently providing leased lines to an MNO, the impact on your business might be less clear. What kind of offers will be most attractive to your customer and what changes do you need to make to be ready for the 5G revolution?
A recap of the current 4G situation is illustrated in figure 1. The normal transport services you provide to an MNO are Ethernet virtual connections (EVCs). You likely deliver them using a network interface device located on the customer’s premises (CPE) that is connected to the eNB cell site router or gateway (CSR/CSG). You terminate the EVCs on a larger device that concentrates them, such as a mobile switching center (MSC/MTSO). The individual EVCs vary in bandwidth between 1GE and 10GE, and the MSC delivers the traffic to the customer’s central office (CO) router typically with n x 10GE interfaces.
As the transport provider, you probably define one EVC per eNB. Using IP/MPLS, the EVC may be implemented using virtual leased lines (VLL) and virtual private LAN service (VPLS), which are still the most commonly used services, although VPWS/VPLS E-VPN are rapidly being adopted. Other typical implementations include L2 services over rings, typically with G.8032v2, and MPLS-TP tunnels.
5G introduces two major architectural changes that will impact what you need to offer an MNO. First, there are changes in the 5G RAN. The gNB (the 5G version of the eNB) has three layers, as pictured in figure 2, the Radio Unit (RU), the Distributed Unit (DU) and the Centralized Unit (CU).
There are also changes to the packet core, which is now not necessarily centralized. MNOs will be able to distribute the peering points into more places closer to users (Distributed Sites) and keep some of them in the current central sites.
The 5G three-layer architecture can be broken up into fronthaul, midhaul and backhaul (see figure 2 above) and these will be the typical configurations:
- 5G Fronthaul will be eCPRI. MNOs will be requesting dark fiber or low-latency EVCs (100 µs one-way). RU-DU distance will be 10–20 km with n x 10 Gb/s or n x 25 Gb/s interfaces required.
- 5G Midhaul will occur when the DU and CU are in different sites and will require an EVC per connection with strict latency requirements (1–2 ms one-way), n x 10 Gb/s interfaces and a range of 100–200 km.
- 5G Backhaul will have the same distance requirement as in 4G and a more “relaxed” latency requirement in the range of 10-20 ms, but there will be a massive bandwidth increase, from n x 10 Gb/s up to 100 Gb/s.
With the higher density of 5G radios, you will see the following changes in the current requirements:
- More bandwidth: The most obvious changes are connectivity increases from 1GE to up to 25GE per RU and up to 10 times more bandwidth needed on the backhaul.
- More buffering: The new levels of bandwidth should not be handled by simply “throwing bandwidth at the problem”. Adequate buffering should be deployed at different layers of the network to accommodate the significantly more bursty traffic.
- Lower latency: This applies especially for fronthaul and midhaul where ultra-reliable low-latency connection (URLLC) services will be implemented.
There are several other aspects to 5G that you will need to consider when preparing your offers.
Capacity and interconnectivity
Besides the typical bandwidth growth, the biggest change with 5G is the 25GE interfaces on the RU. This will be translated into n x 10GE or n x 100GE interfaces towards the transport provider network, requiring n x 10 Gb/s and n x 100 Gb/s midhaul and backhaul services from the mobile transport provider.
The traffic characteristics will change with 5G. Traffic burstiness and increased traffic flows will require different treatment and you should be aware of the underlying applications being carried. For many network operators, traffic management as a platform differentiator is often overlooked. However, it is by far the largest contributor to the overall quality an end-user will experience (QoE). As a result, it is the single largest item that can drive operational value back to end-customers.
The anyhaul network must condition the traffic as follows:
- Differentiate between types of traffic priorities (e.g., voice/video, gaming, signaling, 3G/4G/5G best effort and high priority data)
- Absorb traffic bursts (deep buffering)
Conditioning anyhaul traffic requires a decision process to determine what portion of the received traffic is to be accepted and what portion is dropped. “Coloring” (e.g., marking traffic green, yellow or red) is commonly used as a method to designate the traffic as compliant (or not) to the contractual rate. When the CPE device provides ingress H-QoS with aggregate policers and egress shaping with H-QoS and deep buffers, a better and differentiated solution is provided. 5G anyhaul needs to provide tangible ways for an operator to not only derive strategic advantage but also use that advantage to drive down costs and increase end-user value.
Different types of traffic have different latency or buffering needs. Naturally, some traffic such as voice and video are delay and jitter sensitive and will not benefit from deep buffers. Traffic of this type, real-time traffic, requires priority scheduling in order to minimize delay and jitter. Real-time traffic must be exhaustively serviced above the other traffic flows.
New ultra-reliable, low latency communication (URLLC) applications, such as remote equipment control, will also need to be given top priority with shallow or no buffering.
Signaling and timing over packet flows are equally sensitive to those same variations in delay and the implications of unnecessary buffering can be significant. This is where buffering can impact the accuracy of time distribution affecting both OAM accuracy and the synchronization of any attached devices. Unnecessary delays to signaling can result in a loss of visibility of end-connected devices.
OAM implementation is nothing new and it is well documented in the MEF Mobile Backhaul implementation agreement (MEF22) that refers to standards that include Link OAM (IEEE 802.3ah), and Service OAM (both IEEE 802.1ag and ITU-T Y.1731).
With 5G bringing fast-changing architectures and traffic patterns, OAM tools will be critical to offer and assure new SLAs. External controllers will not just gather telemetry and network utilization information for reporting but, upon detecting congestion or latency problems, will use policies to proactively reroute traffic to new paths that meet the desired SLAs.
It’s expected that the CSR will provide built-in, redundant options for GNSS, SyncE/IEEE 1588v2 and BITS in case the base station does not include built-in GPS. In most cases, the MNO will have their own “synchronized” network and will not require transport providers to provide synchronization, as today. Nonetheless, you should be ready for this requirement to avoid a forklift in case “Synchronization as a Service” becomes a need of one of your MNO customers.
For 5G networks, high-bandwidth IPSec for L3 encryption at the MNO will be kept as today for 3G and 4G, particularly when relying on mobile transport providers for anyhaul. Going forward, MACSec will also play a major role for transport providers, because it provides line rate, low latency encryption and encrypts at L2 and above, including MPLS, IP and Multicast/BIER. Note that MACSec is hop-by-hop encryption.
MNOs are migrating to highly programmable and scalable cloud-native services architectures with network functions disaggregation to enable more flexible services deployment. Their network functions must be able to reliably communicate using multiple types of services over a common transport infrastructure. You must ensure that every new EVC can:
- Efficiently share IP transport resources without contention with business or residential services
- Maintain end-to-end connectivity for multiple types of services
- Be implemented faster
- Automatically re-route traffic based on congestion and/or delay, jitter and loss
- Avoid any service disruption, especially now when MNOs differentiate based on the fastest 5G network.
Automation technologies are emerging to meet these needs and fortunately they are compatible with, and build upon, existing network protocols:
- Segment Routing (SR-MPLS): Steers IP packets along a source-routed path, encoded as a set of instructions in the MPLS label stack, this end-to-end transport service offers deterministic QoS across the access network, WAN and DC
- SR-TE Policy/PCEP: A segment routing traffic engineering policy that can be configured statically and/or advertised in BGP/PCEP and is used by the SR global controller to program TE paths into head-end routers and switches
- BGP EVPN: BGP extensions (MP-BGP address family) to support the setup of L3 and L2, Ethernet-based VPNs, which provides the mechanism to interwork with legacy VPLS, VLL, G.8032 rings, but also, interwork with virtual network functions (VNFs) that can become reachable in customers’ VPNs, including service chaining.
All this needs to be done without losing sight of the current network; meaning, these new technologies MUST be able to interwork with the current network (such as inter-ring, inter-market interworking).
If you are a mobile transport provider, your world is going to get a whole lot more demanding with the arrival of 5G. Its 3-layer anyhaul architecture, CUPS and higher capacities will require much greater flexibility at the transport layer. SLAs will be highly variable and dynamic to match the new capabilities and features of the 5G network.
Share your thoughts on this topic by joining the Twitter discussion with @nokianetworks or @nokia using #IP #routing #Anyhaul #5G #interconnectivity