Towards NWDAF-enabled Analytics and Closed-Loop Automation in 5G Networks

Fatemeh Shafiei Ardestani; Niloy Saha; Noura Limam; Raouf Boutaba

REVIEW 3 major objections 6 minor 1 cited by

Towards NWDAF-enabled Analytics and Closed-Loop Automation in 5G Networks

T0 review · 3 major / 6 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A working 5G closed loop: UPF event exposure feeds NWDAF analytics that drive SMF session release, cutting attack response to under 10 seconds.

desk verdict Real open-source NWDAF engineering with a credible testbed, but the closed-loop security claim needs detection metrics before it lands. read the letter →

arxiv 2505.06789 v1 pith:EUVBDRBB submitted 2025-05-11 cs.NI

Fatemeh Shafiei Ardestani , Niloy Saha , Noura Limam , Raouf Boutaba This is my paper · ORCID

classification cs.NI

keywords NWDAF5GUPFeventexposureserviceclosed-loopautomationanomalydetectionSMFpolicyenforcementopen-sourcecorenetwork

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that 3GPP-standardized network automation for 5G is practically achievable today with open-source components. It presents the first implementation of the UPF Event Exposure Service, the standard interface for pulling user-plane telemetry, and wires it into an NWDAF that runs ML-based analysis and a modified SMF that terminates sessions of anomalous UEs. The result is a proof-of-concept closed loop that detects and mitigates a bot attack with sub-10-second latency and modest UPF overhead. Demonstrating the full feedback cycle—not just analytics in isolation—is the paper's central contribution.

What carries the argument

The load-bearing object is the UPF Event Exposure Service implementation: five modules (encoder/decoder, server, data preparation, client) that convert raw packets into 3GPP-compliant JSON notifications on demand. It is what makes the rest of the loop possible, because it replaces ad hoc or indirect data collection with a standardized real-time feed from the user plane. Around it, the NWDAF's SBI/NBI split and the ML Model Provisioning Service (with MLflow as registry) supply the analysis, and the SMF extension supplies the action; together they complete the closed loop.

What would settle it

Run the deployed pipeline with labeled test traffic where the attack is a known botnet flow (e.g., a CTU-13 scenario) and measure true/false positive rates; if the model fails to flag the flow or flags benign traffic, the closed-loop mitigation claim collapses. Alternatively, disable the ML model and substitute a random or heuristic detector: if similar mitigation latency results, the ML component is not what carries the loop.

Watch

Extended reading notes

Core claim

The paper's central claim is the first end-to-end realization of the NWDAF closed loop defined by 3GPP: the UPF Event Exposure Service is implemented in C and embedded in Open5GS and OAI 5G cores, the NWDAF's southbound interface subscribes to per-flow volume reports in the standard JSON format, a Random-Forest bot detector ingests graph features computed from those reports, and an extended SMF consumes the resulting abnormal-behavior analytics and releases the offending PDU sessions via N4. The evaluation shows latency and CPU overhead of the EES are negligible against a baseline, NWDAF's data collection and notification modules are lightweight relative to ML provisioning, and the full attack-to-mitigation pipeline completes in under 10 seconds. The authors state this is the first implementation of the UPF EES and the first closed-loop proof-of-concept involving UPF, NWDAF, and SMF together.

Load-bearing premise

The closed-loop effectiveness claim rests on the untested assumption that the Random Forest model trained on CTU-13 botnet flows recognizes the Nmap-based scanning behavior used in the testbed; without validated detection accuracy, the measured mitigation latency may not reflect a genuinely successful detection.

Editorial extensions

If this is right

Operators can collect user-plane telemetry through the standardized UPF EES rather than proprietary or SMF-relayed paths, improving interoperability and scalability.
Closed-loop security automation—detecting abnormal UE behavior and terminating sessions—can be deployed on open-source 5G cores without human intervention.
The NWDAF architecture scales by separating data collection and notification modules from the ML provisioning service, which dominates CPU usage and should be scaled independently.
Because the loop is driven by 3GPP-defined subscription parameters, shorter data collection intervals yield faster mitigation, at the cost of detection accuracy.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

