The Need for Common Functional Architecture
The functional architecture of the EXIGENCE system provides a common foundation for developing technical solutions targeting project’s goal at effectively reducing the energy consumption and carbon footprint of ICT services. The functional architecture therefore relies on the project’s three key pillars, i.e., measurement, optimisation and incentivisation. The three pillars are thus main area of EXIGENCE field of research and development of new solutions following EXIGENCE functional architecture.
As the solutions must operate in a coordinated manner to deliver the expected impact, proper alignment of their functionalities is required. Thus, the goal of the functional architecture is coordination of functionalities of each pillar individually as well as their joint operation – both within a single domain (intra-domain), and across multiple domains (inter-domain). Inter-domain operation is inevitable in today’s ICT landscape, where ICT services commonly utilise several (sub)services within network, cloud and cloud–edge continuum environments, thus making multi-domain service deployment the norm.
Overview of Functional Architecture
EXIGENCE main idea, which also shapes its functional architecture, is to provide ecodata (i.e., data related to energy consumption, carbon impact, etc.) on service- and user- level. As depicted in the figure below, an end-to-end ICT service is typically delivered through a composition of sub-services obtained from several distinct domains. In such a concept, a specific domain acts as a (sub)service provider (e.g., domain B), and the other domain as a service user (e.g., domain A). This model roughly follows the well-established service function chaining (SFC) model, established and defined, e.g., within the IETF.
A domain in this scope refers to a closed set of resources formed by any means (ownership, type, region, service) and submitted to the same policy. Thus, domain can be a technology domain (type of resources), authoritative domain (ownership), etc. As already mentioned, the domain may provide various services, which, however, does not make any significant difference to the EXIGENCE architecture concept. In terms of EXIGENCE architecture, ecodata are primarily collected within each domain, utilising metering methods introduced, e.g., in the blogposts “Development of exigence energy consumption, efficency and carbon footprint metrics” and “Development of exigence methods for energy consumption metering”. It needs to be emphasised again that the EXIGENCE objective is to collect ecodata on service- and user- level.
Similarly, orchestration is also related to each separate domain. Orchestration aims at energy and carbon footprint reduction and energy efficiency improvement, which can be effectively done within the domain as only domain-internal management means can, under the domain policy, change the way how resources are used for each of the executed services.
As well, the third EXIGENCE pillar – incentivisation, is also positioned in the inter-domain space and complements both other pillars. Incentivisation goes along with optimisation aiming at proactively pushing service users to make ecologically reasonable decisions, i.e., in addition to trying to satisfy existing service-level agreements (SLAs), a domain can create service variants, which are functionally equivalent, yet might differ in important quality parameters while also exhibiting different eco-costs. Although the ideal case assumes that the optimisation may reduce the eco-costs of a service implementation without degrading its quality, performance or other parameters, the goal of the incentivisation is also that the service provider can recompense users who are willing to sacrifice service quality (e.g., use services of a lower quality, postpone or rate limit service requests, etc.) with a corresponding incentivisation.
While switching focus from intra-domain to inter-domain environment, EXIGENCE introduces EXIGENCE Energy Reporting agent function or simply an “Agent”. The Agent exchanges data with (i) other Agents, each belonging to its own domain, i.e., horizontal reference points, and with (ii) the internal domain functionality – vertical reference points (see also APPLICATION TO (TEMPLATE) INTRA-DOMAIN ARCHITECTURE below). The horizontal reference point is the central definition of the EXIGENCE functional architecture and is the reference point between two EXIGENCE agents and the data exchanged as depicted in the figure below.
Application to (Template) Intra-Domain Architecture
EXIGENCE believes that its architectural concept, as being generic and therefore not defining any concrete architecture, can be applied to multiple domains. While it would be too time consuming to do such an exercise for every domain of interest, the application of the concept was done generally by prescribing EXIGENCE Agent’s functionality to the template inter-domain architecture. As described above, the Agent represents the (intra) domain within the inter-domain architecture, thus enabling functionalities of all three EXIGENCE pillars.
As depicted in the figure below, implementation of intra-domain architecture spans over three planes – User, Control and Management planes (UP, CP, MP). The Agent is a function of the management plane and is presented as a green triangle in the figure below. Within the User Plane, there is Service Function (SF), which is the actual service-relevant functionality in the domain.
Within the Control Plane, architecture includes Service Directory Function – SDF (has a full list of active services), Resource Allocation Function – RAF (keeps the current service allocations to resources), Resource Energy Measurement Function – REMF (can measure energy consumption and, if available, carbon information of any given resource), Service Energy Information Function – SEIF (is the heart of the intra-domain functionality, it is able to deduce service-level energy consumption and carbon emissions for a given service ID by using other functions to determine subservices and resources and by attributing resource-level energy consumption and carbon emissions to service-level ecodata, typically using measurements from REMF on resources received from RAF for subservices from SDF, with some known proportions, or using some internal mapping model).
Bridging control and management planes, there is a Green Orchestration Function (GOF). As an orchestrator, GOF has a classical lifecycle orchestration function for services, which, for EXIGENCE purposes, can manage all Service Variants as mentioned above. An EXIGENCE GOF contains a novel Energy-based Deployment Function (EDF) – its purpose is to find an energy-optimal placement of a set of required SFs on a set of available resources. An EXIGENCE GOF also possesses a novel Incentive Production and Assignment Function (IPAF), used to calculate incentives to be proposed to service users for the usage of particular service variants.
Contributions to the Standardisation
Architectural concepts developed within the project have been disseminated into several standardisation bodies including ETSI PDL, ETSI OSM, the IETF Green Working Group, and 3GPP EnergySYS and 6G Study. The goal of EXIGENCE architecture is not to revolutionise existing network architectures provided by standardisation bodies, but rather to contribute to them with a focus on enabling a gradual evolution towards service delivery with reduced energy consumption and carbon footprint, and with improved overall energy efficiency. In that regard, the above-mentioned EXIGENCE Agent is a central artefact which guided the standardisation efforts and shaped the key challenges addressed in these contributions: how to integrate the Agent concept, and its underlying principles, into the specific architectural scopes and functional domains addressed by each standardisation body.
Within ETSI PDL, which is an industry specification group (ISG) that studies how the industry can utilise permissioned distributed ledger (PDL) technology to enable multi-party interoperation in a trustworthy and decentralised manner, a Group Specification (GS) work item (WI) was proposed by EXIGENCE partners. The WI was approved in April 2024 and started in May 2024. Within WI, inter-domain ecodata exchange system architecture and related interworking procedures were promoted. The work, among others, included study on methods and metrics for energy consumption metering, it defined a PDL-based framework to overcome challenges in data integrity, fragmentation, and trust within inter-domain environment, as well as has defined distributed consensus mechanisms for energy consumption data post-verification and outlined the design and usage of dedicated Smart Contracts for automated compliance checks, policy enforcement, and managing energy-aware incentives. The work was finalised and published in November 2025, now publicly available as an ETSI GS for reference.
Within ETSI OSM, the EXIGENCE Green Orchestrator Function was promoted. EXIGENCE has kick-started the Open-Source MANO code contribution process, to embed its definitions in the VNF and Network Service descriptors, pushing sustainability-driven orchestration practices into OSM.
Within the IETF, primarily through the GREEN working group, EXIGENCE has helped turn “green networking” concepts into concrete, implementable artefacts by contributing to (and aligning with) the WG’s emerging documents: the Use Cases for Energy Efficiency Management (now progressed as a WG draft) and the Framework for Energy Efficiency Management. On top of this framework, EXIGENCE supported work has advanced the PETRA Path Energy Traffic Ratio API. In parallel, EXIGENCE has promoted device and power-infrastructure integration through the SmartPDU YANG model, initially prototyped in the IETF 123 Hackathon and then carried into the GREEN draft to enable vendor-neutral telemetry and control of PDUs as part of an end-to-end energy observability stack. These contributions were actively discussed at IETF 124 in the GREEN sessions, where adoption and progress of drafts were explicitly on the agenda, illustrating EXIGENCE’s role in pushing the work from project results into the IETF standards pipeline.
In 3GPP, EXIGENCE contributed to SA1 and SA2. Within SA1 (5G Advanced, Release 20), input and support were given to the creation of the new study item on “Energy efficiency as service criteria” to ensure that the EXIGENCE idea of inter-domain, service-oriented ecodata reporting and optimisation was in scope for this study. Subsequently, several of the EXIGENCE use cases were proposed to the study, resulting in three of the nine use cases in the study report (TR 22.883). Additionally, in 3GPP 6G Study (6G, Release 20), EXIGENCE requirements were added to Clause 5.8.6 “Use case on energy saving for network in industry park” of the 6G Study Report (TR 22.870). Further refinement and clarification of the requirements were approved and will be included into TR 22.870 v2.0.0. Thus, SA1 efforts helped enable the subsequent submission of solutions to 3GPP SA2 where two solutions were accepted. They both provide the energy-based resource selection and optimisation functionality of GOF in EXIGENCE architecture, i.e., a solution for the core network control plane to enhance the NF selection process in NRF, and a solution for the core network control plane aiming at enabling energy consumption control for energy saving in a network slice.
Contributions to the Research and Industry Community
In addition to contributions to the standardisation, EXIGENCE partners have produced several theoretical and practical outcomes that support the proposed architecture and demonstrate its broader applicability. These results include research contributions with potential for further investigation, as well as practical solutions that require additional development to reach market readiness. The outcomes are considered relevant for future standardisation, research and innovation activities, and potential exploitation including commercialisation:
- research contributions include energy consumption and carbon footprint metrics, energy consumption modelling, incentives for green video streaming and for carbon-aware AI services, value sharing among stakeholders resulting from energy and carbon efficiency gains, energy-efficient federated learning orchestration, energy-efficient placement and execution of distributed AI services, and green-energy-aware federated learning resource orchestration,
- practical solutions include end-to-end energy measurement for streaming, integration of power consumption tools into existing products (MobileONE and qMON – quality monitoring suite), and contributions to Green ICT DIGEST on incentive mechanisms.
Author
Internet Institute Ltd
Rudolf Susnik, manages research and innovation-oriented projects at Internet Institute, focusing on 5G/6G, IoT, edge-cloud continuum, sustainability in ICT and ICT for sustainability. He has over 15 years of experiences from ICT industry, working for network operators and vendors. As well, he also has research and teaching experiences from academia, i.e., University of Ljubljana, where he received his PhD in 2007. In his free time, he actively serves as a volunteer firefighter, contributing to community safety and emergency response.