Industry Thought Leadership

Operators have had techniques to ensure QoS for particular traffic types for many years. Network slicing builds on existing technologies such as the following:

• Differentiated Services (DiffServ): IETF RFC 2475 published in 1998.
• eDecor: A 3GPP Release 14 feature (an enhanced version of Release 13’s dedicated core network selection mechanism, Decor).

While these techniques can already be applied to 4G mobile networks, 5G will expand on them, enabling more automated, end-to-end network slicing. What distinguishes 5G network slicing is that it is not restricted to applying QoS solely in transport and the core, as with DiffServ. Rather, 5G network slicing has the ability to also apply QoS in the radio frequency (RF) domain. Unlike DiffServ, 5G slicing will be able to discriminate between the same types of traffic (Voice over Internet Protocol [VoIP], video, and Internet of Things [IoT]) coming from different tenants. 5G slicing will also, unlike DiffServ, be able to isolate specific traffic streams (e.g., for privacy and security reasons) to restrict them to certain areas of the network (e.g., a dedicated server).

In 4G, the basic granularity of QoS control is the Evolved Packet System (EPS) bearer. The service type is mapped to a specific EPS bearer, and all the data flows on that bearer are given a certain QoS guarantee. In 5G, the QoS model is based on QoS flows. A protocol data unit (PDU) session provides a connectivity service between a user equipment (UE) and the data network. The QoS flow is the finest granularity of QoS differentiation in the PDU session. User plane traffic with the same QoS flow receives the same traffic forwarding treatment (e.g., scheduling, admission threshold, etc.). 3GPP’s 5G QoS indicator defines for a given flow:

• Priority level: 11-66
• Packet delay budget: 5-300 ms • Packet error rate: 10-2 to 10-6
• Maximum data burst: 160-1,358 bytes

For each PDU session, the Network Slice Selection Assistance Information (S-NSSAI) is carried from the core to the radio access network (RAN). The RAN will use the slice identity to ensure consistency between the QoS and network slice, including the resource allocation and scheduling policy, etc. As such, the key difference between QoS and network slicing is that traditional QoS is only applied in the core network whereas with network slicing, this flow-based quality differentiation is carried all the way through to the RAN.

Once mature, network slicing should have much greater automation thanks to orchestration platforms such as Open Networking Automation Platform (ONAP; see here). This should enable network slicing to be delivered more cost-effectively, making it economic to provide network slicing-based services that today are limited to niche use cases.

In a recent Heavy Reading survey, we asked CSPs where they saw the value in network slicing. Surprisingly, the top response was cost reduction. Around 40% of respondents said it would positively affect revenue. Fifteen percent of respondents were sceptical that there was any quantifiable value.

Adopting network slicing rather than building dedicated networks for different service types would certainly generate a cost savings. But implementing network slicing is unlikely to lead to any significant cost savings compared with today’s one-size-fits-all network. Dedicated slices for service types could increase overall network efficiency. For example, an IoT slice for smart meters would not need the mobility and IP Multimedia Subsystem (IMS) capabilities of the network. But the cost savings potential seems marginal.

So where is the new revenue going to come from? The idea is that rather than simply selling buckets of bytes with a few service-level agreements (SLAs – for enterprise customers), mobile network operators (MNOs) will be able to market highly differentiated “slices” of network capacity. These must be carefully priced and positioned to make them more attractive to the enterprise than basic connectivity plans – yet more profitable for the operator. Organizations that might benefit from a dedicated slice include emergency services, healthcare, and industrial plants. Another obvious opportunity for network slicing is in the wholesale/MVNO market. Operators could offer network slices on a wholesale basis, allowing these must be carefully priced and positioned to make them more attractive to the enterprise than basic connectivity plans – yet more profitable for the operator. Organizations that might benefit from a dedicated slice include emergency services, healthcare, and industrial plants. Another obvious opportunity for network slicing is in the wholesale/MVNO market. Operators could offer network slices on a wholesale basis, allowing third parties to sell them on to enterprise users in addition to some value-added services. However, the risk here – like in the case of IoT – is that MNOs become relegated to dumb network slice vendors while the value-added services are captured by third parties.

Network slicing should enable operators to be more agile, launch customized services more quickly (e.g., for a music festival or sports tournament), and target smaller opportunities. Slicing enables isolation during service deployment and reduces interoperability testing, thereby enabling faster launches. However, the operator will need to develop an ecosystem of partners to exploit such short-lived or small opportunities.

In the initial phase of network slicing, operators are likely to launch a handful of slice types (e.g., eMBB, URLLC, and mMTC) with multiple tenants per slice. Over time, the number of slice types should increase and become more service specific (e.g., video gaming and smart meter connectivity). Eventually, we could see application-specific slicing (e.g., Netflix video streaming), although this could run into net neutrality restrictions in some countries. Vodafone UK’s chief technology officer (CTO), Scott Petty, recently commented that, "If net neutrality is applied, the whole premise of network slicing will fall apart."

It is even feasible to have customer-specific slices that are fully configurable via a portal. Enterprise customers could specify their necessary data rate, latency, reliability, and security. An automotive manufacturer might want a URLLC slice for autonomous vehicles, an eMBB slice for in-car entertainment, and a mMTC slice for vehicle diagnostics.

By moving away from the one-size-fits all approach of current networks, slicing should allow operators to be more creative in their service offerings. Slicing should maximize their revenue potential while still using the same underlying infrastructure.