5G-TRANSFORMER glossary

This information capsule collects the key terminology used in 5G-TRANSFORMER. The definitions of terms are structured according to their area, such as virtualization related or business related. The terms defined here are the most relevant ones, especially those that have different definitions by various standardization developing organizations.

For more details about the 5G-TRANSFORMER terminology, please check D1.2 (5G-TRANSFORMER Initial System Design, May 2018).

1.1 General Terms

Data model: A mapping of the contents of an information model into a form that is specific to a particular type of data store or repository. A “data model” is basically the rendering of an information model according to a specific set of mechanisms for representing, organizing, storing and handling data. It has three parts:

A collection of data structures such as lists, tables, relations, etc.
A collection of operations that can be applied to the structures such as retrieval, update, summation, etc.
A collection of integrity rules that define the legal states (set of values) or changes of state (operations on values).

Information model (IM): An abstraction and representation of the entities in a managed environment, their properties, attributes and operations, and the way that they relate to each other. It is independent of any specific repository, software usage, protocol, or platform.

Policy: Policy can be defined from two perspectives:

A definite goal, course or method of action to guide and determine present and future decisions. “Policies” are implemented or executed within a particular context (such as policies defined within a business unit).
Policies as a set of rules to administer, manage, and control access to network resources.

NOTE: These two views are not contradictory since individual rules may be defined in support of business goals.

Service: The behavior or functionality provided by a network, network element or host. To completely specify a “service”, one must define the “functions to be performed …, the information required … to perform these functions, and the information made available by the element to other elements of the system”. Policy can be used to configure a “service” in a network or on a network element/host, invoke its functionality, and/or coordinate services in an interdomain or end-to-end environment.

1.2 Network function virtualization related

The central concepts around network function virtualization and network services are based on the definitions of ETSI NFV.

Network Function (NF): functional block within a network infrastructure that has well-defined external interfaces and well-defined functional behaviour.

Network Service (NFV-NS): composition of Network Functions and defined by its functional and behavioural specification.

NOTE: “The Network Service contributes to the behaviour of the higher layer service, which is characterized by at least performance, dependability, and security specifications. The end-to-end network service behaviour is the result of the combination of the individual network function behaviours as well as the behaviours of the network infrastructure composition mechanism.”

NOTE: A network service can be seen as a set of VNFs or PNFs, connected by VLs as defined in a VNFFG.

Network Service Descriptor (NSD): template that describes the deployment of a Network Service including service topology (constituent VNFs and the relationships between them, Virtual Links, VNF Forwarding Graphs) as well as Network Service characteristics such as SLAs and any other artefacts necessary for the Network Service on-boarding and lifecycle management of its instances.

NOTE: The NSD includes a number of deployment flavors, each referencing deployment flavors of all or a subset of the NFV-NS’s constituent VNFs and Virtual Links. The NSD also provides a list of pointers to the descriptors of its constituent VNFs (i.e. VNFDs) and additional information on the connectivity between them together with the traffic forwarding rules.

Network Service Instance (NFV-NSI): refers to an instance of a network service (NFV-NS).

NOTE: In 5G-TRANSFORMER, the process for instantiating a Network Service instance is initiated from 5GT-VS by sending a request to the 5GT-SO. This request typically contains a pointer to a NSD, a flavor selector and additional input parameters (e.g., IP addresses to be assigned to some of the network functions) and constraints (e.g. location where to deploy all or some of the network functions). The flavor mechanism not only enables selecting a subset of VNFs and virtual links to be instantiated but also the actual flavor for each of the selected objects and the number of instances to be created for each selected VNF.

NFVI as a Service (NFVIaaS): The tenant (e.g., a vertical or an MVNO) is offered a virtual infrastructure including associated resources (networking/computing/storage) under its full control in which it can deploy and manage its own NFV network services on top of it. It is assumed that the vertical will deploy its own MANO stack. This is probably the most usual service consumed by M(V)NOs, given that they have the knowledge and need to customize their communication service offering to their own customers. Resources could be virtual cores, storage, virtual nodes and links, etc.

NOTE: The tenant can deploy and connect VMs on these resources under its own control.

NOTE: NFVIaaS includes the provision of network slices or network slice subnets as a service.

