Architecture and Internal Processes
The proposed Network Slice Manager internal architecture is shown in the following figure. The Network Slice Manager is a Service Platform (SP) functional block that interacts with OSS (Operations Support Systems) and is responsible to access the SP MANO APIs for NS control.
The Network Slice Manager is a consumer of the REST APIs exposed by the MANO framework (reference point Os-Ma-nfvo 1) and the Infrastructure Abstraction (IA). Within a Network Slice Manager, one can identify two main functions:
- The first function is responsible for assigning services and applications to network slices and for managing the lifecycle of these slices. We will call it the Slice Lifecycle Manager
- The second function is responsible for mapping network slices to NSs. We will call it the Slice2NS Mapper
The Slice Lifecycle Manager is responsible for the entire lifecycle management of the created network slice instance, until it is terminated. Subsequent lifecycle events are likely to have an impact on the lifecycle of the underlying NSs, but not systematically.
The Slice Lifecycle Manager function is responsible for the definition and update of Network Slice Templates (NST). If a customer facing service needs to be assigned to an existing NST, it can request a NST update. If not, a novel NST, might be created.
NSTs are then converted by the Slice2NS mapper into NSDs and flavours. Once the NSD has been on-boarded, a slice instantiation request can be triggered, resulting in an NS instantiation request with the appropriate flavour identifier being sent to the NSO.
SLM is responsible for interacting with SP Repositories and Catalogues.
The Slice2NS Mapper functionality has to maintain an association between NST and NSDs identifiers, as well as an association between slice identifiers and NS instance identifiers. In next releases, it might also deal with the required combination/integration/concatenation of NSs.
This behaviour might involve automatic generation of a new NSD, which might be explored in future releases.
Slice2NS Mapper is responsible for interacting with SP MANO Framework.
The SM is the service platform new component, responsible to manage the life cycle of Network Slices. The on-boarded NSTs are stored in the Catalogue after previous validation. The Slice template on-boarding workflow is depicted in follwing figure. Depending on the validation level to be performed, the Catalogue could be also involved, to verify whether the involved NFV building blocks (NSs) are available.
Once a Network Slice Template (NST) is on-boarded, multiple Network Slice Instances (NSI) can be created using this template. The Network Slice instantiation triggers the instantiation of the list of NSs defined in the NST, which are used as building blocks to compose the NSI. The multiple NSs may need to be combined to form a meaningful network/service.
OSS is the entity that usually triggers the Network Slice instantiation, although it may also be triggered automatically (autonomous behaviour). The NSI creation workflow is depicted in the next figure.
NOTE: This page describes the instantiation procedure in a very simple way. For more detailed information, go to the Detailed Instantiation Flow webpage.
This component is an internal module of SONATA and so, it offers its features through the central SONATA module, the Gatekeeper. To understand how the communication between this two modules work when a network slice is instantiated, please reffer to the "Asynchronous Communication with the GTK" page.
[1] ETSI European Telecommunications Standards Institute. ETSI GS NFV-SOL003. Website,July 2017.