Most network slicing schemes in effect today are static and based on implementing specialized service surveillance. Two years ago, most solutions I had seen were in their infancy and varied quite a bit in their approach. Few were “close to the network” solutions and depended upon external OSS (provisioning, inventory, planning and design, and service assurance system) and even BSS functions. They mostly were what I called painting the slices onto the network. In this technique, slice creation means explicitly engineering a set of (or portion of a set of) network resources for the desired characteristics and then monitoring them according to their specific KPIs. Although major failures were to be mitigated against by backup plans, more subtle SLA violations for the slices were handled via manual re-engineering, with a long lifecycle. There was little dynamic behavior exhibited in most cases.

In 2021 and 2022, vendors made great strides in their slicing solutions as slice design and provisioning was added, with substantial automation in cases where the underlying domain controllers were in place. Assurance functions became more sophisticated, with vendors adding latency and other QoS functions to their slicing solutions. Inventory systems, completely refactored or written anew by non-traditional inventory players, became real-time repositories of the state of the network, feeding both the provisioning and assurance part of slicing operations. To feed the provisioning process, slice design functions were written, usually using predefined parameterized slice templates. All of this was done using cloud-native software architecture and delivered on multi-cloud infrastructure with CI/CD processes.

There is little in the way, however, of deployed commercial slicing offers, although the industry has seen many POCs. ACG Research anticipates that the commercial market for vendors’ slicing offerings, and CSPs’ offerings of sliced services, will begin in earnest in late 2022 and accelerate in 2023 with CSP implementations of a small number of dozens of slices implemented on any one network. These numbers will grow as the operations are improved, scaled up, and automated.

In the future, we also expect that additional functionality will be implemented in the network elements to provide a finer degree of control for network slicing. We also expect that the current GMSA list of standard slicing types will be greatly enhanced.

Network slicing: techniques

It has always been possible to ensure a customer’s QoS guarantees are not violated by dedicating equipment to that customer, or selected services for that customer. But the idea of slicing is to have as much of a common network as possible with capacity within the network resources dedicated to certain slices, with known and configurable QoS parameters for the slices, sub-slices, and services. There are two somewhat different techniques for doing this as shown in Figure 1 on the next page. The first is Isolation, how the resources are set aside in the network. The second is Adaptability, how dynamic is the slice (as in how much of the slice operations are automated, allowing them to be quickly changed to meet changing customer requirements or adapted to meet changing network conditions).

Isolation of slice resources

How are the resources set aside in the shared network? Just done statically by the engineering department painting the slices onto the network, with nothing special being done other than monitoring more stringent QoS parameters? Or more sophisticated techniques in the network

Design, engineer and monitor slices

The basic way of doing slicing is via the way that network resources have always been dedicated to individual customers or services. In this basic methodology, the CSP “paints the network” with the slice identifiers in the external OSS systems. This requires no new functions in the equipment, nor any specialized functions in the OSS, domain control, or cross-domain orchestration systems. The resources are flagged in the inventory system as belonging to a particular slice while the service assurance system monitors the QoS parameters, perhaps with more stringent requirements than normal. If SLA violations occur, then the engineering department is notified, and remedial action is planned and put in effect. This can, however, take days or weeks.