Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Introduction

This type II BP of PCEI family focuses on solution with a mobile game deployed across multiple heterogenous edge nodes using various network access modes including mobile and Wifi. The key component is a federated multi-access edge cloud platform – it features several key components. The platform sits between applications and underlying heterogeneous edge infrastructure and also abstracts the multi-access interface and exposes application developer friendly APIs. This blueprint leverages upstream project KubeEdge as baseline platform – this includes the enhanced  federation function (Karmada).

Federated MEC Cloud Platform – Functional Diagram

Cloud Gaming Detail Flow

Federated KubeEdge (Karmada) - Hard Multitenancy using multiple autonomous K8S clusters

Key Enabling Architectural Components

  • Federation Scheduler (Included in Release-5): As a “Global Scheduler”, responsible for application QoS oriented global scheduling in accordance to the placement policies. Essentially, it refers to a decision-making capability that can decide how workloads should be spread across different clusters similar to how a human operator would. It maintains the resource utilization information for all the MEC edge cloud sites.
  • Multi-Mesh (Included in Release-5): Provides support for service mesh capabilities for the edge clouds in support of microservice communication cross cloud and edges.
  • Service Discovery: Retrieves the endpoint address of the edge cloud service instance depending on the UE location, network conditions, signal strength, delay, App QoS requirements etc.
  • Mobility Management: Cloud Core side mobility service subscribes to UE location tracking events or resource rebalancing scenario. Upon UE mobility or resource rebalancing scenario, mobility service uses Cloud core side Service Discovery service interface to retrieve the address of new appropriate location-aware edge node. Cloud Core side mobility service subsequently initiates UE application state migration process between edge nodes. Simple CRIU container migration strategy may not be enough, much more complex than VM migration.
  • Multi-Access Gateway: Multi access gateway controller manages Edge Data Gateway and Access APIG of edge nodes. Edge data gateway connects with edge gateway (UPF) of 5g network system, and routes traffic to containers on edge nodes. Access APIG connects with the management plane of 5g network system (such as CAPIF), and pulls QoS, RNIS, location and other capabilities into the edge platform.
  • AutoScaling: Autoscaler provides capability to automatically scale the number of Pods (workloads) based on observed CPU utilization (or on some other application-provided metrics). Autoscaler also provides vertical Pod autoscaling capability by adjusting a container’s ”CPU limits” and ”memory limits” in accordance to the autoscaling policies.
  • Service Catalog: It provides a way to list, provision, and bind with services without needing detailed knowledge about how those services are created or managed.
  • Cluster Registry: It tracks a collection of clusters inventory which can store per cluster metadata.


  • No labels