XClose

Institute of Communications and Connected Systems

Home
Menu

5G Service Support End-to-End functions

This page is part of the output from the Institute of Communications and Connected Systems that  presents aspects, components, and testbeds which are part of the challenge for 5G infrastructures.

In particular, this page covers the 5G Service Support End-to-End functions, required for dealing with the full path end-to-end issues and aspects:

5. On-demand Slice and VIM creation
6. On-demand topology aggregation
7. Multi-domain aspects & facilities
8. Service Provider to Service Provider interaction


Acronyms

The following acronyms are used throughout these pages:

DC                   Data Center
IA                     Infrastructure Adaptor
NFVI                Network Function Virtualization Instantiator
MCE                Management and Control Entity
NIM                 Network Infrastructure Manager
PoP                 Point of Presence
REST              Representational State Transfer
SDN                Software Defined Networking
SFC                 Service Function Chaining
VIM                  Virtual Infrastructure Manager
VNF                 Virtual Network Function
WIM                 Wide Area Network Infrastructure Manager
VM                   Virtual Machine


5. On-demand Slice and VIM creation

This section describes the creation of a DC Slice and it's associated VIM, and how doing this in an on-demand way is important. One of the main issues that is often discussed in the use of shared cloud and network infrastructures is how resources and services can be isolated from each other, for security purposes or for resource utilisation purposes. Having a slice and VIM, which can be allocated per service, ensures such attributes.

Our approach to this, particularly in the context of DCs, is to allocate independent slices of a DC to each customer.  In this way, customers will never share servers, and the worry of VMs of one customer interacting or spying on another customer will be eliminated. Also, the issue of one customer's VM consuming all the resources and starving other customer's VMs is also ameliorated to some extent.

Each of these slices will be allocated and de-allocated in an on-demand fashion.  A customer can interact with a Slice Manager, and request a new slice.  The resulting slice will be isolated from the other slices. Furthermore, each slice will get its own VIM or NIM, and not have management as part of shared one.

The following figure presents how the resources of a DC are isolated from each other, and how a Slice Manager is involved in such a process.

The functions are part of the UCL Slice Controller open source soft infrastructure testbed. The Slice Controller can be downloaded from our UCL EE CISP repository http://clayfour.ee.ucl.ac.uk/slice/.

References

18.  Alex Galis, Chih-Lin I "Towards 5G Network Slicing - Motivations and Challenges" - IEEE 5G Tech Focus, Volume 1, Number 1, March 2017- http://5g.ieee.org/tech-focus/march-2017#networkslicing


6. On-demand topology aggregation

This section describes the aggregation of various slices into a single topology and how doing this in an on-demand way is important. Once we have at set of various slices which have been created by interacting with various suppliers who are able to create Network slices and DC slices, these slices need to be managed and orchestrated together. Each slice will have its own slice management component — a VIM for DC slice, and a NIM for a Network slice.

We suggest that the best approach is to glue these slices and their associated managers into one addressable abstraction — a virtual topology — made up of network and DC parts. This aggregation of sub-network and sub-DC slices has to also be done in an on-demand manner as the slices are all allocated at run-time, and their addresses and attributes will be set on-the-fly by the infrastructure supplier.

The resulting topology presents an abstraction over the underlying system that can be viewed as a single entity, and addressed as a single entity.  It allows other sub-systems of the 5G environment to have a handle on a conceptual element, rather than just a collection of separate parts.

References

19.  Matsubara, D., Egawa, T., Nishinaga, N., Kafle, V. P., Shin, M. K., Galis, A.,  -"Toward Future Networks: A Viewpoint from ITU-T" - IEEE Communications Magazine, March 2013, Vol. 51, No. 3, Pages: 112 — 118; ISSN 0163-6804


7. Multi-domain aspects & facilities

This section describes issues of multi-domain operation addressing core, edge, mobile networks as well as end-to-end aspects, per operator or multi operator.In the 5G landscape different providers can build up a federated infrastructure for the exchange of different types of resources and the delivery of end-to-end services to their customers. As a consequence, the definition of a standard interoperable interface among Multi-Domain Orchestrators and/or between Multi-Domain Orchestrator and Domain Orchestrator(s) is of crucial importance to allow the extension of service provisioning beyond a single administrative domain (i.e., inter-operators).

One relevant aspect is the joint orchestration of compute, storage and network resources across administrative domain boundaries, in a common service offering. The component of the 5G testbed will comply with APIs that will convey information about the deployment of slices and network functions to be interchanged among administrative domains. Apart from that, a detailed view of the boundaries and differences between Control and Management will be necessary in order to properly interchange information among domains, and between providers and customers.

That control relationship between domains can present different models, like peer-to-peer or hierarchical. These control relationships imply a different location of the administrative boundaries (East-West, North-South), and can be investigated using the 5G testbed in order to identify a proper mapping between the 5G components interfaces and ETSI NFV MANO and thus ensure rapid adoption and fast standardisation and interoperability.

References

20.  W. Koong Chai, A. Galis, M. Charalambides, G. Pavlou "Federation of Future Internet Networks"- NOMS2010/ ManFI 2010- Management of Future Internet 2010, 19-23 April 2010 Osaka, Japan http://www.manfi.org/2010/

