Micro-service Architecture

AdvantEDGE is a controller software that facilitates deployment of edge applications in a simulated network environment.

It is composed of a collection of micro-services that interact together to allow deployment and testing of edge scenarios.

AdvantEDGE micro-services are packaged in Docker containers which are designed to operate in a Kubernetes environment.

Containers belong to one of 4 groups

High-level overview of AdvantEDGE micro-service architecture:

The following subsystems compose the AdvantEDGE Platform:

The following components compose each AdvantEDGE Sandbox:

Network Model

AdvantEDGE uses the following model to define a scenario.

Wireless Connectivity

AdvantEDGE supports 4G, 5G and WLAN wireless connectivity types for PoAs within a scenario and a PoA supports a unique technology. Wireless connectivity is reserved for user terminals while edge and cloud nodes are considered wired (e.g. not supporting wireless edge nodes yet)

Accordingly, user terminals can be configured to support a subset or all existing wireless connectivity types. The wireless technologies of a terminal can also be prioritized in case a terminal is in range of several PoAs; in that case a UE would connect via the highest priority wireless technology which is physically the closest to the terminal.

User terminals also support having no connectivity; this can happen if the initial state has been configured as disconnected, if a terminal is out of range of all supported PoAs (when using the GIS automation) or when a user sends a Mobility event to DISCONNECTED destination.

Network Characteristics

AdvantEDGE supports the following network characteristics: latency, jitter, throughput and packet loss.

With regards to the AdvantEDGE model, network characteristics can be applied on a Scenario (Inter-Domains, including Distant cloud elements which are considered as part of another domain), Domains (Inter-Zones), Zones (Intra-Zones), POAs (Terminal-links), Physical Locations (Distant clouds, Edge nodes, Fog nodes, UEs) and Processes (Applications)

At deployment time, containers are started in a Kubernetes pod; AdvantEDGE inserts a companion container (a sidecar) in each deployed pod. The sidecar has the mandate to apply network characteristics from the simulation model. The TC-engine is the micro-service responsible for implementing the real-time simulation model; it constantly maintains & updates network characteristics using multiple inputs such as the scenario values, scenario updates (mobility & net.char events), current bandwidth used by every pod, etc. providing each sidecar of the scenario with values to apply. The “tc” acronym comes from Traffic Control and relates to the underlying tc-netem technology used to realize network characteristics in each sidecar.

About network emulation, the emulation model is path emulation and is only concerned with emulating end-to-end network characteristics between processes, using a network hierarchy defined by the scenario. The resulting network characteristics applied between two communicating processes are then the result of calculations based on the scenario topology (see table below for the details). Internally, each possible path between processes is sub-divided in segments onto which network characteristics are applied; finally, using these segments, an end-to-end path calculation is done. For example, in its simplest form, end-to-end segment latencies are added to compute the path latency; at a higher complexity level, available bandwidth requires a calculation that is function of the segments configuration and real-time consumption by other processes sharing the path segments.

Each network characteristic has the same configuration points: Inter-Domain, Inter-Zone, Intra-Zone, Terminal Link, Node and Application.

Path example

A path is a collection of segments with each segments having its own network characteristics.

Two processes exchanging data in one direction is called a flow. A flow contains a path. A path is unidirectional.

The following provides a general overview of a path-segments evaluation between processes executing in different physical locations for a given scenario.

Compute Characteristics

AdvantEDGE supports the following compute characteristics: CPU limits (min & max), memory limits (min & max).

These can be specified at scenario configuration time and cannot be dynamically updated once a scenario is deployed. The compute characteristics are handled by the K8s platform.

CPU limitation will reserve the minimum value and automatically cap CPU usage to the to the maximum value specified. CPU units can be specified as a fraction ( ex: 1.3, 0.5, 0.25 etc.); 1 CPU corresponds to 1 Core, 1 vCPU or 1 Hyperthread depending on the host platform you are running on.

Memory limitation will reserve the minimum value and automatically cap memory usage to the to the maximum value specified. Memory units are in MegaBytes.

A workload will not execute if the system does not have enough resources to satisfy requirements; the following rules apply:

Edge Application Architecture

Edge applications architecture may be influenced by different deployment, behavioral and grouping models. Below, we provide architectural considerations for developing your edge applciations.

Deployment Model

Edge application deployment model relates to the UE to edge application relationship

Below are a few deployment model examples:

• Model 1: One edge application instance serving one UE (one-to-one relationship)
  - multiple edge application instances can reside on the same physical node simultaneously

