Menu Close

Topic 1

TERMINET open calls banner

TOPIC 1: Service deployment across the edge computing and IoT nodes and SDN control enablement, for validation over the TERMINET architecture and use cases

TOPIC1 Patron: UBITECH

Introduction

TERMINET utilises the concept of multiple access edge computing (MEC) to move decisions to the point of interest to better serve the end user applications according to the related IoT locations. However, MEC is not flexible enough to support the high level of heterogeneity in the IoT ecosystem, while it is not capable of supporting large scale IoT paradigms due to scalability constraints.

To this end, TERMINET leverages Software Defined Networking (SDN) and virtualization technologies to deliver a virtualised SDN enabled, Multi access Edge Computing (vMEC) reference architecture. The virtualisation technologies employed by TERMINET are used to enable on-demand deployment of vMEC nodes, servers, and gateways while SDN provides real-time steering and load balancing of IoT traffic towards TERMINET edge servers.

There are two important aspects of the vMEC scheme related to the current topic:

  • network programmability through a multi-technological SDN network fabric and
  • the ability of the TERMINET vMEC scheme to accommodate services across the IoT-to-edge-to-core cloud continuum, supported by automated application orchestration and re-configuration capabilities.

An early version of the SDN-enabled TERMINET vMEC scheme is depicted in Figure 1. The two key platform components linked to functional aspects mentioned above are the Resource Orchestrator and the SDN controller shown on the right side of the figure. These are establishing control plane bindings with the respective data plane blocks of the TERMINET infrastructure (middle part of figure).

Figure 1: Overview of TERMINET’s SDN-enabled vMEC scheme

The Resource Orchestrator block constitutes the platform layer (PLA-L) building block of the TERMINET architecture and provides the ecosystem for TERMINET applications. In essence, this ecosystem grants two important services to the TERMINET application and intelligence layers (APP-L and INT-L):

  1. core-edge cloud resources for hosting applications and managing their lifecycle; this is provided by the Vertical Application Orchestrator (VAO).
  2. an underlying storage and data processing service to accommodate data originating from or heading to the physical layer (PHY-L); this is provided by the Streaming Analytics Orchestrator (SAO).

Both orchestrators operate atop popular virtual infrastructure managers (VIMs), such as Kubernetes (K8s) or OpenStack.

The SDN controller block enables the interconnection of the various TERMINET IoT resource islands with the rest of the TERMINET platform as well as a microservice-oriented application deployment across edges and the continuum. It interfaces with the VAO through a slicing interface, which allows the VAO to instruct the SDN controller to establish the required communication paths, enabling transparent communication among the overlay TERMINET application components and between application components and IoT devices. Successively, the SDN controller instructs the SDN data plane blocks to install the necessary rules through a set of southbound device drivers, supporting network management protocols (i.e., OpenFlow [1], NETCONF [2], etc.) and the Recursive InterNetwork Architecture (RINA) [3].

The aims of this topic are:

  • The deployment of a new service (beyond those studied in TERMINET use cases) that makes use of the existing IoT and network infrastructure and provides additional service capabilities to the existing end users
  • The deployment of a service followed by new IoT devices that are added to existing infrastructures and followed by the required SDN control interfaces, thus allowing further enhancement of the targeted use case capabilities and the development of synergies with the existing infrastructures.
  • The successful transfer of the TERMINET service deployment and SDN based control platform over new IoT installations followed by the adequate services to be deployed, thus showing the interoperability of the TERMINET architecture.

Functional Requirements

For the deployment of services, the VAO user interface and the overall deployment process must be followed. This relies on a user-friendly environment that facilitates service onboarding, together with service requirements, application component processing parameters, and service policy declarations.

The proposed services must follow the needs, the infrastructure capabilities, and the deployment rules of the end users. These must be known a priori and guide the developers’ efforts accordingly to the extent possible.

The deployment of IoT devices on existing use cases must be followed by the supporting gateway node if this is required and be compatible to the operational characteristics of the use case infrastructure.

Technical Requirements

Services must be presented in the form of linked application components each one separately deployable over the network resources.

The application components must be dockerised. Also, application components are preferred to be in the form of micro-services organised as direct acyclic graphs that can be deployed using e.g., docker compose. OpenStack deployments are also supported if required.

For the deployment of application components, the processing requirements must be known and followed by any specific network requirement.

The implementation of policy decisions (SLAs) must be aligned with the monitoring capabilities of the platform or else the monitoring metrics must be provided

For additional IoT devices or gateways inserted to the infrastructure, the respective device drivers must be provided at the southbound part of TERMINET’s Streaming Analytics platform component (if there is no compatibility with the existing ones). This component is currently realized using the EdgeX Foundry open source project.

Compatibility with the REST endpoints of TERMINET’s Streaming Analytics platform component (i.e., EdgeX) is required for checking health, configuration, and metrics of a specific service or application running on the platform.

Open Call Topic 1 Winner

Title: Privacy-Preserving Federated Learning Application for diagnosis of coMmunication disordErs iN Child development

Acronym: FLAMENCO

Learn more about topic 1 winner

References

  1. McKeown, T. Anderson, H. Balakrishnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turner. “OpenFlow: enabling innovation in campus networks”. SIGCOMM Comput. Commun. Rev. 38, 2 (April 2008), 69–74. DOI: https://doi.org/10.1145/1355734.1355746.
  2. Internet Engineering Task Force (IETF) RFC 6241, “Network Configuration Protocol (NETCONF),” 2011. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc6241.
  3. Grasa, J. Day, M. Tarzan, D. Lopez, K. Smith. “Next Generation Protocols (NGP); An example of a non-IP network protocol architecture based on RINA design principles”. ETSI GR NGP 009, v1.1.1, February 2019.
Skip to content