Network Service as a Service (NSaaS): Provide to a tenant the possibility to define and instantiate a network service.

NF forwarding graph (NF FG): graph of logical links connecting NF nodes for the purpose of describing traffic flow between these network functions.

Physical Application (PA): implementation of a VA via a tightly coupled software and hardware system.

NOTE: analogous to PNF.

NOTE: may include devices such as cameras, smart city sensors, etc.

Physical Network Function (PNF): implementation of a NF via a tightly coupled software and hardware system.

VA Forwarding Graph (VA FG): Forwarding graph among VA, VNF, PA, PNF nodes.

Virtual Application (VA): more general term for a piece of software which can be loaded into a Virtual Machine.

Virtual link (VL): set of connection points along with the connectivity relationship between them and any associated target performance metrics (e.g. bandwidth, latency, QoS).

Virtualised Network Function (VNF): implementation of an NF that can be deployed on a Network Function Virtualisation Infrastructure.

Virtualised Network Function Component (VNFC): internal component of a VNF providing a defined sub-set of that VNF’s functionality, with the main characteristic that a single instance of this component maps 1:1 against a single Virtualisation Container.

Virtualised Network Function Descriptor (VNFD): configuration template that describes a VNF in terms of its deployment and operational behavior, and is used in the process of VNF on-boarding and managing the lifecycle of a VNF instance.

VNF Forwarding Graph (VNF FG): NF forwarding graph where at least one node is a VNF.

VS as a Service (VSaaS): Provide to a vertical the possibility to define and instantiate a vertical service.

NOTE: similar to NSaaS, with vertical instead of network service.

1.3 Network slice related

Network slice (NS): A network slice is a complete logical network with specific services offered to customers over a shared compute, storage and network infrastructure. E.g. a network operator can build a network slice including an Access Network (AN) and a Core Network (CN) to enable communication services.

Network slice instance (NSI): a set of network functions and the resources for these network functions which are arranged and configured, forming a complete logical network to meet certain network characteristics.

NOTE: A Network slice instance is the realization of a network slice.

NOTE: In ETSI NFV parlance a network slice instance would typically be deployed as a NFV Network Service instance (NFV-NSI). Different slices can map to instances of the same type of NFV-NS with different deployment flavors or instances of different types of NFV-NS. In an NFV framework, creating a network slice will typically involve filling a NSD and requesting the NFV Orchestrator to instantiate a NFV-NS according to the contents of its NSD and selected deployment flavor.

Network slice subnet instance (NSSI): a set of network functions and the resources for these network functions which are arranged and configured to form a logical network (sub-network).

NOTE:

A NSI may include one or more NSSIs, which can include one or more VNFs or PNFs.
A NSSI can be shared by multiple NSIs.
Both NSI and NSSI can be mapped to a nested NFV Network Service.

1.4 Vertical service related

Vertical: 5G-TRANSFORMER stakeholder belonging to a specific industry or group of customers and consuming 5G-TRANSFORMER services. MVNOs are considered a special type of vertical in 5G-TRANSFORMER.

NOTE: The existence of network slices is transparent to the vertical and it is fully under the control of the 5G-TRANSFORMER Service Provider how to handle them, including, for instance, mapping services into network slices.

Vertical Service (VS): From a business perspective, it is a service focused on a specific industry or group of customers with specialized needs (e.g., automotive services, entertainment services, e-health services, industry 4.0). The 5G-TRANSFORMER system is designed to fulfil the requirements of vertical services coming from the 5G-TRANSFORMER Service consumers. M(V)NO requests are also handled as a special kind of vertical service.

From a technical point of view, it is a composition of general functions as well as network functions and defined by its functional and behavioural specification.

NOTE: The vertical service behaviour is the result of the combination of the individual VA behaviours as well as the behaviours of the network infrastructure composition mechanism.

NOTE: A vertical service is similar to a network service, but provides more general functionality than network functionality.

Vertical Service Blueprint (VSB): A parameterized version of a VSD, where parameters have to be provided to provide a complete VSD, which is ready to be instantiated.

