User mobility and spatio-temporal variations in content popularity make the end-to-end deployment and undisrupted operation of IP-based mobile video streaming services, such as IPTV and Video-on-Demand (VoD), very complicated. In order to maintain a high Quality of Experience (QoE) for mobile clients, the common practice is to use Content Delivery Networks (CDNs), which are deployed on geographically distributed infrastructure typically provided by Communication Service Providers (CSPs), such as Mobile Network Operators (MNOs) in 5G scenarios. Caching servers are deployed on Multi-access Edge Computing (MEC) nodes close to end-users, in order to offload the core network from high-throughput streams. In such environments, monitored metrics on network performance at various levels can provide valuable insights for network adjustments in terms of resource usage. The ETSI MEC Architecture Framework supports the exchange of geo-based services that can feed such network adaptation mechanisms, which in turn optimize content delivery, enhancing service continuity and avoiding interruptions. However, the dimensioning and coverage footprint of a specific CDN provider often appears insufficient to address the aforementioned cases of service demand fluctuations, motivating the inclusion and consideration of alternative CDN resources in such systems.
The vCDN use case that we present in this article focuses on the use of 3rd party edge resources in a 5G System in situation of congestion or saturation of edge resources. In particular, it illustrates how the 5GZORRO platform can enable the automated extension of virtual Content Delivery Network (vCDN) services across multi-party compute, storage, and network resources of a 5G System in response to resource exhaustion in a CSP’s management domain. The validation and demonstration is built on the 5GZORRO prototype and ICOM’s commercial CDN solution, i.e. fs|cdn™ Anywhere. fs|cdn™ Anywhere is an end-to-end CDN solution that enables the seamless integration of IPTV and value-added interactive services into the operator’s back-office OSS/BSS and external Over-The-Top (OTT) content systems. Especially for the case of mobile clients, fs|cdn™ Anywhere adopts HTTP Live Streaming (HLS) and Dynamic Adaptive Streaming over HTTP (MPEG-DASH) protocols and creates a hierarchical (tree-like) topology of HTTP servers (e.g. content caches) to emulate a multicast delivery tree. These content caches are placed at key locations in a CSP’s network and allow access to all CDN subscribers.
The demonstrated scenario is shown in Figure 1. In this setup, both the central and edge CDN servers are hosted on 5G Barcelona’s infrastructure. The central CDN server includes various virtualized software modules that are deployed as Virtual Network Functions (VNFs). Also, the software module for Edge Cache is deployed on the Edge server as a VNF through its orchestration layer. This way, the core CDN components are close to the edge ones and all are placed on the same local network.
In this scenario, a CDN service provider leases a network slice instance from a CSP that includes performance guarantees in certain areas of the network. An emulator tool is running to generate virtual traffic in this cache. Additionally, a data pipeline is activated that continuously extracts application metrics and feeds them to the appropriate 5GZORRO platform components for storage and analysis.
The metric is then retrieved by Intelligent SLA Breach Predictor (ISBP) and used for its prediction model, which is already trained with an existing data set. At some point, the predicted value exceeds the defined threshold and an alert is generated indicating that the CDN edge server located on the CSP edge is about to become overloaded.
As a result, an advanced auto-scaling policy triggers the resource discovery process, which aims to identify potentially usable 3rd party edge compute resources. The discovery process identifies candidate product offers and rates them based on how well they satisfy the offer request as well as on profile information related to the resource (e.g., trust properties, pricing, etc.). After selecting the highest rated offer, the CSP orders it from the Marketplace. In the final stage, the network slice is extended to the 3rd party infrastructure. This includes installing the service components on the new resources.
After the slice extension, the Central CDN services include the new CDN edge server in their tables, so that some of the user requests will be assigned to that server. When executing the use case demo at 5G Barcelona testbed, it was verified that requests are sent to both edge servers, according to an algorithm applied for sharing the traffic between available Edge Caches. This is expressed in Figure 2, which shows the screen of a single user. The user receives content from both edge servers seamlessly.
5GZORRO orchestration mechanisms involved in the Use Case
In previous article we outlined the main features that are necessary for realising the 5GZORRO envisioned scenarios about pervasive vCDN services. Here we describe the concrete 5GZORRO modules that have been developed and successfully tested for zero-touch network and service management capabilities in multi-domain environments.
Intelligent Slice and Service Management (ISSM)
ISSM focuses on the automated management of secured cross-domain slices and services within them. It is therefore responsible for enforcing business transactions both at the system level by interacting with NSSO and with alternative slicing technologies that may be developed in the future, as well as by managing business transaction contexts across the 5GZORRO platform, enabling a principled, repeatable, controlled, and reliable interaction between the multiple components of the platform to implement a specific business flow.
ISSM consists of three modules:
• ISSM Workflow Manager (ISSM-WFM): responsible for executing the orchestration workflow
• ISSM-MEC: handles the deployment of 5G slices natively on Kubernetes (K8s) in a multi-cluster environment
• ISSM-Optimizer (ISSM-O): optimizes cost- efficiency and cost- trustworthiness tradeoffs of services and network slices
It should be noted that ISSM components are logically centralized only for ISSM-WFM and ISSM-MEC and are in fact distributed and symmetric. ISSM-O is a centralized platform component, due to its role as a cross-domain planner.
Management and Orchestration Layer
Regarding the subsystem of the 5GZORRO Platform dedicated to the management and orchestration of services and slices, the set of services offered is mainly oriented towards internal consumption by other elements of the platform and not by the 5GZORRO stakeholders themselves. In this sense, such a set of modules offers functionalities related to resource management and monitoring, e-licensing management, as well as to control a network slice and service orchestration within a stakeholder’s domain. These functions are available at the higher and more abstract levels of the 5GZORRO platform, such as ISSM, which exploits them to build services and slices based on an intelligent composition of the available resources.
Figure 3 shows the modules of MANO that belong to the Zero-touch Management and Orchestration logical subsystem of the 5GZORRO platform. The dashed arrows indicate distinct interactions between modules.
The objective of eLM is to enable reliable tracking of the usage of purchased software components/xNFs, in real time, providing proof of usage so that vendors/owners can materialize revenues related to licensing costs. It is designed to seamlessly integrate stakeholders into the 5GZORRO ecosystem who either want to offer and consume xNFs or to offer their virtualized infrastructure for xNF orchestration and deployment, resulting in a production level telecommunication framework that will track the utilization of xNFs that are commercially available through the 5GZORRO Marketplace.
xRM is a functional module of the 5GZORRO platform, available to each stakeholder domain, that directly interacts with the underlying 5G Virtualized Platform. In this way, it offers, to the upper layer applications, a set of services related to resource monitoring and management. It also offers direct support to the 5GZORRO RSOC, through a translation service, to translate on-demand technical descriptions into appropriate resource and service models defined by the TM Forum.
NSSO is responsible for processing communication service level lifecycle management actions received from ISSM. With this scope, NSSO performs communication service mapping into network slices, within an administrative domain, and interacts with the 5G virtualized infrastructure to manage the lifecycle of resources associated with the network slices. This mapping is performed based on rules and algorithms which can be dynamically updated as part of the management control loops. In addition, NSSO is responsible for configuring the service-related monitoring metrics, the corresponding e-Licenses to be attached to the service instances, and the virtual infrastructure networking when the local network slice is part of a multi-domain E2E slice.
The Network Service Mesh Manager (NSMM) aims at securing the end-to-end communication of a service deployed across different management domains. Such a function is performed at orchestration time and is explicitly requested by NSSO which is also the exclusive consumer of the NSMM interface. In this regard, NSMM can be considered an extension of NSSO and fully part of the 5GZORRO Orchestration stack.
To sum up, one of the main advantages of the 5GZORRO platform is that it provides a marketplace where various kinds of resources are offered for trading. In this case, the type of resource traded was compute resources, which were used to expand the capacity of a vertical application. In addition, 5GZORRO mechanisms enable rapid deployment and integration of new VNFs in a slice as well as the appropriate Day-0/1/2 configurations. In general, a variety of 5G players, stakeholders and vertical operators can also benefit from purchasing from the 5GZORRO marketplace, as they can lease only the number of resources they need and for the time required, reducing CAPEX and OPEX costs.