The paper does not validate that the CTU-13-trained Random Forest generalizes to the Nmap scanning attack used in the testbed; if detection accuracy is low, the sub-10-second mitigation time is a best-case rather than typical figure.
The same EES-to-NWDAF-to-SMF architecture should extend to other 3GPP analytics IDs (e.g., QoS monitoring, mobility anomalies) and other enforcement points such as the PCF, which the authors list as future work.
The bottleneck identified—ML inference time—suggests that optimizing or pre-deploying detection models will directly improve closed-loop latency, possibly below the measured values.
A direct comparison of the UPF EES against the SMF-relay data collection used by prior work (e.g., via N4) would quantify the standardization benefit in latency and load.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Two things to know upfront. First, this is a genuine engineering contribution: the authors implement three pieces that didn't exist together in open-source 5G cores—a UPF Event Exposure Service, an ML model provisioning service built on MLflow, and an SMF extension that acts on NWDAF analytics to release PDU sessions. Second, the paper's claim that the system is "effective" for closed-loop security management is the soft spot. The evaluation measures pipeline latency but never measures detection accuracy or false positives.

What's genuinely good: the UPF EES implementation is real, follows 3GPP message formats, and the overhead measurements (latency, CPU) use 95% CIs and show minimal impact. The NWDAF resource usage breakdown is useful, and the closed-loop workflow is clearly described. The code is public, which raises the bar for reproducibility. Table 1 gives a fair comparison of prior NWDAF work. The "first" claims are not independently verified, but they're plausible given the survey.

The central weakness is the security effectiveness. The Random Forest bot detector is trained on CTU-13 botnet flows and then tested on an Nmap http-open-proxy scan in the testbed. No precision, recall, or false positive rate is reported. That matters because a false positive would cause the SMF to release a legitimate UE's PDU session—a real safety failure. The latency numbers in Figure 8 are only meaningful for cases where the UE got banned; they say nothing about missed attacks or false alarms. The stress-test note put this correctly: the transfer of the CTU-13 model to a different attack is assumed, not shown. This isn't a fatal flaw for the engineering contribution, but it is a load-bearing gap for the "effectiveness" claim.

Minor points: UERANSIM-simulated UEs and synthetic traffic limit generalization, but that's typical for this kind of systems work. The self-citation to Monarch is fine—it's used as motivation, not as evidence. The MLflow integration is straightforward but reasonable.

Who should read this: operators and researchers wanting a working reference implementation of NWDAF data collection and closed-loop mitigation. It's a systems paper, not an ML/security evaluation paper. With a serious revision—adding detection metrics on the testbed's own traffic, or softening the effectiveness claim to "latency of the pipeline"—this could be a solid venue paper. I'd send it to peer review: the engineering deserves referee time, and the missing metrics are fixable.

Referee Report

3 major / 6 minor

Summary. The paper presents an NWDAF implementation for 5G networks with three main engineering contributions: a 3GPP-compliant UPF Event Exposure Service for standardized real-time data collection, an ML Model Provisioning Service integrated with MLflow for model lifecycle management, and an SMF extension that subscribes to NWDAF abnormal-behavior analytics and automatically releases PDU sessions of flagged UEs. The system is integrated with Open5GS and OAI 5G Core, and evaluated on an Open5GS/UERANSIM testbed. The evaluation measures UPF latency and CPU overhead under increasing data rate and UE count, NWDAF module CPU usage at different reporting intervals, and end-to-end attack-to-mitigation latency for a bot-detection scenario using a Random Forest model trained on CTU-13 graph features and tested on an Nmap http-open-proxy scan. The paper claims the first implementation of the UPF Event Exposure Service and the first proof-of-concept closed-loop automation involving UPF, NWDAF, and a modified SMF.