NOTE: There can be a wide range of parameters. The parameters can be used to express requirements of the vertical service, but also management related parameters such as file locations of virtual machine images or the priority of a service. A subset of parameters to express requirements are: Bitrate of VAs and the connecting links, round-trip time among two VAs, geographical area to be covered by the vertical service.

Vertical Service Descriptor (VSD): A description of the deployment of a vertical service including service topology (constituent VAs and the relationships between them, Virtual Links, VNF Forwarding Graphs) as well as vertical service characteristics such as SLAs and any other artefacts necessary for the vertical service on-boarding and lifecycle management of its instances.

NOTE: A VSD may still contain instance specific parameters to be provided at instantiation time. This is similar to parameters provided at instantiation time of VNFs.

1.5 Multi-access edge computing related

The central concepts around multi-access edge computing are based on the definitions of ETSI MEC and recent draft integrating NFV and MEC. Following the renaming of mobile edge computing to multi-access edge computing, the definitions have been changed accordingly.

Multi-access edge application (MEA): application that can be instantiated on a multi-access edge host within the multi-access edge system and can potentially provide or consume multi-access edge services.

Multiple-access Edge Application Orchestrator (MEAO): It has the same functions as MEO, excepting that it should use the NFVO to instantiate the virtual resources for the MEA as well as for the MEP.

Multiple-access Edge Host (MEC Host): It provides the virtualization environment to run MEC applications, while it interacts with the mobile network entities, via the MEP platform, to provide MES and offload data to MEA.

Multiple-access Edge Orchestrator (MEO): The MEO is in charge of the orchestration and the instantiation of MEA.

Multiple-access Edge Platform Manager (MEPM): It is in charge of the life-cycle management of the deployed MEA. The MEPM is in charge of the MEP configuration, such as the MEC application authorization, the traffic type need to be offloaded to the MEC application, DNS redirection, etc.

Multiple-access Edge Platform Manager – NFV (MEPM-V): The virtualized version of the MEPM delegates the LCM of MEA to one or more VNFMs, and keeps the MEP configuration.

Multi-access edge platform (MEP): collection of functionality that is required to run multi-access edge applications on a specific multi-access edge host virtualisation infrastructure and to enable them to provide and consume multi-access edge services, and that can provide itself a number of multi-access edge services.

Multi-access edge service (MES): service provided via the multi-access edge platform either by the multi-access edge platform itself or by a multi-access edge application.

1.6 Business logic/stakeholder related

5G-TRANSFORMER Service (TS): Services offered by a 5G-TRANSFORMER Service Provider (TSP) to 5G-TRANSFORMER Service Consumers, such as verticals, through the 5GT-VS northbound interface or to other TSPs through the east-west interface (E/WBI). As for the former, it includes the following four types of services: 5G-TRANSFORMER Managed Vertical Service (TMVS), 5G-TRANSFORMER Unmanaged Vertical Service (TUVS), NSaaS, and NFVIaaS. Additionally, TSPs can also consume TSs offered by peering TSPs. This interaction is done through the east-west interface (E/WBI) of 5GT-SOs, and so, it is not a slice-related interaction but an NFV network service-related one. There are two types of services offered in this way: federated services and federated resources. A service offered by a 5G-TRANSFORMER Service Provider can include a bundle of such services.

5G-TRANSFORMER Managed Vertical Service (TMVS): Vertical services that are fully deployed and managed by the TSP and consumed as such by the vertical (i.e., without any interface available to modify the service logic, but only for getting operational information, at most).

5G-TRANSFORMER Unmanaged Vertical Service (TUVS): Vertical services that are deployed by the TSP (i.e., instantiating VNFs and their connectivity), but their logic is partly or fully managed by the vertical. This includes the configuration of VNF internals to control the logic of the vertical services at service level. In this case, the lifecycle management of the NFV-NS and its VNFs are still retained by the TSP.

5G-TRANSFORMER Service Consumer (TSC): Uses 5G-TRANSFORMER services that are offered by a 5G-TRANSFORMER Service Provider. Note that a 5G-TRANSFORMER Service Provider can also be a TSC of another service provider.

5G-TRANSFORMER Service Provider (TSP): Provides 5G-TRANSFORMER services. Designs, builds and operates its 5G-TRANSFORMER services.

