End-to-End Network Slicing: Opportunities and Challenges for Operators – a View from BT

Andy Corston-Petrie (andy.petrie@bt.com), Principal Researcher, Converged Networks Research Lab, BT TSO

IEEE Softwarization, December 2017

 

For more than a year, BT has been actively researching Network Slicing as a key capability within the 5G landscape. We set out by identifying the key research questions to explore, and have previously identified a number of strategic priorities for operators, spanning technical, commercial and operational domains. In this article, we will describe what we believe those strategic priorities are, with a special emphasis on the challenges and opportunities around end to end network slicing across multiple domains, technologies and vendors.  

This article aims to give an update on BT Research’s activities on Network Slicing, and the challenges and opportunities that we have identified.

Figure 1

Figure 1

We start with a familiar picture in the 5G world.  The graphic in figure 1 gives a good illustration of how different services will have varying metrics and Key Performance Indicators (KPIs), and not just at the extreme peaks of ultra-high bandwidth, ultra-low latency, and massive Machine Type Communication (mMTC) values that typically grab the 5G headlines. The stringent needs of next generation applications and services will drive the different combinations of these values, and these will define our network slices.

Figure 2

Figure 2

To meet these differing service needs, there are architectural options for deployment.

As illustrated in figure 2, an operator could deploy a single multi-service network, with a shared physical layer supporting a shared functional layer. However, there are two main challenges facing operators. Trying to engineer the network to support as many next-generation services as possible may be very inefficient, in terms of the resources and performance measures required. Alternatively, the operator could end up compromising for practical reasons, which may mean the performance does not meet the high demands of the services.

Alternatively, the operator could deploy separate physical sub-networks, each with their own physical resource layer and functional layer on top of that. Each subnet could be designed and optimized for a particular demanding service, but the cost of deploying discrete subnets is going to be a challenge.

Or the operator could deploy discrete virtual networks, built on one shared physical resource layer, with multiple functional layers dedicated to each application or service type. These are our slices. 

So, let us take a quick look at the reasons that operators like ourselves are interested in slicing – what are the goals?

Figure 3

Figure 3

Firstly – what we refer to as “Agility Without Disruption” (Figure 3).  This means giving the operator an opportunity to significantly reduce service launch cycle time, and stamp out new services rapidly without disturbing existing services and traffic. Secondly, the ability to cope with conflicting functional requirements while minimizing over-engineering and resource wastage, which would benefit CAPEX, and avoiding the need to deploy multiple networks, which would otherwise impact OPEX. Thirdly, a set of capabilities that can offer tailored, optimized and guaranteed service measures for different applications, customers and sectors.  And finally, there’s likely to be a trade-off between the higher service revenues envisaged against the cost of efficient operability and complexity. Given the scale of the 5G ambition across industry, we believe all of these things need to be addressed for operators to maximize their return while delivering the exacting services that their customers demand.

Here in BT Labs, we have been looking at the economics of slicing at scale; at methods of slicing in different technical domains, for example Software Defined Networking (SDN) in the backhaul network, and Network Function Virtualization (NFV) in the mobile core; at the challenges of orchestration across multiple domains to be able to deliver partial or full end-to-end slices; federated network slicing models, future roaming models, fixed and mobile networks and so on. We have also been heavily involved in standards and various groups, and working with a number of partner organizations to explore the issues.

So what have we learned?  From our studies on the economics of slicing, we came up with a number of initial conclusions. Firstly, the benefits of slicing grow as the number of service types that you are trying to launch grows. In other words, there is economy of scale in slicing. Secondly, it’s key that the rest of the organization gears up to support this ambition – development, delivery, marketing, operations and so on – otherwise the operator will not be able to exploit the technology commercially. Thirdly, significant investment is needed in automation to be able to do this at scale, otherwise the complexity and operational challenges are likely to mount up.

Figure 4

Figure 4

