Introduction to Network Slicing: Not Completely New, But Different

Ultra-low-latency networks have received significant press in the last few years. These specialty networks are used by high-frequency trading firms as they seek to gain competitive advantages from shaving milliseconds from their transaction times[1]. These require specialized equipment engineered and installed in distinctive ways, then operated with specialized teams. Remote haptics, virtual and enhanced reality, remote surgery, real-time industrial control, and connected autonomous vehicles are often cited as the next wave of services that will demand ultra-low latencies. As these nascent services are brought to market, the importance of decreasing these high network costs increases greatly.

But other, competing specialty network requirements are also envisioned with hugely different characteristics:

• The Internet of Things (IoT), with billions of connected devices, many of which will have low bandwidth requirements (and loose latency requirements) and revenues of the order of $1 per month will demand a network that has low capex and opex.
• Mobile broadband users are increasingly consuming more bandwidth that will require vast network capacity increases with only modest growth in cost.

To meet these challenges, the concept of network slicing has been introduced. Although the standards admit the possibility of 256 slice types (and nearly 16 million different slices within each slice type), ACG Research believes four types have significant near-term commercial potential:

• Ultra-reliable low-latency communications (URLLC slice)
• Massive machine type communications (mMTC slice)
• Enhanced mobile broadband (eMBB slice)
• Customer-specific slice(s): dedicated slices for a customer or group of customers

In network slicing, the physical (and virtualized) network infrastructure is shared. Network slicing is achieved by a combination of careful network engineering, advanced network elements (both physical and virtual) that are slice-aware[2], and operations processes for resource and service provisioning as well as service assurance (including security) that ensure proper quality of service (QoS) to meet the specified service level agreements (SLAs). Of course, the business systems must also support customers in researching and ordering these services and provide billing for them.

Many of these concepts are not new; they have been intrinsic to enterprise services such as IP-VPNs, SD-WANs, low-latency trading networks, and other special networks arrangements created by CSPs for their enterprise customers. What is new is the consolidation of these networks into a set of common resources that can maximally be shared with other network services.

Network Slicing Will Touch Everything

With network slicing affecting all parts of the network, systems, and operations, the implications are immense, requiring cooperation among the different domains. Here is ACG Research’s preliminary perspectives of the implications and our current view of network slicing in our various research areas:

OSS/BSS

Operations Support Systems (OSS) and Business Support Systems (BSS) usually lag network evolution. In the case of network slicing, they are being updated now in advance of specialized network infrastructure features for slicing. This provides either:

• hard slicing of the networks by network engineering allocating network resources to the individual slices, inventorying them as such, and then monitoring them for the required QoS via service assurance systems.
• operational slicing, where the network resources involved in a slice are not at all dedicated but are simply inventoried as being part of the slice and then monitored for proper QoS by the service assurance systems.

As network slicing evolves, the OSS systems will need to evolve to take into account the multiple slices in the network, with separate engineering, service provisioning of the slices, and service assurance of the specific QoS parameters of the slices across the various network domains and potentially across CSPs’ networks.

Similarly, BSS systems must be extended to support the new services and their QoS guarantees. They also will need new inter-carrier operational interfaces (either direct or through exchanges) to support slices that go across CSPs’ networks.

Transport Infrastructure

PON, DOCSIS, packet transport, and optical infrastructures are not currently slice-aware. Packet networks are starting to incorporate slicing features, working with the domain controllers from each vendor. Segment routing in packet networks looks like it will be an important technology for network slicing. The ability to support slicing at Layer 1 (by partitioning the bandwidth of the transport link in line with slice requirements) will be a new capability not generally present today that will help slices achieve their goals. ACG Research expects that vendors will increasingly differentiate themselves through slice-aware features controlled by the vendors’ domain control systems. Many will do this in advance of standards, as usual.

Domain Control & Orchestration

Domain control systems[3] will be updated to handle the slice requirements in the future. Cross domain orchestration of slicing provisioning, assurance, management, and optimization will require coordination across the network from end to end. The extra complexity will be daunting unless copious automation is applied.