5G-TRANSFORMER Mobile Transport and Computing Platform Operator (TMOP): In charge of orchestrating resources, potentially from multiple virtual infrastructure providers (VISP) and offered to the TSP. In that sense, it acts as an aggregator of resources. The virtual infrastructure features transport and computing resources, potentially including those of datacentre service providers with which the TMOP has an agreement. Designs, builds, and operates the computing and network aggregated virtual infrastructure services. It has agreements with Virtualization Infrastructure Service Providers (VISPs).

Virtualization Infrastructure Service Provider (VISP): Provides virtualized infrastructure services. Designs, builds and operates its virtualization infrastructure(s). VISP-T provides virtual transport infrastructure and VISP-C virtual computing infrastructure.

Data Centre Service Provider (DCSP)[1]: Provides data centre services. Designs, builds and operates its data centres.

1.7 5G-TRANSFORMER specific terms

Abstracted Resource/ Resource abstraction: Limited description of a resource with intention to hide certain parameters (such as quantity, vendors, location of the resource, etc.) and secure enough to be shared with other administrative domains.

Abstracted Service/ Service abstraction: Limited description of a service with intention to hide certain parameters (such as used resources, virtual links, interconnections etc.) and secure enough to be shared with other administrative domains.

Administrative domain: is a collection of resources operated by a single organization. The internal structure (collection of resources) operates with significant degree of mutual trust among them. The domain’s resources interoperate with other administrative domains in a mutually suspicious manner and they are viewed as a cohesive entity from the outside.

Available Resources for Federation: Set of resources offered by a provider domain under pre-agreed terms and conditions; available resources potentially to be used by a consumer domain, with certain pre-agreed terms and conditions.

Available Services for Federation: Available services offered by a provider domain to other potential consumer domains, under pre-agreed terms and conditions.

Consumer domain: Administrative domain that demands resources or services from other administrative domains.

Federated Resources: Resources managed by a consumer domain, but owned by a provider domain (operator). The consumer domain is allowed (by the provider domain) to manage and use the resources based on pre-agreed terms and conditions (SLAs). In this case, the consumer TSP uses NFV (abstracted) virtual resources offered by the peer TSP. This may be the case when an end-to-end NFVIaaS service is built by combining virtual resources belonging to multiple TSP administrative domains.

Federated Services: Services managed by a consumer domain, but owned by a provider domain. The consumer domain is allowed (by the provider domain) to manage and use the services based on pre-agreed terms and conditions (SLAs). In this case, the consumer TSP uses NFV network services offered by the peer TSP. This may be the case when an end-to-end service is split into constituent services that are deployed in multiple TSP administrative domains.

Federation is a mechanism for integrating multiple administrative domains at different granularity into a unified open platform where the federated resources and/or services can trust each other at a certain degree.

Mobile transport and computing platform (5GT-MTP): A component of the 5G-TRANSFORMER system.

Local Repository: Database (in an administrative domain) that holds information for available resources for federation, catalogue of services/abstracted services, provided by other provider domains.

Provider domain: Administrative domain that offers resources or services to other administrative domains.

Service catalogue: Composed set of services and/or service abstractions offered by a provider domain to other potential consumer domains using mutual taxonomy and agreed usage terms (SLAs). The composed service catalogue is shared among pre-agreed peering administrative domains.

Service Orchestrator (5GT-SO): A component of the 5G-TRANSFORMER system.

Technology domain: is a collection of resources that are part of a single technology (system) and belong to a single administrative domain. The internal structure is defined and operated according to the technology definitions and standards. One or more technology domains can be part of an administrative domain.

Vertical Slicer (5GT-VS): A component of the 5G-TRANSFORMER system.

NOTE: The prefix ‘5GT’ of the acronym is used to avoid a clash with ‘VS’ standing for vertical service.

[1] The difference between DCSP and VISP-C is that the former is closer to the raw resources (host servers) offering simple services of raw resource consumption. Additionally, these resources are located in a centralized location (datacentre). The latter offers access to a variety of virtual infrastructure resources created by aggregating multiple technology domains and by making them accessible through a single API for all of them. For instance, VISP-C may offer not only centralized datacentre resources, but also distributed computing resources available throughout the network.