Significance. If the implementation claims hold, this is a useful systems contribution: it addresses a real gap between 3GPP-specified NWDAF capabilities and available open-source implementations, and it makes the source code publicly available. The UPF overhead measurements with confidence intervals are a concrete data point for the cost of standardized event exposure, and the SMF-side closed-loop action is a natural and standards-aligned demonstration. The main weakness is that the closed-loop effectiveness claim is not supported by detection-quality metrics: the model is trained on CTU-13 but evaluated on a different attack type, and no accuracy, precision, recall, or false-positive rates are reported. This makes the end-to-end latency numbers conditional on unmeasured detection success and leaves safety-relevant false positives unexplored. The paper is therefore best viewed as a credible system prototype whose effectiveness claim needs substantially more evidence before it can be accepted as demonstrated.

major comments (3)

[§6.3, Figure 8] The central effectiveness claim in the abstract and §6.3 is not supported by the reported measurements. Figure 8 reports t1/t2/t3 latencies averaged over 20 trials, but the paper gives no detection accuracy, precision, recall, F1, true-positive rate, or false-positive rate for the Random Forest bot detector on the testbed's Nmap http-open-proxy attack. The model is trained on CTU-13 Scenarios 1, 2, 3, and 5 with node-level graph features (§5), while §6.3 evaluates on a scanning behavior that is not present in that training data. The t2/t3 values are therefore conditional on the model having eventually flagged the UE; the paper does not report how often this happened, nor how often benign UEs were falsely flagged. Because a false positive triggers SMF to release a legitimate UE's PDU session via N4 (§3.4), the evaluation as designed cannot detect this safety-relevant failure mode. I request per-trial detection counts, ground-truth-labeled evaluation of both the testbed attack and benign traffic, and explicit TPR/FPR metrics, or the effectiveness claim should be revised to pipeline latency under successful detection.
[§5, Bot Detection Model] The training and evaluation data pipeline is underspecified, which blocks reproducibility of the detection claim. The model is trained on 'bot behavior data from Scenarios 1, 2, 3, and 5 of the CTU-13 dataset', but it is not stated whether benign examples used for training come from CTU-13 or from the 'different scripts inside UEs' mentioned in the same section. It is also not stated whether any CTU-13 data were held out for validation, and no validation accuracy for the Random Forest model is reported anywhere. The testbed's Nmap scan produces a graph (one UE, 20 servers, proxy-scan flows) that is structurally very different from CTU-13 botnet communication graphs, yet the paper does not discuss this domain shift. The authors should provide a validation experiment on the testbed's own labeled attack and benign traces, or explicitly limit the claim to a mechanism demonstration rather than a validated detector.
[§6.1, Figure 6] The scalability claim is broader than the evidence. The experiments use at most 7 simulated UEs and up to 100 Mbps in a UERANSIM-based testbed, and Figure 6c fixes the total data rate at 10 Mbit/s while increasing the number of UEs, so per-flow reporting is not stressed as the number of flows grows. The abstract and conclusion state scalability without these qualifications. I recommend either extending the UE-count experiments to ranges where per-flow notification generation is actually stressed, or qualifying the scalability claim to the tested regime.

minor comments (6)

[§1, Section numbering] The introduction says 'Section 5 demonstrates the operational workflow and evaluates the system against multiple metrics' and then 'Section 7 concludes', omitting Section 6, which is the Performance Evaluation. The section references should be corrected.
[Figure 6c] The x-axis labels and legend use '1 UEs', '3 UEs', etc.; '1 UEs' should be '1 UE', and the legend entries should be made consistent with the plotted series.
[Listing 1] The sample notification contains a truncated IP address ('142..}') and the 'packFiltId' string appears cut off; the listing should show a complete, valid example.
[§6.1, Latency measurement] The one-way delay is computed as half of the average RTT; this assumes symmetric network paths and should be stated as an approximation rather than a precise one-way measurement.
[§6.2, Figure 7] The ML Model Provision Service CPU share lumps together MLflow registry queries, model filtering, and inference serving, so the statement that this service dominates CPU usage is not decomposable. A per-submodule breakdown would make the scaling recommendation in §6.2 more actionable.
[§4, Open5GS and OAI] Section 4 states that both Open5GS and OAI 5G Core support the entire closed-loop workflow, but Section 6 reports experiments only on Open5GS. The text should state explicitly whether the OAI integration was exercised in the closed-loop evaluation or only implemented.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: the implementation is built against external 3GPP specifications and an external CTU-13 dataset, and the evaluation is a new testbed measurement rather than a re-derivation of inputs.