Overall, the end-to-end picture is likely to be complex, as illustrated in Figure 4. Areas requiring further investigation include how to slice the radio and backhaul domains, whether slices are made up of sub-slices, and whether there will be partial slices as well as end-to-end slices. There may also be slices for services that span administrative, security or even regulatory domains. Operators will also need to design practical solutions for exposing slices to customers and their operations, for example through the MANagement and Operation (MANO) stack and integrated into the Operational/Business Support System (OSS/BSS) domain, or real-time functional interfaces.

Beyond that, more advanced topics include automation, machine learning, self-healing, self-optimising, real-time monitoring, and so on.

Efficient network slicing will require a multi-domain orchestration capability that can reserve and allocate virtual resources for slices in multiple domains. The orchestrator needs to be smart and dynamic – to obtain the right resources at the right time in each domain, and to handle scenarios where the available resources are suboptimal. Slices could also span multiple operators, multiple vendors and several technology domains. This architecture and capability are going to be key to avoiding slow, expensive, manual tasks in resource coordination during slice delivery.

In summary, network slicing shows promise as a key enabler for operators to design and deploy next generation services. It is still a very active research area for us, our partners, and the wider industry.  In particular, we would hope to see significant progress in capabilities such as multi-domain orchestration, operability and assurance, so that slicing truly can start to be considered for rapid deployment in the near future. The next couple of years will be crucial in exploring the opportunities and challenges faced by operators in this space.

 


 

Andy Corston-PetrieAndy Corston-Petrie has over 25 years of experience in the telecommunications industry.  A Physics graduate from the University of St Andrews, Andy has held a variety of positions at BT, including software development, system testing and programme delivery, and spent 10 years as the lead service designer of BT's IPX solutions.

Andy is Principal Researcher in the Converged Networks Research Lab, which is part of BT's Research and Innovation group at BT Labs in Suffolk.  His research work is focussed on 5G technologies and Network Slicing, as well as related concepts, such as NFV, SDN and Edge Computing.

 

Editor:

Neil DaviesNeil Davies is an expert in resolving the practical and theoretical challenges of large scale distributed and high-performance computing. He is a computer scientist, mathematician and hands-on software developer who builds both rigorously engineered working systems and scalable demonstrators of new computing and networking concepts. His interests center around scalability effects in large distributed systems, their operational quality, and how to manage their degradation gracefully under saturation and in adverse operational conditions. This has lead to recent work with Ofcom on scalability and traffic management in national infrastructures.

Throughout his 20-year career at the University of Bristol he was involved with early developments in networking, its protocols and their implementations. During this time he collaborated with organizations such as NATS, Nuclear Electric, HSE, ST Microelectronics and CERN on issues relating to scalable performance and operational safety. He was also technical lead on several large EU Framework collaborations relating to high performance switching.  Mentoring PhD candidates is a particular interest; Neil has worked with CERN students on the performance aspects of data acquisition for the ATLAS experiment, and has ongoing collaborative relationships with other institutions.

 

 


 

Subscribe to IEEE Softwarization

Join our free SDN Technical Community and receive IEEE Softwarization.

Subscribe Now

 


Article Contributions Welcomed

Download IEEE Softwarization Editorial Guidelines for Authors (PDF, 122 KB)

If you wish to have an article considered for publication, please contact the Managing Editor at sdn-editor@ieee.org.

 


Past Issues

November 2018

March 2018

January 2018

December 2017

September 2017

July 2017

May 2017

March 2017

January 2017

November 2016

September 2016

July 2016

May 2016

March 2016

January 2016

November 2015


IEEE Softwarization Editorial Board

Laurent Ciavaglia, Editor-in-Chief
Mohamed Faten Zhani, Managing Editor
TBD, Deputy Managing Editor
Syed Hassan Ahmed
Dr. J. Amudhavel
Francesco Benedetto
Korhan Cengiz
Noel Crespi
Neil Davies
Eliezer Dekel
Eileen Healy
Chris Hrivnak
Atta ur Rehman Khan
Marie-Paule Odini
Shashikant Patil
Kostas Pentikousis
Luca Prete
Muhammad Maaz Rehan
Mubashir Rehmani
Stefano Salsano
Elio Salvadori
Nadir Shah
Alexandros Stavdas
Jose Verger