SD-WAN

SD-WANsare already an example of operational slicing of the network and may also include some hard-sliced dedicated network resources. Network slicing will most probably be integrated into the SD-WAN technologies over time as they support more applications and functions.

Mobile Network Infrastructure

The RAN, xHaul, and the 5G core network will need to be slice-aware[4]. As in transport infrastructure, new features and functions will be provided by vendors as they attempt to differentiate themselves. 3GPP Release 16 is expected to extend network slicing to the RAN, although the benefits are not known to justify the added RAN complexity. Network slicing Open RAN (O-RAN) arrangements may be needed before RAN slicing becomes a reality.

Cloud and Data Center Networks

Network functions in CSPs’ deployments often include elements running in a data center environment that need to meet service delivery requirements for an offering. Border controllers and network gateways of various types are but two examples of those nodes. Having physical switches and routers, and their virtualized counterparts support network slicing in CSPs’ data centers will, over time, be an important part of realizing slices overall.

Key Market Questions on Network Slicing and ACG’s Current Views

• How many slices? and How many slice types?
  The prevailing opinion is that about a dozen-and-a-half slices for the foreseeable future. Ericsson and others say thousands, one for each customer (and maybe for each service type for each customer). Standards admit all of these possibilities, and the market has not yet figured out how to handle it.
  Our Take: Tier 1s will slice within regions of their networks first, slicing into eMBB, mMTC, and URLLC, plus slices for major customers. For the next few years, most will slice their networks into less than two dozen slices. Vendors will provide Slicing-as-a-Service NaaS solutions for smaller CSPs that want to offer slices to their enterprise customers for competitive reasons but are not convinced that the business benefits yet justify major network upgrades.
• Will the operational complexity of running these sliced networks make it uneconomic?Complexitywill come from the matrix of [# of domains] x [# of slices]; each cell of that matrix needs to be engineered, created, monitored, secured, and tuned.
  Our Take: This complex arrangement will require extensive automation. Our DCO research program is in the middle of this. TCO studies will be key. We expect that the complexity of operations will limit the number of slices employed for the next few years.
• How do you handle a network that is not entirely SDN and slice-enabled?
  Slicing only makes sense if it is end-to-end. Yet slice-enabling the entire network, DCO systems, and OSS/BSS systems will be a massive undertaking.
  Our Take: True end-to-end slicing will be limited to specific use cases for a long time. eMBB will be the default for most 5G mobile networks. We will see some limited hard-sliced URLLC for special cases. Narrow-band IoT is a cost issue and will be handled mostly with low priority settings on packet-based legacy equipment.

• How will slices work across carriers/multi-cloud?
  Standard service offerings across multiple carriers and across multiple clouds (for NFV and advanced services) will be a huge problem.
  Our Take: We will not see this for several years. Exchanges and web-scale companies will probably be the first to offer the end-to-end slices.
• How much will slicing be extended into the data center? Across CSPs? Into private networks?
  The extension of the slices into the data centers extends the concept outside the normal bounds of telecoms’ standards. This will require functions that cross the normal network and IT operational boundaries.
  Our Take: Extensions into the CSPs’ clouds will naturally occur as the virtualization of the network functions evolves and expands. Extensions into private clouds to scale will be more difficult and take longer. Extensions into private networks will occur only in the long term.
• How does slicing fit into disaggregated architectures such as O-RAN?
  O-RAN and other standards are being defined and implemented now without slicing.
  Our Take: O-RAN will continue to deploy without slicing, which will be added slowly.
• How close are we to a fully sliced network?
  Our Take: We are just at the beginning of a ten-year journey.

Conclusion

Network slicing is still in its infancy but looks to be an important part of the enterprise-focused differentiated services of the future. ACG Research analysts will be following its evolution in our individual programs as the network functions, domain controllers and cross domain orchestrators, and the OSS and BSS systems evolve to support network slicing.