full rationale

The paper's chain of claims is self-contained: the UPF Event Exposure Service, NWDAF analytics, and SMF enforcement are implemented against 3GPP TS 23.288, TS 23.502, and TS 29.564, which are external specifications. The bot detection model is trained on the public CTU-13 dataset, not on the testbed's own attack traffic, and the closed-loop latency measurements in Section 6.3 (t1, t2, t3) are direct measurements of the implemented pipeline rather than quantities derived from fitted parameters. There are no equations whose outputs are fed back as inputs, and no fitted parameter is renamed as a prediction. The only self-citation is Monarch [17], used to motivate a gap; the central implementation and evaluation do not rely on it for support. The skeptic's concern that detection accuracy is never validated for the Nmap-based attack is a real evaluation completeness gap, and Section 6.3's trade-off discussion implicitly acknowledges this by referring to 'required detection precision' without quantifying it, but this is a correctness/evidence weakness, not circularity: the model was not fitted to the testbed data, so the measured mitigation latency is not a re-expression of the training input. Therefore the circularity score is 0.

Assumptions & free parameters 1 free parameters · 3 assumptions · 0 invented entities

The system builds entirely on existing 3GPP standards, open-source cores, and a public botnet dataset; no new entities are postulated. The main unverified assumptions concern the transfer of the ML model and the representativeness of the simulation testbed.

free parameters (1)

Random Forest model hyperparameters and trained weights = Not reported
The bot detection model is trained on CTU-13 data, but the paper neither reports the hyperparameters nor evaluates detection accuracy; the exact model determines both detection latency and whether the block action is correct.

assumptions (3)

domain assumption The 3GPP TS 29.564 and TS 23.288 specifications correctly define the UPF Event Exposure Service and NWDAF analytics interfaces as implemented.
The implementation is built to these specs, and the paper does not validate interoperability against an independent 3GPP-compliant implementation.
domain assumption UERANSIM simulations of UEs and gNB are representative enough of real 5G devices for the measured latency and CPU overhead to generalize.
All experiments use UERANSIM rather than physical UEs or commercial cores; the paper does not compare against real hardware.
domain assumption The CTU-13 botnet dataset provides a valid training distribution for detecting the Nmap open-proxy scanning behavior used in the closed-loop evaluation.
The model is trained on CTU-13 flow data but tested on a different attack tool and testbed traffic; no transfer validation is reported.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Towards NWDAF-enabled Analytics and Closed-Loop Automation in 5G Networks." pith.science (2026). https://pith.science/paper/EUVBDRBB

@misc{pith2026250506789,
  author       = {Pith},
  title        = {Pith review of: Towards NWDAF-enabled Analytics and Closed-Loop Automation in 5G Networks},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/EUVBDRBB}},
  note         = {Machine review of arXiv:2505.06789}
}

read the original abstract