21.  R. Guerzoni, I. Vaishnavi, D. Perez, A. Galis, F. Tusa, P. Monti, A. Sgambelluri, G. Biczók, B. Sonkoly, L. Toka, A. Ramos, J. Melián, O. Dugeon, F. Cugini, B. Martini, P. Iovanna, G. Giuliani, R. Figueiredo, L. M. Contreras-Murillo, C. J. Bernardos, C. Santana, R. Szabo —" Analysis of End-to-End Multi-Domain Management and Orchestration Frameworks for Software Defined Infrastructures: an Architectural Survey"- August 2016 Wiley Transactions on Emerging Telecommunications Technologies; http://onlinelibrary.wiley.com/journal/10.1002/(ISSN)2161-3915

22.  R. Guerzoni, D. Perez Caparros, P. Monti, G. Giuliani, J. Melian, C. J. Bernardos Cano, G. Biczók, B. Sonkoly, F. Tusa, A. Galis, I. Vaishnavi1, F. Ubaldi, A. Sgambelluri, C. Santana, R. Szabo- "Multi-domain Orchestration and Management of Software Defined Infrastructures: a Bottom-Up Approach", IEEE EuCNC 2016, 27-30 June 3016 Athens, Greece

23.  Bernardos, C. J, Csaba, S., Dugeon, O., Galis, A., Morris, D., and Szabo, R., — "5G Exchange (5GEx) — Multi-domain Orchestration for Software Defined Infrastructures for Networks, Clouds and Services" — European Conference on Networks and Communications, 29 June - 2 July 2015, http://eucnc.eu

24.  A. Sgambelluri, A. Milani, J. Czentye, J. Melian, Wint Y. Poe, F. Tusa, O. Gonzalez de dios, B. Sonkoly, M. Gharbaoui, F. Paolucci, E. Maini, G. Giuliani, A. Ramos, P. Monti, L. M. Contreras Murillo, I. Vaishnavi, C. J. Bernardos Cano and Róbert Szabó. A Multi-Operator Network Service Orchestration Prototype: The 5G Exchange. Optical Fiber Communication Conference 2017, Los Angeles, California United States, 19—23 March 2017, http://www.ofcconference.org/en-us/home/

25.  A. Sgambelluri, F. Tusa, M. Gharbaoui, E. Maini, L. Toka, J. Martín Pérez, F. Paolucci, B. Martini, Wint Yi Poe, J. Melian, A. Muhammad, A. Ramos, O. González de Dios, B. Sonkoly, P. Monti, I. Vaishnavi, C. J. Bernardos, R. Szabo. Orchestration of Network Services Across Multiple Operators: The 5G Exchange Prototype. EuCNC 2017, 12-15 June 2017, Oulu, Finland, http://www.eucnc.eu.


8. Service Provider to Service Provider interaction

This section describes a model of interaction between two or more MANO Service Providers used to orchestrate different network segments or different domains of a large partitioned NFVi. One can consider a scenario of a company composed by one or more local offices, such as a head office and multiple telecom service provision offices.

Users in the local offices want to deploy network services composed of several VNFs, but local offices cannot leverage on a dedicated NFVi, or the NFVi they can leverage cannot meet the requirements of the requested service deployment. Nonetheless, local offices offer to their users a MANO to orchestrate their service instances. In order to deploy this services, the local office MANO has to interact with other partition of the company. The service deployment requests might be sent to the head office or to other local offices which may have a VIM.

Most of the times, the NFVi able to meet the requirements of local office would be orchestrated by one or more telecom service provider orchestrators in the company. In our model this scenario is realised by considering a north-south interface between orchestrator, where each north-bound orchestrator interact with its south-bound counterpart as it would do with a VIM. The interaction is mediated by an abstraction layer[link] that allows exposing the orchestrator capabilities in a compliant way with a VIM interface, using a relevant orchestrator wrapper.

By means of this abstraction, this simple scenario can be extended and generalised by considering a generic tree model where each orchestrator can leverage other orchestrators to access resources it can't directly orchestrate, or to leverage software and services provided by other segments of the company.

 As a proof of concept, we designed and developed an implementation of Service Platform to Service Platform (SP to SP) interaction, that is described in the following points:

  • Two Service Platforms cooperates for rapid and dynamic service provisioning in a NFV environment.
  • The company has segmented its infrastructure in order to meet the demands of separate organisation/departments. It deploys a hierarchy of service platforms that need to collaborate in order to deploy NFV end-to-end services across the network.
  • A generic SP/orchestrator can leverage on a segment of NFVi or on other SP to instantiate functions and services.
  • The orchestrator (5GEx SP) at higher level operates over a lightweight VIM domain (VLSP) and over a SONATA SP
  • REST interface between 5GEx domain adapter and SONATA Gatekeeper
  • SONATA SP operates on top of another partition of the NFVi, using VLSP VIM
  • Upgraded Infrastructure Adapter drives creation of VIM slices interacting with the Slice Manager
  • End-to-end service composed of four VNFs, on-boarded as services in SONATA Service Platform and exposed as Domain Capabilities to the 5GEx orchestrator.

References

26. http://www.sonata-nfv.eu/content/5g-service-platform-service-platform-in...

 

Authors 

Profile picture of Alex Galis
Prof Alex Galis
Professorial Research Associate

Institute of Communications and Connected Systems
Roberts Building
University College London
WC1E 7JE


Profile picture of Francesco Tusa
Dr Francesco Tusa
Research Associate

Institute of Communications and Connected Systems
Roberts Building
University College London
WC1E 7JE


Profile picture of Stuart Clayman
Dr Stuart Clayman
Senior Research Associate

Institute of Communications and Connected Systems
Roberts Building
University College London
WC1E 7JE