If you ask five different customers what they expect from their customer service provider (CSP), you will most likely get five different answers. Customers have different expectations of what their CSP can provide, and fortunately, with network slicing, CSPs now have more flexibility in how they can meet those customers’ demands.
Network slicing is one of the key technologies enabled with 5G networks. Network slicing uses network sharing to allow telcos to provide an independent logical network to each user to better guarantee the QoS that the user needs. 3GPP included network slicing as a standard for 5G to allow telcos and CSPs to share a network with a common infrastructure and create logical networks. A shared infrastructure allows the provider to segment off needs for different businesses like defined network resources, QoS and security policies.
There are multiple slice types called slice service type (SST) standardized by 3GPP:
- eMBB – enhanced mobile broadband
- mMTC – massive machine type communication
- URLLC – ultra-reliable low latency communication
- V2X – vehicle to everything and everything to vehicles
- HMTC – high-performance machine type communications
There is a possibility to use optional and nonstandard slice types, also called slice differentiator (SD), but these are organization specific.
Network slicing can be used in multiple scenarios to provide the correct bandwidth, throughput, latency, reliability and connection density required for each use case. Some examples of how network slicing can be used include:
- Smart agriculture: Sensor devices can be used to communicate the moisture, fertilization and nutrition levels to a farmer through a central hub to help the farmer know the status of the crop remotely. For this type of monitoring, packets with small payloads are sent every few seconds and latency is not a concern; however, there will be a large number of connections. For this scenario and other Internet of Things (IoT) use cases, mMTC slices will be most the suitable slice type.
- Real-time applications: Many scenarios, like robot-controlled machines, AR/VR and industrial automation, need networks with high reliability and low latency. To address the needs of real-time applications, a network slice with the type URLLC can be applied. URLLC is optimized for environments where low latency is crucial and the source and destination are close to each other.
- Self-driving vehicles: For full automated vehicles to work, there is the need for vehicle-to-vehicle or vehicle-to-all-devices communications. Autonomous vehicles will need to communicate well with other sources like another vehicle, lidar or traffic lights. Network slice of type V2X is designed for vehicles and was specifically created to help the automotive industry.
Implementation
Network slicing can be a powerful tool for CSPs and telcos; however, network slicing cannot be rolled out overnight. Planning, network upgrades and configuration changes are needed to support all that network slicing has to offer. Fortunately, the implementation can be done in phases to simplify rollout and ease cost.
Phase 1 – Preconfigured slicing
Providers create pre-defined slices based on expected capacity and the forecast of the application usage. In this phase, telcos define the characteristics of the network slice based on the expected traffic types. When setting up this type of network slicing, a telco needs to understand the NF (network function) and its requirements and to implement the network slicing in a way optimized for the specific traffic type. For example, a telco might need to support the V2X protocol to allow smart cars to communicate. V2X is latency-sensitive and needs to be highly accurate. If the telco also supports web browsing, these applications typically do not demand high throughput or have stringent latency requirements. If the telco supports both protocols, the telco can set up network V2X network slicing designated for V2X that has QoS parameters optimized for automated car use cases. The CSP could then set up an eMBB standard network slice with characteristics like capacity and support for a large number of users that can be used for web browsing applications. In this scenario, each network element, such as core, RAN and transport, will have different requests for the different network slices.
Phase 2 – On-demand
For phase 2, networking slicing happens on demand. With on-demand network slicing, different network slices can be created as new protocols and needs arise. On-demand network slicing handles multiple varieties of network slices with distinctive characteristics and allows the telco to support new applications as the need arises. For example, if a service provider creates a network for the transport domain, network slices are created accordingly to fit the requirements of that specific domain. With on-demand network slicing, new slices can be created as the network grows and different applications come online.
Phase 3 – Tenant-based
Implementation happens on a tenant basis. With tenant-based network slicing, a deeper level of network slicing happens based on tenants and specific customer requirements. To continue the example from phase 2 above, with tenant-based slicing, slices are created for a particular customer in the transport domain giving even more granular control to each customer. The slices in phase 3 will be ephemeral and just used for the duration of the communication session.
Multi-tenancy
Network slicing involves splitting the radio access into several end-to-end virtual networks. One of the ways these virtual networks can be created is through the use of multi-tenancy. Multi-tenancy can be used when a telco wants to share network resources, such as infrastructure (IaaS), software (SaaS) or platform (PaaS), among different parties. A multi-tenant architecture is based on central administration, involves a common code application and is based on operating common instance(s) of applications for multiple tenants. In addition, it also secures private data for each tenant from other tenants using the same resources.
With multi-tenancy, all tenants share the compute, storage and network resources but these resources are segmented to provide security and access restrictions. The resources can also be allocated to properly service the different network requirements of each tenant. The tenants can use various network slices, which are bound by a set of network policies and security rules to best fit their networking requirements. The use of the appropriate network slice provides desired throughput, latency and security to the respective tenants. For example, if a CSP needs to serve multiple customers, each with a different set of requirements, the CSP can use the same physical networking setup and create different network slices for each customer. Each network slice will be configured with the required QoS.
Network slicing uses multi-tenancy to provide ready-made network capability and can be shared between the tenants by adding multiple subnets to the network slice. For example, some networks need lower latency to serve their network functions like CUPS and UPF, and some other networks may demand higher bandwidth. Each requirement can be addressed by each network slice in the same physical environment. By sharing the network resources, CSPs can reduce CAPEX (capital expenditure) and OPEX (operational expenditure) to gain huge advantages with lower entry costs and lower recurring costs.
To achieve the benefits of network slicing, tenants and network slices must work together in cloud environments as shown in the diagram below.
The diagram shows how tenants can access their respective network slices. In this example multiple tenants are shown accessing their respective network slice and a single tenant can be see accessing multiple network slices.
As another example, assume a CSP provides network services to different vendors, such as industrial, hospital and transport.
Network slices created for industrial will be accessed by the tenant’s company offices, factories and workshops. For this use case, multiple tenants access multiple network slices. Different slices would be created for the hospital and transport customers so that each tenant within those customer’s domains could use the appropriate slice. No two sectors can talk to each other to achieve isolation. All these configurations are scalable and dynamic and can grow as the customer demand grows.
Summary and next steps
Network slicing is an exciting new option to allow CSPs to share scare resources with multiple customers. However, not all networks are ready to support network slicing and not all CSPs have the internal resources to deploy it.
If you are ready to use the power of network slicing but are not sure where to start, VMware Professional Services would love to help. Please visit our website to learn about more about VMware Professional Services and how we can help you evolve your network.