The fifth generation of cellular technology (5G) delivers faster speeds, lower latency, and improved network service alongside support for a large number of users and a diverse range of verticals. This brings increased complexity to network control and management, making closed-loop automation essential. In response, the 3rd Generation Partnership Project (3GPP) introduced the Network Data Analytics Function (NWDAF) to streamline network monitoring by collecting, analyzing, and providing insights from network data. While prior research has focused mainly on isolated applications of machine learning within NWDAF, critical aspects such as standardized data collection, analytics integration in closed-loop automation, and end-to-end system evaluation have received limited attention. This work addresses existing gaps by presenting a practical implementation of NWDAF and its integration with leading open-source 5G core network solutions. We develop a 3GPP-compliant User Plane Function (UPF) event exposure service for real-time data collection and an ML model provisioning service integrated with MLflow to support end-to-end machine learning lifecycle management. Additionally, we enhance the Session Management Function (SMF) to consume NWDAF analytics and respond accordingly. Our evaluation demonstrates the solution's scalability, resource efficiency, and effectiveness in enabling closed-loop security management in 5G networks.

Figures

Figures reproduced from arXiv: 2505.06789 by the authors.

**Figure 2.** High-level overview of our NWDAF system for closed [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗

**Figure 3.** UPF Event Exposure Service 4 [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗

Figures from the paper (5 more)

**Figure 4.** Figure 4: ML model Provision Service ML Model Provision Service. In line with the 3GPP specification, this service can receive different subscription requests through the server module and provide information about the requested ML models using the client module. We integrate M…

**Figure 5.** Figure 5: Sequence diagram for closed-loop workflow [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

**Figure 6.** Figure 6: UPF performance under varying stress conditions: (a–b) Increasing data rates; (c) Increasing number of UEs [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

**Figure 7.** Figure 7: Resource usage of different NWDAF modules [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

**Figure 8.** Figure 8: Response time breakdown for automated attack [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Untangling Co-Drift: Proactive Multi-Intent Failure Prediction and Root-Cause Disambiguation for Self-Driving Networks
cs.NI 2026-07 conditional novelty 6.0 of 10

MILD jointly predicts imminent intent failures in self-driving networks and identifies the root-cause intent under co-drift, using a teacher-augmented mixture-of-experts model.

Reference graph

Works this paper leans on

20 extracted references · 19 canonical work pages · cited by 1 Pith paper

[1]

Nmap Network Scanner

2009. Nmap Network Scanner. https://nmap.org

work page 2009
[2]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Core Network and Terminals; 5G System; User Plane Function Services; Stage 3 (Release 18). Technical Report TS 29.564. 3GPP

work page 2024
[3]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Services and System Aspects; Architecture enhancements for 5G System (5GS) to support network data analytics services; (Release 19). Technical Report TS 23.288. 3GPP

work page 2024
[4]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 19). Technical Report TS 23.502. 3GPP

work page 2024
[5]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Services and System Aspects; System archi- tecture for the 5G System (5GS); Stage 2 (Release 19). Technical Report TS 23.501. 3GPP

work page 2024
[6]

Khizar Abbas, Talha Ahmed Khan, Muhammad Afaq, Javier Jose Diaz Rivera, and Wang-Cheol Song. 2021. Network Data Analytics Function for IBN-based Network Slice Lifecycle Management. In 2021 22nd Asia-Pacific Network Operations and Management Symposium (APNOMS). 148–153. doi:10.23919/APNOMS52696. 2021.9562662

work page arXiv 2021
[7]

OpenAirInterface Software Alliance. 2025. OAI 5G Core Network (CN5G). https://gitlab.eurecom.fr/oai/cn5g Accessed: 2025-04- 06

work page 2025
[8]

Abebu Ademe Bayleyegn, Zaloa Fernández, and Fabrizio Granelli

work page

Show all 20 references

[9]

Ali Chouman, Dimitrios Michael Manias, and Abdallah Shami
[10]

MLflow Contributors. 2025. MLflow:A Tool for Managing the Machine Learning Lifecycle. https://mlflow.org/#core-concepts Accessed: 2025-04-06

2025
[11]

Open5GS Contributors. 2025. Open5GS: Open Source 5G and EPC. https://github.com/open5gs/open5gs Accessed: 2025-04- 06

2025
[12]

Sebastian Garcia, Martin Grill, Jan Stiborek, and Alejandro Zunino. 2014. An empirical comparison of botnet detection meth- ods. computers & security45 (2014), 100–123

2014
[13]

Ali Güngör. 2025. UERANSIM: Open source 5G UE and RAN (gNodeB) implementation. https://github.com/aligungr/ UERANSIM Accessed: 2025-04-06

2025
[14]

Dimitrios Michael Manias, Ali Chouman, and Abdallah Shami
[15]

Abdelkader Mekrache, Karim Boutiba, and Adlen Ksentini. 2023. Combining Network Data Analytics Function and Machine Learn- ingforAbnormalTrafficDetectioninBeyond5G.In GLOBECOM 2023-2023 IEEE Global Communications Conference. IEEE, 1204–1209

2023
[16]

Sebastian Peters, Fikret Sivrikaya, Satyatma Winarga Rochadi, and Amina Ayadi-Miessen. 2024. Cobra-5G – an AI-Driven Solu- tion for Resilient Industrial Applications in Private 5G Environ- ments. In2024 International Conference on Intelligent Comput- ing, Communication, Networ...

2024
[17]

InGLOBECOM 2022-2022 IEEE Global Communications Conference

An NWDAF approach to 5G core network signaling traffic: Analysis and characterization. InGLOBECOM 2022-2022 IEEE Global Communications Conference. IEEE, 6001–6006

2022
[20]

Niloy Saha, Nashid Shahriar, Muhammad Sulaiman, Noura Li- mam, Raouf Boutaba, and Aladdin Saleh. 2025. Monarch: Mon- itoring Architecture for 5G and Beyond Network Slices.IEEE Transactions on Network and Service Management22, 1 (2025), 777–790. doi:10.1109/TNSM.2024.3479246 10

2025
[2022]

In 2022 Inter- national Wireless Communications and Mobile Computing (IWCMC)

Towards supporting intelligence in 5G/6G core networks: NWDAF implementation and initial analysis. In 2022 Inter- national Wireless Communications and Mobile Computing (IWCMC). IEEE, 324–329

2022
[2024]

In2024 IEEE 10th International Conference on Network Softwarization (NetSoft)

Real-Time Monitoring of 5G Networks: An NWDAF and ML Based KPI Prediction. In2024 IEEE 10th International Conference on Network Softwarization (NetSoft). 31–36. doi:10. 1109/NetSoft60951.2024.10588931

2024

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.

[1] [1]

Nmap Network Scanner

2009. Nmap Network Scanner. https://nmap.org

work page 2009

[2] [2]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Core Network and Terminals; 5G System; User Plane Function Services; Stage 3 (Release 18). Technical Report TS 29.564. 3GPP

work page 2024

[3] [3]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Services and System Aspects; Architecture enhancements for 5G System (5GS) to support network data analytics services; (Release 19). Technical Report TS 23.288. 3GPP

work page 2024

[4] [4]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS); Stage 2 (Release 19). Technical Report TS 23.502. 3GPP

work page 2024

[5] [5]

3rd Generation Partnership Project (3GPP). 2024. Technical Specification Group Services and System Aspects; System archi- tecture for the 5G System (5GS); Stage 2 (Release 19). Technical Report TS 23.501. 3GPP

work page 2024

[6] [6]

Khizar Abbas, Talha Ahmed Khan, Muhammad Afaq, Javier Jose Diaz Rivera, and Wang-Cheol Song. 2021. Network Data Analytics Function for IBN-based Network Slice Lifecycle Management. In 2021 22nd Asia-Pacific Network Operations and Management Symposium (APNOMS). 148–153. doi:10.23919/APNOMS52696. 2021.9562662

work page arXiv 2021

[7] [7]

OpenAirInterface Software Alliance. 2025. OAI 5G Core Network (CN5G). https://gitlab.eurecom.fr/oai/cn5g Accessed: 2025-04- 06

work page 2025

[8] [8]

Abebu Ademe Bayleyegn, Zaloa Fernández, and Fabrizio Granelli

work page