• Model 2: One edge application instance serving all UEs connected to a PoA (one to many relationship)
  - one edge application instance resides on a physical node serving a localized geographical area

• Model 3: One edge application instance serving all UEs present in a Zone (one-to-many relationship)
  - one edge application instance resides on a centrally located node serving a larger geographic area

• Other edge application deployment models may be valid too!

What if your deployment model is not listed?
AdvantEDGE has been developed to provide as much flexibility as possible, so it may already support other deployment models not listed above out of the box.
If your use case requires a deployment model that is not currently supported, AdvantEDGE can be extended to support it.

Behavioral Model

The behavioral model of an edge application can vary greatly depending on its function, deployment model and overall design.

Below are some considerations that influence the behavioral model of an edge application:

• Bootstrapping
  - When is the edge application instantiated?
  - Does it follow an Always-available vs Just-in-time instantiation model?
  - Where is the application bootstrapped?

• State Management
  - Is the edge application stateful or stateless?
  - Where do stateful applications get the inital UE state?
  - Does the state need to be persisted or transfered when UE moves away?

• UE Mobility
  - How does the edge application react to UE mobility events?
  - Should edge application instance follow UE movement through the network?
  - Should UE state be transferred to another instance when the UE moves through the network?
  - Does the MEC platform provide an instance/state transfer service or does it happen at the application level (e.g. "over-the-top")

To help application developers & researchers with edge application design, AdvantEDGE allows to experiment with different models in an agile manner before any deployment happens on the real infrastructure.

Grouping models

AdvantEDGE uses the single-edge application terminology to designate an independent application that execute in a single edge location. Many instances of a single-edge application may be executed on the platform; these applications are not inter-related from the platform point of view and are considered as different applications.

AdvantEDGE uses the multi-edge application terminology to designate an edge application formed by a group of edge applications; the group has multiple instances running on different geographically dispersed nodes. The group is considered as a single application by the platform.

From a UE point of view, accessing a single/multi-edge application at run-time makes no difference; the fact that the application has multiple instances is not known to the UE.

From a network point of view however, a UE accessing a single-edge application consist in routing the traffic to that specific application instance while a UE accessing a multi-edge application consists in routing the traffic to the edge application instance closest to the UE; it is therefore up to the network to route the UE traffic to the closest edge application instance based on the UE location.

AdvantEDGE defines a multi-edge application as an edge application belonging to an edge-group; edge applications with no edge-group are considered as single-edge applications.

In order to provide support to multi-edge applications scenarios, AdvantEDGE implements the application state transfer edge service.

Frontend Architecture

This section provides a bird’s eye view of the AdvantEDGE frontend architecture. This high-level overview should give the reader enough insight into the design choices to get started exploring and augmenting it.

The frontend is based on React and Redux javascript technologies

The frontend is composed of 5 main tabs or pages.

States

A key portion of the React application state structure is shown below:

{
  ui: {
    page: ...,
    eventCreationMode: true | false,
    currentEventType: MOBILITY_EVENT | NETWORK_CHARACTERISICS_EVENT,
    devMode: true | false,
    automaticRefresh: true | false,
    refreshInterval: <in ms>,
    execShowApps: true | false
    ...
  },
  cfg: {
    type: {...},
    state: {...}
    scenario: {...}
    vis: {...}
    table: {...}
    elementConfiguration: {...}
    apiResults: {...}
    ...
  },
  exec: {
    type: {...}
    state: {...}
    scenario: {...}
    vis: {...}
    table: {...}
    selectedScenarioElement: {...}
    apiResults: {...}
    ...
  },
  settings: {
    ...
  },
}

The following table describes information elements of ui state.

The following table describes information elements of cfg state.

The following table describes information elements of exec state.

Reducers

AdvantEDGE frontend uses a Redux reducer; it takes as its arguments an action and the current state of the application and computes a new state for the application. In turn, the main functionality of React can be seen as a function that takes the state and through a render function outputs corresponding html markup.

In AdvantEDGE frontend, the root reducer is composed from more specialized reducers that individually compute state transistions for the following branches of the state tree: ui, cfg, exec and settings. In turn, cfg and exec are each created by combining lower-level reducers, one for each sub-branch of the state.

Actions

The state of the application is updated through Redux actions when user-initiated events occur or following responses from HTTP requests to the AdvantEDGE server.

The following diagram illustrates this general pattern as used in the AdvantEDGE frontend.

The following table describes actions of the AdvantEDGE application.

Next Step

Learn about the various Platform features that enable a rich experimentation environment:

• Event generation
• Geospatial Information System (GIS)
• Sandbox environment
• External nodes
• etc.