GenioSim: A Novel Simulation Platform for Edge Computing over Optical Networks Carmine Cesaranoa , Alessio Foggiab , Roberto Natellac a KTH Royal Institution of Technology, Stockholm, Sweden b University of Naples Federico II, Naples, Italy c Gran Sasso Science Institute, L’Aquila, Italy
arXiv:2605.10062v1 [cs.NI] 11 May 2026
Abstract The convergence of Passive Optical Networks (PONs) and edge computing creates new opportunities: Optical Line Terminals (OLTs) and Optical Network Terminals (ONTs) can be repurposed as low-latency edge compute nodes for offloading workloads. However, exploring such design options early in the development cycle is costly and time-consuming, as prototyping requires specialized hardware and realistic traffic conditions. Simulation becomes essential, yet current tools are unable to accurately model this emerging class of systems. To address these gaps, we introduce GenioSim, a simulation platform for hierarchical PON-enabled edge infrastructures. It models OLTs and ONTs with realistic PON behavior, supports hybrid container- and VMbased virtualization, and provides multiple service and execution models. These capabilities enable the evaluation of resource management policies under complex, heterogeneous conditions. We present experiments in the context of use cases of industrial relevance, to show GenioSim can provide insights for capacity planning and for the choice of policies for container placement and task offloading in PON-enabled edge infrastructures. Keywords: Simulation, Modeling, Edge Computing, Passive Optical Networks
1. Introduction Passive Optical Networks (PONs) have become the de facto standard for fiber-to-the-home (FTTH) access, with widespread deployment and continued global growth [1]. Optical Line Terminals (OLTs), located in central offices of service providers, serve as aggregation points for multiple user premises over optical fibers. These terminals are typically backed up by commercial off-the-shelf (COTS) components, including x86 CPUs and high-capacity storage hardware, and open-source software (OSS), including operating systems, orchestrators, and virtualization technologies, to run network management functions, such as dynamic bandwidth allocation and control-plane signaling, following the Network Function Virtualization (NFV) paradigm [2]. This trend has sparked growing interest in repurposing the existing PON backend infrastructure to support edge computing workloads. The edge computing paradigm has gained traction as a promising approach to meet increasingly stringent latency and bandwidth requirements, by leveraging computational resources closer to end-users [3]. Specifically, co-locating edge functions alongside the OLT within central offices is now being actively explored by both industry and academia [4, 5, 6], aiming to achieve high-throughput and ultra-low-latency processing capabilities. Consequently, there is a growing need for flexible solutions that design and validate these systems under realistic workloads, resource constraints, and dynamic network conditions. In particular, simulation is a key pillar for the analysis of computer systems, since it enables the evaluation of complex systems before they are physically built, saving time and resources, and
potentially preventing costly errors [7]. Indeed, physical PON testbeds are expensive to build, requiring specialized hardware, complex middleware and software integration, and configuration efforts across multiple layers of the network stack. These high barriers to experimentation limit the ability to rapidly prototype and explore alternative designs, deployment strategies, and orchestration algorithms. Therefore, simulation tools are essential for capacity planning and performance evaluation before committing to costly physical deployments. Despite the availability of edge computing simulators, a critical research gap remains in their ability to model heterogeneous infrastructures, particularly those that incorporate access technologies such as PONs. Existing tools [8, 9, 10] have made significant progress by introducing several features, such as user mobility modeling, modular service composition, and energyaware resource simulation. However, they do not cover well the following three key areas. First, (1) current simulators cannot model complex, hierarchical network topologies, in particular the multi-level infrastructure of PONs, including splitters, Optical Network Terminals (ONTs), and the co-location of compute and network functions within central offices [11]. Second, (2) there is limited support for hybrid virtualization environments: while some tools model workload execution in virtual machines (VMs), they do not reflect setups that combine VMs for the management of physical resources of the PON infrastructure (e.g., to isolate network management functions from edge workloads) and containers, for lightweight isolation between edge applications [12]. Third, (3) most simulators focus primarily on task offloading, where clients upload and execute individual tasks on edge computing servers: however, more
complex business service models deploy long-running applications on edge servers (service placement), to reduce response latency and share resources among multiple service requests [13, 14, 15, 16]. These limitations hinder the ability of existing simulators to experiment with realistic hierarchical orchestration strategies in PON-enabled infrastructures. To address these limitations, we introduce GenioSim, a novel simulation platform. GenioSim is inspired by GENIO (Edge cloud platform enabled by a new intelligent OLT for GPON networks), an industrial R&D project on a new orchestration platform for edge workloads in PON networks [6]. GenioSim supports realistic PON topologies, including ONTs, OLTs, and optical fiber links, as well as their hierarchical relationships. Moreover, GenioSim includes native support for hybrid virtualization, enabling simulations of both containers and virtual machines, and introduces a decoupled execution model in which applications (as containers) and user requests (as tasks) follow distinct workflows. Unlike existing simulators, GenioSim enables the joint evaluation of service placement and task offloading policies over hierarchical PON infrastructures, under heterogeneous resources and multi-layer orchestration constraints. These extensions enable the analysis of adaptive orchestration strategies and workload distribution across realistic PONenabled edge computing scenarios. To demonstrate the capabilities of GenioSim, we present a set of experiments in the context of use cases of industrial interest from the GENIO project. The experiments explore two representative uses of GenioSim: (i) capacity planning, where GenioSim is used to determine the minimum computational resources required in OLTs and ONTs to satisfy applicationspecific latency SLOs; and (ii) orchestration policy evaluation, where GenioSim evaluates how different container placement and task offloading strategies interact with the PON hierarchy and heterogeneous edge resources. Overall, the results show that GenioSim is not only able to model these infrastructures, but also to expose non-trivial trade-offs in capacity sizing, workload distribution, and policy selection. In particular, the experiments show that far-edge resources improve performance only when coordinated through resource-aware and delay-aware orchestration policies, whereas naive proximitydriven choices may degrade both latency and task success rate. To foster reproducibility and broader adoption, we release GenioSim as open-source software1 . The main contributions of the paper are summarized as follows:
The remainder of the paper is organized as follows. Section 2 provides background on PONs, resource orchestration in edge computing environments, and the GENIO project. Section 3 discusses related work. Section 4 presents the design of GenioSim. Section 5 describes the experimental evaluation. Section 6 analyzes the scalability and performance of the simulator. Section 7 discusses limitations of the current model and outlines directions for future work and Section 8 concludes the paper. 2. Background 2.1. Passive Optical Networks Passive Optical Networks (PONs) are widely deployed access technologies for fiber-to-the-home (FTTH) connectivity. A typical PON topology consists of an Optical Line Terminal (OLT) located in the service provider’s central office, multiple Optical Network Terminals (ONTs) at user premises, and passive optical splitters that connect them. The OLT acts as an aggregation point, concentrating user traffic and interfacing with metro or core networks. Although originally designed for broadband access, the hierarchical structure of PON, where lightweight ONTs forward traffic to OLTs, makes them a promising substrate for distributed computing. In particular, OLTs are increasingly equipped with commercial off-the-shelf (COTS) servers and storage, enabling their reuse as edge computing nodes co-located with access infrastructure. 2.2. Edge Computing and Virtualization Models Edge computing extends cloud capabilities by deploying resources closer to end-users, thereby reducing latency and the load on backhaul. In practice, service providers rely on virtualization technologies to manage these resources. Virtual Machines (VMs) offer strong isolation and are typically used to host network management functions and virtualized infrastructure services. Containers, in contrast, provide lightweight isolation with faster startup times, making them suitable for edge applications that require dynamic and fine-grained scaling. Hybrid deployments are increasingly common in telco environments, where VMs and containers coexist: VMs host critical infrastructure services, while containers support user-facing workloads. Modeling this coexistence is essential for a realistic evaluation of edge computing platforms.
• We present GenioSim, a simulation platform for PONenabled edge computing infrastructures with explicit modeling of hierarchical PON topologies. • We implement in GenioSim several strategies for container placement and task offloading, enabling the systematic analysis of orchestration policies for PON-enabled edge computing. • We apply GenioSim for both capacity planning and for the evaluation of orchestration policies on use cases derived from an industrial R&D project.
2.3. Service Placement and Task Offloading Resource orchestration in edge infrastructures involves two complementary processes. Service placement determines where long-lived applications (e.g., containers) are deployed across available nodes. Once deployed, multiple user requests can be served by the same application instance, balancing resource costs. Task offloading, in contrast, occurs at runtime and assigns individual user tasks to one of the available service instances, based on factors such as latency, load, or network conditions. Decoupling placement from offloading enables adaptive orchestration strategies, particularly in hierarchical infrastructures where services may span cloud, edge, and far edge.
1 https://github.com/dessertlab/GenioSim
2
Figure 2: Architectural overview of GenioSim. The modules highlighted in green represent the areas of enhancement with respect to the state-of-the-art.
Figure 1: GENIO Project deployment.
across ONTs and OLTs, while runtime task routing uses DNSbased brokers deployed at OLTs to direct user requests to the nearest or least-loaded service replica. This decentralized routing layer is necessary for telco-scale deployments and must therefore be explicitly modeled in simulation. Together, these characteristics, and the lack of existing simulators that support them, directly motivate the design choices behind GenioSim.
This distinction is critical for supporting realistic workload beyond the simplified task-execution model of existing simulators. 2.4. Genio Project The GENIO project develops an industrial edge-computing platform integrated with PON infrastructures, where computation is distributed across three hierarchical tiers, ONTs at the far edge, OLTs at the edge tier, and the cloud, as shown in Figure 1. ONTs are lightweight devices deployed in customer premises, capable of executing ultra-low-latency tasks or forwarding them upstream. OLTs, traditionally used for PON management, are repurposed as compute-capable edge hubs based on x86 COTS hardware and extended with an SDN stack to dynamically manage access-network traffic and multi-tenant resources. The cloud tier provide high-capacity computing and hosts the global orchestrator responsible for service placement, resource management, and cross-OLT coordination. A defining characteristic of GENIO is the coexistence of hybrid virtualization, where VM-based isolation (managed via KVM and Proxmox) is complemented by container-based deployments for business applications (managed via Kubernetes). This mixed model reflects real operational constraints: infrastructure services require strong VM isolation, while tenant applications demand lightweight, cloud-native deployment models. Consequently, GENIO applications may run in dedicated VMs, containers inside VMs, or shared container pools, making hybrid virtualization essential for any simulator aiming to evaluate realistic placement and offloading decisions. GENIO targets industrial and telco-grade workloads, including IoT analytics, computer-vision pipelines, smart-building monitoring, ML inference services, and multimedia streaming. These applications exhibit heterogeneous compute demand, latency SLOs, and user access patterns, often with bursty workloads and multi-tenant sharing. The platform adopts a serviceoriented model in which long-running containerized services are deployed once an then repeatedly invoked by multiple users, a key difference from simulators where tasks implicitly instantiate their own execution environment. Another crucial architectural trait is hierarchical orchestration: the cloud decides where services (containers) are placed
3. Related Work Cloud and Edge Computing Simulators. Simulation is widely used to evaluate edge infrastructure and orchestration strategies before deployment, complementing costly and less flexible testbeds. CloudSim and derivatives focus on datacenter resource management with abstracted networks and no edge devices [17]. Edge-oriented simulators, including EdgeSimPy, EdgeCloudSim, iFogSim/iFogSim2, FogNetSim++, YAFS, LEAF, ENIGMA, MyIFogSim, and PureEdgeSim extend this paradigm to three-tier (cloud, edge, device) settings ans support task-based workloads and placement mechanisms [10, 8, 18, 19, 20, 21, 22, 23, 24, 9]. However, these tools rely on simplified resource and network abstractions and primarily target consumer scenarios rather than industrial deployments [25, 26, 27, 28, 29]. PureEdgeSim is most relevant due to its modular architecture [9], but its network, virtualization, and orchestration models cannot capture the PON-enabled, cloudnative, multi-tenant settings targeted by GENIO. GenioSim extends PureEdgeSim to address these gaps. Network and Access Infrastructure Modeling. Simulators differ widely in network modeling: FogNetSim++ and YAFS offer flexible topologies [20, 21], yet most tools still represent communication through coarse bandwidth, such as delay links without detailed lower-layer or access-technology behavior [25, 26]. This abstraction is problematic for industrial edge computing like GENIO, where PON is central. Existing simulators, including iFogSim, EdgeCloudSim, YAFS, and PureEdgesim, assume that flat networks in which devices directly connect to edge/cloud nodes, omitting ONT-OLT hierarchies and fiber aggregation [18, 8, 21, 9]. Even energy-focused tools like LEAF 3
lack PON-specific entities [22, 27]. Research on multi-access edge computing and network softwarization highlight the importance of optical access [30, 31], but these works provide algorithms, not reusable simulation environments. No existing simulator explicitly models ONTs/OLTs or PON congestion. GenioSim fills this gap by introducing ONTs/OLTs and optical links with configurable latency, bandwidth, and energy.
eling. This integrated design enables realistic evaluation of orchestration strategies in PON-enabled industrial environments. 4. GenioSim Design GenioSim has been designed to overcome limitations of existing edge computing simulators. As discussed in the previous section, other simulators cannot accurately represent access technologies and complex orchestration models, thus falling short in modeling the industrial use cases targeted by the GENIO project. To address these gaps, the design of GenioSim is guided by four requirements:
Virtualization and Cloud-Native Modeling. With cloud-native architectures becoming standard, containers and Kubernetesbased orchestration dominate modern edge deployments, while hybrid VM+container environments remain common [32, 33, 34, 35]. Existing simulators remain VM-centric: CloudSim and derivatives treat VMs as the main compute unit [17], and EdgeCloudSim and iFogSim variants similarly execute tasks directly on hosts or VMs without explicit container modeling [8, 18, 19]. Calls for first-class support of containers, VMs, and serverless functions remain largely unmet [36]. GenioSim adds a hybrid virtualization layer where containers run inside VMs at OLTs and ONTs, modeling hypervisor overhead through a new network-level abstraction and configurable XML-based deployment policies.
1. Realistic modeling of PON-enabled infrastructures: capturing the hierarchical structure of PON, including ONTs, OLTs, and fiber optic links. 2. Support for hybrid virtualization: enabling coexistence of VMs and containers, reflecting cloud-native deployments. 3. Hierarchical orchestration: decoupling high-level service placement from task execution, distributed across cloud, edge, and far-edge tiers. 4. Realistic workload and user modeling: supporting longlived services, multi-tenancy, and heterogeneous user behaviors.
Orchestration and Request Dispatch. Edge simulators such as FogNetSim++, iFogSim, and EdgeCloudSim implement placement and scheduling policies accounting for node utilization and application latency [20, 18, 8], but typically assume centralized controllers and shallow hierarchies [26]. A major limitation is the lack of joint modeling of service placement and request dispatch: placement is studied in isolation from routing, despite their tight coupling [37]. Centralized cloudnative schedulers also conflict with multi-tier edge environments [38, 37, 30]. Hierarchical orchestration schemes have been proposed [39, 31], but focus on algorithms rather than simulation frameworks. GenioSim introduces hierarchical orchestration with separate placement (ContainerOrchestrator) and task-offloading (TaskOrchestrator) layers, coordinated via DNS-based brokers deployed on OLT servers.
These requirements extend PureEdgeSim into a PON-aware, cloud-native simulation environment that aligns with the needs of the GENIO project, addressing the gaps identified in Section 3. GenioSim adopts a system-level simulation approach, following the design philosophy of other popular simulators such as CloudSim and PureEdgeSim [17, 9]. Rather than modeling network behavior at the packet level, the simulator focuses on application-level aspects relevant for edge orchestration studies, such as service placement, task offloading, and resource allocation across heterogeneous nodes. This abstraction enables the exploration of orchestration strategies in large-scale PONenabled edge infrastructures while maintaining practical simulation scalability.
Workload and User Modeling. Existing tools typically model workload as independent tasks defined by arrival rates rather than long-lived applications [8, 18]. These approaches inadequately capture industrial workloads exhibiting complex, bursty, multi-tenant dynamics [27, 29, 28]. GenioSim separates services from users: services are persistent containers with configurable resource and network footprint, while user profiles define heterogeneous access patterns, burstiness, and temporal behavior, enabling realistic multi-tenant and session-based dynamics.
4.1. Architectural Overview GenioSim builds on a modular architecture that separates simulation control, infrastructure modeling, workload generation, networking, orchestration, and scenario configuration. Figure 2 illustrates the main modules and highlights the components that extend or replace those of earlier simulators such as PureEdgeSim [9] and CloudSim [17]. While retaining this modular foundation for compatibility and extensibility, GenioSim introduces a set of targeted enhancements that involve multiple modules.
Positioning of GenioSim. To sum up, existing simulators lack (i) PON-aware access hierarchies, (ii) hybrid VM-container modeling, (iii) joint placement-offloading designs, an (iv) realistic user-modeling and multi-tenant workload. GenioSim extends PureEdgeSim with explicit PON entities, hybrid virtualization with hypervisor-aware overhead, hierarchical orchestration with DNS-based brokers, and decoupled service/user mod-
Simulation Manager. Handles the global event loop, lifecycle timing, and initialization of containers and tasks. Unlike previous simulators, it supports decoupled service placement and task execution, allowing long-running services to be deployed independently of user-generated requests. 4
Figure 3: Comparison of network topologies supported by PureEdgeSim (left) vs. GenioSim (right).
Each edge device is paired with an ONT, which acts as a lightweight far-edge node. ONTs forward traffic to OLTs, which aggregate flows and act as edge-level computing hubs. The Network Module includes optical fiber links as configurable connections with tunable parameters to represent latency, bandwidth, and energy consumption. Figure 3 shows the differences between PureEdgeSim and GenioSim with respect to the modeled network topologies.
Server Manager. Models compute resources at the cloud, edge, and far-edge layers. GenioSim extends this module with explicit PON-aware entities (ONTs, OLTs), hierarchical resource organization, and a hybrid virtualization layer where VMs host containers. Network Module. Represents communication across hierarchical PON topologies, including ONT–OLT relationships and optical fiber links. Link models include configurable latency, bandwidth, and energy, enabling realistic bottleneck and congestion behavior.
GenioSim introduces brokers, based on the DNS protocol. These entities act as intermediaries between end-users and services, by routing each user request towards the service instance that will handle it, and balancing the load among instances. These DNS-based brokers do not provide computational resources, but only handle routing and load balancing. They are hosted on OLT servers at the edge layer.
Task Orchestration Module. Implements hierarchical orchestration by separating container placement from task offloading. Placement determines where services reside; offloading determines, at runtime, how tasks flow through ONTs, OLTs, and DNS-based brokers.
In the following sections, we detail the main characteristics that differentiate GenioSim from prior simulators.
This design mirrors the GENIO platform, where DNS-based routing is used as a lightweight, decentralized, and highly scalable mechanism for directing user requests across the telco edge. DNS provides a fault-tolerant method for mapping service names to dynamically changing service endpoints without relying on centralized controllers or heavy service meshes, scales naturally to multi-OLT deployments, and enables fast traffic redirection under dynamic placement changes, failures, or load variations.
4.2. PON-enabled Modeling In previous simulators, such as PureEdgeSim, the Network Module models communication as a flat structure, where devices are directly connected to cloud or edge data centers. Bandwidth allocation adapts dynamically to load, but the model lacks hierarchical access topologies as those found in PONs. In GenioSim, the Server Manager and the Network Module explicitly represent the entities of PON infrastructures.
By explicitly modeling in detail how user requests traverse ONTs, OLTs, DNS brokers, and upstream links, GenioSim supports fine-grained analysis of traffic distribution, dynamic workload redirection, and the interplay between placement decisions and runtime task offloading. This design makes it possible to capture congestion phenomena across the PON infrastructure, including overloads and bottlenecks at ONTs, OLTs, DNS brokers, and fiber access links.
Scenario Manager and Task Generator. Provide a high-level configuration interface (via XML) for defining applications, container properties, replica placement, and heterogeneous user behavior. This supports multi-tenant and bursty workloads reflective of real deployments.
5
GenioSim introduces a hierarchical orchestration model that explicitly separates service placement from task offloading, aligning the simulator with real-world PON-enabled architectures and GENIO’s service subscription paradigm:
4.3. Hybrid Virtualization In PureEdgeSim, the Server Manager models data centers, servers, and VMs, but does not support explicit containerization. Tasks are executed directly on hosts or VMs, limiting the ability to simulate cloud-native deployments. GenioSim provides a Server Manager with a hybrid virtualization layer, where containers can be deployed inside VMs hosted on OLTs and ONTs (Figure 4). This layered model mirrors realworld PON-based infrastructures where VMs provide strong isolation for infrastructure services and containers support the lightweight, flexible deployment of edge applications.
• Service placement: a global orchestrator determines where each service replica is deployed, across cloud nodes, OLTs, or ONTs. Services are represented as long-lived containers whose lifecycle (deployment, migration, removal) is independent of user activity. • Task offloading: at runtime, user requests are routed by DNS-based brokers, which select the most suitable service replica based on current latency, load, and resource availability. In this paradigm, operators deploy applications as longrunning services, while clients subscribe to them and subsequently issue tasks (Figure 5). The GenioSim event model reflects this separation: the Simulation Manager schedules container lifecycle events independently of task arrivals, and the Task Orchestration module maintains two distinct flows, one for managing service placement and another for computing per-task offloading decisions.
Figure 4: Hybrid virtualization in GenioSim, where containers are deployed inside VMs hosted on OLTs.
To enable this model, the Network Module introduces a new hypervisor link abstraction that connects containers to their hosting VM. This link accounts for configurable latency and energy overheads associated with hypervisor mediation, which were ignored in PureEdgeSim. These costs are explicitly reflected in task execution times, allowing experiments to capture the trade-offs between isolation and performance. As a result, GenioSim supports fine-grained comparison between different deployment choices: pure VM execution, pure container execution, or mixed setups. Configuration files in XML format specify VM capacity, container allocation policies (private vs. shared), and the number of replicas, enabling the exploration of virtualization strategies that affect resource efficiency and QoS. Figure 5: Service subscription model in GenioSim. Operators deploy applications as containers at the Cloud level, while clients subscribe to services and issue tasks through the Edge.
4.4. Hierarchical Orchestration One of the requirements in the GENIO project is the ability to support hierarchical orchestration, where long-lived services are deployed independently of the short-lived user requests that consume them. In PureEdgeSim, the Task Orchestration Module couples these two dimensions: tasks are served by instantiating a job on demand on an edge server, thereby conflating service creation with request execution. This prevents modeling realistic cloud-native deployments where services run continuously, are reused by multiple clients, and where task arrivals occur at a high rate. It also contradicts GENIO’s operational model, where services are provisioned once and then shared across many users.
Decoupling service placement from task offloading requires introducing dedicated abstractions, different from previous simulators. In GenioSim, containers are now first-class entities, distinct from tasks. They are instantiated through a dedicated ContainerGenerator that supports both shared instances (i.e., container instances can serve multiple clients) and private instances (i.e., each instance serves a single client). Applications explicitly reference container attributes in addition to task parameters, while a new ContainerTransferProgress class captures the impact of container deployment on network 6
Figure 6: Routing of service placement requests in GenioSim. Operator deployments are sent to the Cloud orchestrator, which selects target nodes (OLTs/ONTs) and distributes container images accordingly. Placement updates are propagated to DNS brokers and subscribed clients.
Figure 7: Routing of task execution requests in GenioSim. Clients submit tasks to the nearest OLT-side DNS broker, which selects the optimal service replica based on placement state, resource availability, and offloading policy.
This approach is computationally lightweight and deterministic; however, it can still overload nodes with less computational capacity and create suboptimal paths between users and containers. Round Robin scheduling is widely used in operating systems and cloud orchestration systems [40].
bandwidth. Core modules were adapted to reflect this separation. The Task Generator now produces tasks independently of containers, with private tasks only enabled after the associated container is placed. The Simulation Manager initializes container placement prior to task generation, reflecting operator-driven deployment followed by client-driven execution. The Server Manager maintains per-node container queues, constrained by memory and storage resources. Orchestration responsibilities are split between a cloud-level ContainerOrchestator, which manages placement and lifecycle events, and an edge-level TaskOrchestrator, which handles runtime offloading in line with current container distribution. GenioSim adopts a request routing model designed to reflect hierarchical orchestration. The simulator models two types of requests: (1) requests for service placement, made by service operators, in which container images flow from the Cloud to OLTs, with notifications propagated to DNS brokers and clients (Figure 6); (2) requests for task execution, in which end-users send requests to a service, using DNS brokers to resolve the container instance for processing the request (Figure 7). By introducing hierarchical orchestration, GenioSim captures the separation of placement and execution required by GENIO, and enables fine-grained analysis of orchestration policies under realistic container lifecycles and load dynamics.
CPU-Greedy. It applies a per-core, count-based greedy rule that selects the node with the lowest ratio between the number of currently assigned containers Ci and the total number of CPU cores Ni . In the event of a tie, the algorithm prefers the node with a higher number of cores. This heuristic performs fast, low-overhead decisions that roughly balance container counts in proportion to core counts. However, the objective is not resource- or utilization-aware, since it disregards available memory, storage, and per-core MIPS, potentially leading to suboptimal placements under heterogeneous nodes and varying container demands. Formally, the selected node minimizes the ratio defined in Equation 1. This heuristic is first introduced in this work. Fi =
Ci Ni
(1)
Trade-Off. It selects the node that minimizes a topologyweighted queueing cost function that approximates the expected completion time. For each node i, the cost Fi grows linearly with the current number of assigned containers Ci and the size of the incoming task S t , and decreases with the node’s percore processing power MIPS i (Million Instructions per Second). A topology-dependent weight ti penalizes nodes in the cloud layer and favours nodes in the edge and far-edge layers (i.e., ONTs and OLTs) in the selection process. This heuristic is resource-aware (in terms of per-core MIPS and task size) and topology-aware. Still, it overlooks memory and storage availability as well as total core count, which may lead to underutilization of multi-core nodes. The node with the lowest cost is selected for allocation. Formally, the cost function is defined
4.5. Orchestration Strategies: Placement The following four service placement algorithms are implemented in GenioSim. Each algorithm defines a heuristic for selecting the best computing node, where a container should be deployed. Round Robin. The algorithm cycles through the list of available computing nodes and assigns each new container to the next node in order, without considering resource capacity, load, or network conditions. All nodes are treated uniformly. 7
in Equation 2. This heuristic was originally introduced in the PureEdgeSim simulator [9]. Fi = (2Ci + 1) · ti ·
St MIPSi
the Latency-based and Rate-based variants first identify the best host among multiple OLTs and ONTs and then optimize placement locally within that host according to network proximity and load proportionality, respectively.
(2)
4.6. Orchestration Strategies: Offloading
Multi-Objective. It maximizes a resource-aware and topologyaware availability score over feasible nodes. For each node i, the score S i aggregates normalized available resources R, including RAM, storage, number of CPU cores, and per-core MIPS, and penalizes nodes with a large number of active containers Ci . A topology bias term ti assigns a lower penalty to nodes in the edge and far-edge layers (e.g., ONTs and OLTs) and a higher one to nodes in the cloud layer. This weighted-sum approach captures both computational heterogeneity and topology preference, albeit at the cost of higher decision overhead and complexity compared to the CPU-greedy approach. The node maximizing the score defined in Equation 3 is selected for allocation. This heuristic is first introduced in this work. ! X Ri,avail − C i − ti . (3) Si = wR Ri,tot {RAM, storage, R∈
The following task offloading algorithms are implemented in GenioSim. Each algorithm defines how user requests (tasks) are routed to containers that run the required service. Round Robin. This algorithm distributes incoming tasks across all container instances of the same application in cyclic order. Each new task is forwarded to the next container in the sequence, independently of the container’s location, load, or execution delay. This ensures fairness and negligible scheduling overhead, but does not exploit differences in network latency or node performance, which may result in suboptimal offloading decisions. Best Latency. This algorithm assigns each task to the container instance that offers the lowest end-to-end network latency from the task’s originating edge device. If multiple containers have the same minimum latency, it selects among them the one with the fewest currently assigned tasks. This strategy is networkaware but largely load-agnostic, balancing load only when latency ties occur. This heuristic is first introduced in this work.
cores, MIPS/core}
Each of these algorithms has three variants, which differ in how they determine the scope of the placement decision. • Standard variant applies the algorithm globally across all computing nodes in the topology (including those in the cloud, OLTs, and ONTs) to directly select the best node for placement. The other two variants (Latency-based and Rate-based) adopt a two-level decision process that involves multiple OLTs and ONTs. First, they evaluate all potential hosts, that is, all OLTs and ONTs in the simulated topology, to determine which ones are the most suitable to host the container.
Best Delay. This algorithm extends the best latency strategy by accounting for both communication delay and an approximation of execution delay on the destination node. For each container instance i implementing the required application, it computes the network latency Linet from the task’s originating edge device to the container’s hosting node. It estimates the execution delay by summing the compute demand S t of all tasks already queued on that node (plus incoming tasks), dividing by the node’s per-core processing capacity MIPS i , and normalizing by the number of CPU cores Ni . This strategy is explicitly delay-aware, combining network and processing delays. The task is dispatched to the container that minimizes the predicted delay, as defined in Equation 4. This heuristic is first introduced in this work.
• Latency-based variant analyzes, for each OLT, the mean network latency between containers currently deployed on that OLT and end-user devices associated with that container, selects the OLTs with the lowest average latency, and among them chooses the one currently hosting the fewest containers of the same type. • Rate-based variant measures, for each OLT, how many edge devices are already connected and how many container copies of the same type are already deployed, then selects the OLT with the lowest ratio between deployed copies and associated devices.
Each offloading algorithm is evaluated in two modes, which determine how often the offloading destination is recomputed.
After this host-selection phase, the chosen OLT (or ONT) becomes the local placement scope. The corresponding base algorithm (Round Robin, Trade-Off, CPU-Greedy, or MultiObjective) is applied within that host’s associated computing nodes (e.g., VMs in the case of OLTs or the physical node itself in the case of ONTs) to select the final target node for container deployment. In summary, the Standard variant optimizes placement globally across the entire infrastructure. In contrast,
• Static mode associates each edge device with a fixed offloading node the first time it generates a task. This mapping is stored and reused for all subsequent tasks from that device. As a result, offloading decisions incur negligible runtime overhead but cannot adapt to changes in network latency, node load, or task queue lengths. Static mode, therefore, prioritizes stability and speed over responsiveness.
P Di = Linet +
8
S new St t∈Qi ( MIPS i ) + MIPS i
Ni
(4)
• Dynamic mode recomputes the offloading decision for every incoming task. The system evaluates the selected offloading algorithm (Round Robin, Best Latency, or Best Delay) each time by inspecting current network conditions, container placement, and queue state. This enables fine-grained responsiveness to transient load and latency fluctuations, but introduces additional control-plane computation.
support edge computing workloads. First, we experiment on capacity planning, where we use GenioSim to determine the minimum computational resources required to sustain full task completion under application-specific latency constraints. Second, we conduct an experiment to compare orchestration policies, where we use GenioSim to assess how different placement and offloading strategies affect overall system performance. These experiments represent two relevant use cases for the proposed tool. The experiments use GenioSim to reproduce PON-based edge computing deployments, where we measure both the Task Success Rate (TSR), i.e., the fraction of tasks completed within the application-specific latency bound, and the end-to-end latency, defined as the time between the submission of a task from the user and its completion.
4.7. Workload and Users Modeling In previous simulators, such as PureEdgeSim, the workload is represented by tasks, which are modeled using parameters like task size (e.g., in terms of CPU instruction counts needed to process the task) and rate of task arrival. However, as previously discussed, this approach does not fit well with longrunning services, which process multiple requests once they are instantiated, and which are deployed in multi-tenant infrastructures. Moreover, real-world industrial applications often involve various users with heterogeneous behavioral profiles. GenioSim provides a richer modeling of workloads and users, by clearly separating services from their users, and allowing multiple user behavioral profiles. In particular, this modeling involves the Task Generator and the Scenario Manager modules. On the one hand, application services are modeled as containers, with configurable properties such as memory and storage requirements, bandwidth footprint, number of replicas, and whether a container instance is shared among multiple users. Containers persist as long-lived services, enabling evaluation of lifecycle events such as creation, scaling, and removal. Users, on the other hand, are defined through separate profiles, which specify application type, access pattern (random, bursty, or periodic), request rates, and temporal behavior (start time, active periods, idle intervals). This fine-grained configuration enables the reproduction of realistic workload dynamics, including diurnal cycles, sudden bursts of demand, and sessionoriented behavior. By decoupling user activity from application instances, GenioSim enables heterogeneous, multi-tenant environments where users compete for shared services. This design supports simulations of stressful and highly variable workloads, such as bursty video on-demand streaming and ML-based event processing patterns. Together, these extensions provide a much richer workload model than PureEdgeSim, enabling practitioners to investigate orchestration strategies under conditions that mirror real-world variability and peak loads.
5.1. Application Scenarios Different edge applications are modeled by tuning the simulation parameters, which are derived from prior works that emulate realistic edge computing scenarios [6, 9, 41, 42]. These parameters are confirmed by empirical data provided by the industrial partners of the GENIO project. We model several application scenarios with distinct computational intensities and latency service-level objectives (SLOs). These scenarios capture diverse workload characteristics, with some compute-demanding tasks and others involving data-intensive exchanges. In contrast, others generate frequent request bursts, thereby reflecting the heterogeneity typical of real-world edge deployments. For the experiment on capacity planning, we consider five different applications: S1 Smart City: 128 users representing connected streetlight nodes supporting urban monitoring services; S2 E-Health: 10 users representing remote patients equipped with continuous health monitoring devices; S3 Smart Building: 20 users representing surveillance and analytics endpoints within an intelligent facility; S4 Sports Streaming: 60 users representing simultaneous viewers of live multimedia content; S5 Video Gaming: 80 users representing participants in interactive cloud-gaming sessions. In addition, for orchestration strategy evaluation, we define a Mixed scenario that combines all five baseline applications into a single multi-tenant setup with a total of 298 users, generating heterogeneous and time-varying demand representative of realistic industrial deployments. Table 1 summarizes the main parameters of each scenario, including task rates, latency SLOs (column “Max latency”), computational demand (columns “Request size” and “Task length”), response size, and number of active users, thus defining the five baseline workloads used in our experiments.
Overall, the enhancements provided by GenioSim bridge the gap between edge computing simulators and the unique requirements of PON-enabled infrastructures. This approach enables designers and researchers to evaluate orchestration strategies under realistic network, virtualization, and application conditions.
5.2. Capacity planning Objective. We aim to determine the minimum computational capacity required to sustain 100% TSR for each application when deployed on a single OLT in isolation, and to quantify
5. Experimental Analysis This section presents experiments using GenioSim to evaluate how well PON-enabled, hierarchical infrastructures can 9
Table 1: Simulation parameters for the application scenarios
Active Users Task rate (task/min) Max latency (s) Task length (MI) Request size (KB) Response size (KB)
time, over five independent runs; average results across runs to obtain stable statistics.
S1
S2
S3
S4
S5
128 2 0.5 500 1 10
10 60 0.05 1,000 10 10
20 60 0.2 5,000 750 500
60 20 0.5 5,000 750 500
80 180 0.05 100 10 10
Results. Figure 8 presents, for each application scenario: (1) mean latency achieved by the different CPU classes for both Edge-only and Far Edge + Edge deployments (bars), and (2) task success rate (TSR) achieved under the same configurations (overlaid as lines). These values are reported for different CPU classes. The computation capacity of each CPU is provided on the bottom of each plot. Since applications differ in computational load and latency sensitivity, the resource capacity needed to meet SLOs varies across scenarios. Overall, lighter workloads benefit from faredge execution, while compute-intensive or latency-sensitive applications remain OLT-bound. Smart City always achieves 100% TSR due to its low computational demand (500 MI per task). Allowing ONTs to execute tasks further reduces latency by supplementing OLT capacity and minimizing network traffic. E-Health, Smart Building, and Sport Streaming exhibit monotonic improvement as the capacity of the OLT increases, as TSR increases, and latency decreases. Transitioning from Edge-only to Far-Edge + Edge provides marginal gains, since these applications typically execute at the OLT to meet moderate SLOs (0.05–0.5 s) with stable compute performance. Video Gaming poses the most demanding scenario. At low OLT capacities, Far-Edge + Edge increases task failures, as ONTs admit tasks but are frequently unable to process all of them, resulting in inflated service times and missed deadlines. In contrast, Edge-only avoids overloads and achieves lower latency under the same OLT capacities.
how extending computation to the far edge (ONTs) affects both TSR and latency. The success criterion is the smallest OLT capacity that maintains 100% TSR throughout the experiment duration while meeting the application’s latency SLO. Experimental Setup. We simulate a single-OLT topology centered in the simulation region, with its associated ONTs representing the far-edge layer. The OLT models a physical x86class host with 8 cores, serving as the upper-tier edge node, consistent with the hardware configuration already deployed in OLT systems by our industrial partner [43]. Each core’s computational capacity, expressed in MIPS, is varied across experiments to emulate different commercial CPU classes (see the next paragraph on Methodology). On top of this physical OLT, we instantiate four VMs, each allocated two of the physical cores. The aggregate computational capacity of the OLT is therefore divided among these VMs, whose per-core MIPS values are adjusted to reflect the characteristics of the CPU being emulated. Each ONT emulates a Raspberry Pi 4 Model B–class device with four cores at 12,000 MIPS/core, representing faredge resources close to end users. The number of instantiated ONTs matches the active user count in the selected application scenario (Section 5.1). We evaluate two deployment configurations: (1) Edge-only, where all tasks are executed on OLT VMs; and (2) Far-Edge + Edge, which allows ONTs to execute tasks locally when resources are sufficient. All experiments use single-application workloads to isolate capacity effects and avoid inter-application interference. Container placement follows the Trade-Off policy, and task offloading uses a Round-Robin strategy, providing a conservative baseline for capacity estimation. Each simulation runs for 300 minutes of simulated time.
Takeaways: (i) Capacity planning is application-specific; simulations can guide the selection of the minimal hardware resources needed to meet application requirements. (ii) Distributing the load on the far-edge is effective to reduce latency for light workloads with sufficient ONT capacity. Still, more complex workloads with strict time constraints do not necessarily benefit from the far edge. (iii) For heavy computational workloads (e.g., gaming), introducing the far edge can expose to task failures (i.e., TSR degradation), which needs to be enforced through conservative task admission.
5.3. Comparison of Orchestration Policies Objective. We quantify the impact of container placement and task offloading strategies on TSR and latency under heterogeneous, bursty workloads in a multi-OLT deployment. The goal is to identify policy combinations that sustain high TSR while minimizing latency.
Methodology. To evaluate the OLT’s computational capacity requirements, we systematically vary its total capacity processing power to match the performance of five representative commercial x86 CPU classes. For each class, we assign a per-core MIPS value derived from the Sandra Dhrystone benchmark [44] and scale it across the OLT’s eight cores. The ONT resources remain constant throughout. For each application and deployment model, we proceed as follows. We configure the OLT with the target CPU capacity and GenioSim instantiate resources to simulate (including VMs); initialize container placement and execute the workload; record TSR and mean end-to-end latency during the simulated
Experimental Setup. We simulate a topology with three OLTs, and devices on the far edge evenly distributed among the OLTs. Each OLT provides 14 physical cores (95,000 MIPS/core) for a total of 1.33 million MIPS per OLT. The far-edge layer consists of ONTs following the same hardware modeling as described in the previous experiment. In this case, each OLT hosts 7 VMs (two cores each). The far-edge layer includes one ONT per 10
and Far-Edge+Edge) used previously. The workload, however, is now heterogeneous, combining all five application scenarios to generate concurrent and bursty task arrivals representative of realistic multi-tenant conditions. Methodology. For each simulation, a placement algorithm and an offloading algorithm are selected together with their respective variants. We evaluate 12 placement strategies (4 algorithms × {standard, latency-based, rate-based}) and 6 offloading strategies (3 algorithms × {static, dynamic}), totaling 72 policy combinations. Each combination is executed five times per deployment model, yielding 720 simulations in total. Placement and offloading mechanisms are implemented as described in the Sections 4.5 and 4.6. For each run, we record the TSR and mean latency. TSR is computed as the ratio of completed tasks to the total number of submitted tasks, providing a global measure of orchestration efficiency. Latency is collected per application and normalized by its respective target SLA (Table 1) to ensure comparability across applications with different latency scales. The normalized values are then averaged to yield a single representative latency per policy combination (Lnorm ). Consequently, latency values reported here represent SLA-normalized averages and are not directly comparable to the raw latency results from the provisioning experiment. Results for Edge-Only. Figure 9 presents heatmaps of TSR and normalized latency for all combinations of offloading and placement strategies obtained under the edge-only deployment; rows list the offloading algorithms (Round Robin, Best Latency, Best Delay; static/dynamic modes) and columns group the placement algorithms (Round Robin, Greedy, Trade Off, Multi-Objective; Standard/Latency-based/Rate-based variants). Each cell reports the mean value over five runs. All policies under the Edge-only configuration maintain full SLA compliance, with normalized latencies ranging between 0.30 and 0.41 (mean ≈ 0.35). The narrow latency range indicates that, in a compute-rich environment, placement and offloading choices have only a secondary impact on performance. Among offloading variants, Best Delay (BD) consistently achieves the lowest normalized latencies (around 0.30–0.31), owing to its explicit estimation of end-to-end service time (Lnet + Qwait + S t /MIPS). Best Latency (BL) also performs well but yields slightly higher delay (∼ 0.34–0.36) since it ignores queuing effects and may offload tasks to temporarily busy nodes. For placement, both latency-based and rate-based variants reduce the average latency by roughly 7–10% compared to their standard counterparts by biasing container deployment toward nearby or lightly loaded nodes. Dynamic offloading yields a modest additional benefit (∆Lnorm ≈ −0.01), as per-task adaptation smooths transient load peaks across VMs. Regarding the success of tasks, all Edge-only configurations achieve high TSR between 91.7% and 97.6% (mean ≈ 94.4%). Differences in TSR follow offloading strategy more than placement: BL variants deliver the highest completion rates (up to 97.6%), while BD and RR are slightly lower (∼ 94–95%). This
Figure 8: TSR and end-to-end latency across CPU capacity sweeps for Edgeonly and Far-Edge + Edge deployments, evaluated over five application scenarios. When only one TSR curve is shown, the two deployments produce overlapping results.
user, for a total of 298 ONTs corresponding to all users in the Mixed workload (Section 5.1). We evaluate the same two deployment models (Edge-only 11
Figure 9: Comparison of TSR (top) and normalized latency (bottom) across all combinations of offloading and placement strategies when used in edge-only deployment. Each cell reports the mean over five runs.
reflects BL’s bias toward low-latency OLT nodes, which minimizes queueing losses under the high workload intensity of this scenario. Dynamic offloading slightly improves TSR but with marginal average gains (< 1 percentage point). Latency- and rate-based placement variants raise TSR by about 1–2% relative to standard ones through improved task-to-container locality. Overall, the Edge-only configuration confirms that with sufficient OLT capacity, all orchestration strategies can satisfy SLA constraints, and performance differences mainly stem from the adaptability of the offloading policy rather than placement limitations.
leverages heterogeneous compute resources. Latency- and ratebased variants clearly outperform the base algorithms, reducing latency by roughly 8–10% on average, by aligning container placement with node proximity and available capacity. In contrast, the base algorithms often distribute containers arbitrarily, causing tasks to traverse multiple network hops or accumulate at ONTs, which have lower computational capacity. Offloading decisions amplify these effects: static policies perform consistently worse than dynamic ones, as their fixed routing cannot respond to transient congestion and load imbalances. Dynamic offloading lowers mean latency by 5–10% across most strategies, especially when paired with delay-aware offloading.
Results for Far-Edge+Edge. Figure 10 shows the corresponding heatmaps for the Far-Edge + Edge deployment. Introducing the Far-Edge layer heavily changes latency dynamics. Normalized latencies now span a wider range (0.29–1.59), and only about half of the policy combinations satisfy the SLA condition (Lnorm < 1). Average latency across all algorithms increases to approximately 0.78, exhibiting a bimodal distribution: MultiObjective and Trade-Off placements consistently remain below SLA (mean Lnorm ≈ 0.34), while Round-Robin and CPUGreedy variants incur persistent violations (Lnorm ≈ 1.1–1.6). This divergence stems from how each placement algorithm
TSR trends mirror the latency distribution. The mean TSR across all policies decreases to about 91%, but again splits by algorithm: Multi-Objective and Trade-Off placements achieve near-perfect reliability (up to 100% TSR), while Round-Robin and Greedy collapse below 80%. Policies combining latencyor rate-based placement with dynamic BD offloading dominate the high-performance region. In contrast, proximity-only (BL) strategies show the lowest TSR, down to 72%, as they overadmit tasks to resource-constrained ONTs, resulting in servicetime overruns and deadline misses. These findings confirm 12
Latency-based variant
Rate-based variant 89.34
89.33
94.28
97.43
BEST LATENCY
72.75
75.78
94.50
97.23
76.73
77.62
97.49
100.00
75.50
77.40
97.71
99.99
BEST DELAY
88.08
87.35
94.57
97.41
88.30
88.55
96.08
99.99
87.86
88.14
96.27
100.00
ROUND ROBIN
90.59
90.53
93.19
96.16
90.58
90.49
93.88
97.84
90.57
90.59
93.93
97.95
BEST LATENCY
72.47
76.18
94.66
97.11
75.77
76.31
97.57
99.99
75.31
77.30
97.80
100.00
BEST DELAY
90.57
90.35
94.83
96.83
90.61
90.64
95.96
100.00
90.62
90.64
96.06
100.00
95 90 85 80 75
CT IV
FF MU
LTI
OB JE
EO TR AD
EE GR
IN OB DR
OB JE LTI MU
RO UN
CT IV
FF EO TR AD
EE GR
IN OB DR
OB JE LTI
RO UN
CT IV
FF EO MU
TR AD
EE GR
OB DR RO UN
100
E
97.53
DY
94.02
E
89.83
DY
89.30
E
95.83
DY
93.97
IN
89.32
Average TSR (%)
89.36
Dynamic mode
ROUND ROBIN
Static mode
Offloading Algorithm
Standard variant
Figure 10: Comparison of TSR (top) and normalized latency (bottom) across all combinations of offloading and placement strategies when used in Far-Edge + Edge deployment. Each cell reports the mean over five runs.
that, in heterogeneous edge hierarchies, compute-awareness outweighs mere proximity: effective orchestration must pair placement guided by node capacity with offloading that reacts to current service delay.
wise, proximity to the user paradoxically increases end-to-end latency due to queuing effects. The observations above can be summarized through the following key insights regarding orchestration policies in PONenabled edge infrastructures. In particular, the experiments show that the best performance is achieved by combining compute-aware placement strategies such as Multi-objective or Trade-Off with dynamic Best Delay offloading, which jointly account for node capacity, queueing delay, and network latency.
Comparison between deployment models. Comparing the two deployment models shows that adding far-edge nodes does not necessarily improve latency and task success, unless appropriate orchestration policies are applied to account explicitly for the Far-Edge+Edge deployment model. The average variation in terms of success rate (∆TSR) from Edge-only to FarEdge+Edge is −3.3 percentage points, and the average ∆Lnorm is +0.43. However, the best policies, which are the MultiObjective or Trade-Off placement with dynamic Best Delay offloading, reverse this trend, achieving ∆TSR = +5 points and ∆Lnorm = −0.06. These configurations succeed because they exploit ONTs only when the predicted service delay, including processing cost, remains below the OLT alternative. Conversely, naïve policies (e.g., Round-Robin placement with static Best Latency offloading) significantly degrade with respect to both metrics (∆TSR −20 points, ∆Lnorm + 1.0). Overall, the results demonstrate that far-edge computation improves performance only under adaptive, delay-aware orchestration; other-
Takeaways: (i) Introducing the Far-Edge layer amplifies the performance gap between compute-aware and proximitybased policies: only strategies that jointly account for node capacity and network delay sustain SLA compliance. (ii) Multi-objective and trade-off placements, when combined with dynamic delay-aware offloading, consistently achieve high TSR and low latency across heterogeneous conditions. (iii) In contrast, proximity-driven or static policies (e.g., BL with Round-Robin placement) overload ONTs and violate SLA guarantees, confirming that in heterogeneous infrastructures, compute-awareness outweighs mere proximity. 13
Table 2: Scalability results when varying the number of OLTs (1,000 users).
6. Simulator Scalability and Performance Objective. GenioSim targets scenarios with multiple OLTs, hundreds of ONTs, and bursty multi-tenant worklods. To assess the practical scalability of GenioSim, we evaluate how the simulator’s runtime and memory usage evolve as the size of the simulated infrastructure and number of users increase. Experimental Setup. All scalability experiments use the Mixed scenario described in Section 5.1, which combines all application workloads to generate heterogeneous and bursty traffic patterns. Two scaling dimensions are explored. In the first experiment, the number of users is fixed at 1,000, with each user represented by one ONT; while the number of OLTs varies from 10 to 100 in increments of 10. This configuration evaluates how the simulator scales with the size of the access network infrastructure. In the second experiment, the number of OLTs is fixed at 100 while the number of users varies from 100 to 1,000 in increments of 100. This configuration evaluates how the simulator scales with the number of edge devices and workload generators. For each simulation run, we measure (i) the total simulation runtime and (ii) the maximum resident set size (RSS) of the simulator process, representing peak memory consumption. Each configuration is executed three times, and the reported values correspond to the average across runs. All simulations were executed on a workstation equipped with an Intel Core i7 processor (8 cores, 3.2 GHz), 32 GB of RAM, running Ubuntu 22.04.
OLTs
Simulation Time (s)
Max RSS (MB)
10 20 30 40 50 60 70 80 90 100
142.29 144.76 143.83 146.27 145.12 147.54 148.16 146.29 151.26 154.77
2678.3 2711.6 2756.2 2779.7 2780.3 2810.6 2817.9 2824.9 2863.6 2883.5
Table 3: Scalability results when varying the number of users (100 OLTs).
Users
Simulation Time (s)
Max RSS (MB)
100 200 300 400 500 600 700 800 900 1000
25.41 35.49 48.54 62.47 75.53 90.33 104.47 126.15 141.53 156.52
1224.3 1473.0 1707.4 1971.6 2225.0 2472.3 2597.5 2789.9 2856.8 2960.5
7. Discussion
Results. Table 2 reports the results when varying the number of OLTs while keeping 1,000 users fixed. The simulator runtime increases moderately from 142 s to 155 s as the number of OLTs grows from 10 to 100, corresponding to an increase of approximately 9%. Memory consumption grows gradually from about 2.7 GB to 2.9 GB over the same range. These results indicate that increasing the number of OLTs entities has a limited impact on simulation cost, suggesting that the simulator scales efficiently with infrastructure size. Table 3 reports the results when varying the number of users while keeping the number of OLTs fixed at 100. In this case, runtime increases from approximately 25 s for 100 users to 157 s for 1,000 users. Memory consumption grows from about 1.2 GB to 3.0 GB across the same range. This trend reflects the increased number of simulated entities and workload events generated by user devices. Despite this growth, the simulator remains capable of handling scenarios with up to 1,000 users and 100 OLTs within a few minutes of runtime on a standard workstation. Overall, these results show that GenioSim scales well with both infrastructure size and number of simulated users. Runtime grows approximately linearly with the number of workload-generating devices, while increases in infrastructure elements (OLTs) have a relatively small impact on simulation cost. These findings confirm that the simulator can support large-scale PON-enabled edge scenarios with hundreds of nodes and thousands of users while maintaining practical execution times and memory usage.
While the experiments presented in Section 5 illustrate two representative use cases of GenioSim, namely capacity planning and orchestration policy evaluation, it is important to discuss the realism, assumptions, and intended scope of the simulator. Simulation fidelity and scope. GenioSim adopts a system-level simulation approach aimed at evaluating orchestration strategies and resource provisioning decisions in PON-enabled edge infrastructures. Rather than reproducing detailed protocol behavior, the simulator captures the architectural characteristics that most strongly influence orchestration outcomes, including hierarchical infrastructure organization (ONTs, OLTs, and cloud nodes), heterogeneous compute capacities across tiers, hybrid VM-container execution environments, and the separation between service placement and runtime task offloading. Together with configurable network latency and bandwidth parameters and heterogeneous user workloads, there elements allow the simulator to capture the key system-level effects such as resources contention, queueing delays, and communication latency across the edge hierarchy. To maintain scalability and support large multi-tier deployments, some aspects or real systems are intentionally abstracted. In particular, GenioSim does not model packet-level PON mechanisms (e.g., dynamic bandwidth allocation or optical framing) and represents network communication through latency and bandwidth abstractions. Likewise, container and VM execution are modeled through resource consumption and scheduling delays rather than detailed 14
emulation of container engines, hypervisor internals, or orchestration platforms such as Kubernetes. Control-plane functions such as monitoring, logging, and cluster management are therefore not explicitly simulated. In addition, the simulator is calibrated using representative hardware configurations and workload characteristics derived from prior studies [17, 9] and industrial input from the GENIO project [6]. While GenioSim is not calibrated against a full-scale experimental deployment, the chosen parameters ensure that simulated scenarios remain within realistic operating ranges. Consequently, the results should be interpreted as system-level insights rather than precise performance predictions. In particular, the simulator is well suited for comparative evaluation of orchestration policies and for capacity planning studies, whereas protocol-level performance validation would require complementary experimental approaches.
evaluation, GenioSim can also serve as a foundation for future research, enabling the assessment of novel orchestration policies and adaptive scheduling mechanisms in heterogeneous PON–edge environments. Moreover, industry practitioners can employ the tool to analyze how alternative orchestration strategies perform for their specific application scenarios, supporting data-driven decisions in deployment planning. Overall, the experimental analysis demonstrates the feasibility of combining PON networks with edge computing workloads by provisioning sufficient hardware resources within the PON infrastructure and adopting appropriate orchestration algorithms. Acknowledgment This work has been partially supported by the GENIO project (CUP B69J23005770005) funded by MIMIT, "Accordi per l’Innovazione" program. We also gratefully acknowledge the valuable contribution of Master’s student Gianluigi Erra.
Extensibility of the simulator. The placement and offloading strategies evaluated in this work are heuristic policies intended to serve as representative baselines. In particular, the implemented algorithms capture different classes of orchestration strategies commonly studied in edge computing environments, including simple load-balancing policies (e.g., roundrobin), resource-aware placement heuristics, and delay-aware offloading decisions. At the same time, GenioSim is designed as an extensible simulation environment for evaluating alternative orchestration mechanisms. The modular architecture of the ContainerOrchestrator and TaskOrchestrator components allows new placement and offloading policies to be integrated without modifying the rest of the simulation framework. This design enables experimentation with more advanced approaches such as optimization-based and learning-based policies.
References [1] OMIDIA, “Fiber and Copper Access Equipment Forecast: 2021-27,” 2022. [Online]. Available: https://omdia.tech.informa.com/om022089/ fiber-and-copper-access-equipment-forecast-202127 [2] P. v. Anvith, N. Gunavathi, B. Malarkodi, and B. Rebekka, “A survey on network functions virtualization for telecom paradigm,” in 2019 TEQIP III Sponsored International Conference on Microwave Integrated Circuits, Photonics and Wireless Networks (IMICPW), 2019, pp. 302–306. [3] W. Z. Khan, E. Ahmed, S. Hakak, I. Yaqoob, and A. Ahmed, “Edge computing: A survey,” Future Generation Computer Systems, vol. 97, pp. 219–235, 2019. [Online]. Available: https://www.sciencedirect. com/science/article/pii/S0167739X18319903
Energy Modeling. GenioSim includes support for energy modeling at both the network and infrastructure levels. In particular, the simulator allows nodes and network links to be associated with configurable energy consumption parameters, enabling the study of energy-aware resource management strategies. In this work, however, the experimental analysis focuses on two specific use cases: capacity planning and orchestration policy comparison under heterogeneous workloads. For this reason, the evaluation concentrates on performance-oriented metrics such as task success rate and end-to-end latency. Energy-aware evaluation is an important direction for future work.
[4] Telefonica, “Telefónica Open Access and Edge Computing,” 2019, accessed on 05.02.2024. [Online]. Available: https://www.telefonica.com/es/wp-content/uploads/sites/ 4/2021/02/whitepaper-telefonica-opa-mec-feb-2019.pdf [5] TIM, “Edge Cloud Computing,” 2022, accessed on 05.02.2024. [Online]. Available: https: //www.gruppotim.it/it/newsroom/notiziario-tecnico-tim/ 2022/n1-2022/cap03-edge-cloud-computing.html [6] C. Cesarano, A. Foggia, G. Roscigno, L. Andreani, and R. Natella, “Genio: Synergizing edge computing with optical network infrastructures,” IEEE Communications Magazine, 2025.
8. Conclusion We presented GenioSim, a simulation platform to support PON-enabled edge infrastructures. Simulation scenarios inspired by the GENIO project showed that far-edge ONTs reduce latency only under moderate requirements, while strict workloads demand higher provisioning at the OLT. In multiOLT setups, orchestration proved decisive: advanced placement and delay-aware offloading strategies consistently outperformed simple heuristics, particularly under bursty applications such as streaming and gaming. Beyond the presented
[7] S. Svorobej, P. Takako Endo, M. Bendechache, C. FilelisPapadopoulos, K. M. Giannoutakis, G. A. Gravvanis, D. Tzovaras, J. Byrne, and T. Lynn, “Simulating fog and edge computing scenarios: An overview and research challenges,” Future Internet, vol. 11, no. 3, 2019. [Online]. Available: https://www.mdpi.com/1999-5903/ 11/3/55 15
[8] C. Sonmez, A. Ozgovde, and C. Ersoy, “Edgecloudsim: An environment for performance evaluation of edge computing systems,” Transactions on Emerging Telecommunications Technologies, vol. 29, no. 11, p. e3493, 2018.
edge and fog computing environments,” Software: Practice and Experience, vol. 47, no. 9, pp. 1275–1296, 2017. [19] R. Mahmud, S. Pallewatta, M. Goudarzi, and R. Buyya, “Ifogsim2: An extended ifogsim simulator for mobility, clustering, and microservice management in edge and fog computing environments,” Journal of Systems and Software, vol. 190, p. 111351, 2022.
[9] C. Mechalikh, H. Taktak, and F. Moussa, “Pureedgesim: A simulation toolkit for performance evaluation of cloud, fog, and pure edge computing environments,” in 2019 international conference on high performance computing & simulation (HPCS). IEEE, 2019, pp. 700–707.
[20] T. Qayyum, A. W. Malik, M. A. K. Khattak, O. Khalid, and S. U. Khan, “Fognetsim++: A toolkit for modeling and simulation of distributed fog environment,” IEEE Access, vol. 6, pp. 63 570–63 583, 2018.
[10] P. S. Souza, T. Ferreto, and R. N. Calheiros, “Edgesimpy: Python-based modeling and simulation of edge computing resource management policies,” Future Generation Computer Systems, vol. 148, pp. 446–459, 2023.
[21] I. Lera, C. Guerrero, and C. Juiz, “Yafs: A simulator for iot scenarios in fog computing,” IEEE Access, vol. 7, pp. 91 745–91 758, 2019.
[11] I. Dias, L. Ruan, C. Ranaweera, and E. Wong, “From 5g to beyond: Passive optical network and multi-access edge computing integration for latency-sensitive applications,” Optical Fiber Technology, vol. 75, p. 103191, 2023. [Online]. Available: https://www.sciencedirect.com/science/ article/pii/S1068520022003753
[22] P. Wiesner and L. Thamsen, “Leaf: Simulating large energy-aware fog computing environments,” in 2021 IEEE 5th International Conference on Fog and Edge Computing (ICFEC). IEEE, 2021, pp. 29–36.
[12] R. Morabito, V. Cozzolino, A. Y. Ding, N. Beijar, and J. Ott, “Consolidate iot edge computing with lightweight virtualization,” IEEE Network, vol. 32, no. 1, pp. 102– 111, 2018.
[23] E. Del-Pozo-Puñal, F. García-Carballeira, and D. Camarmas-Alonso, “A scalable simulator for cloud, fog and edge computing platforms with mobility support,” Future Generation Computer Systems, vol. 144, pp. 117–130, 2023.
[13] Y. Qian, L. Hu, J. Chen, X. Guan, M. M. Hassan, and A. Alelaiwi, “Privacy-aware service placement for mobile edge computing via federated learning,” Information Sciences, vol. 505, pp. 562–570, 2019.
[24] M. M. Lopes, W. A. Higashino, M. A. Capretz, and L. F. Bittencourt, “Myifogsim: A simulator for virtual machine migration in fog computing,” in Companion proceedings of the10th international conference on utility and cloud computing, 2017, pp. 47–52.
[14] T. He, H. Khamfroush, S. Wang, T. La Porta, and S. Stein, “It’s hard to share: Joint service placement and request scheduling in edge clouds with sharable and non-sharable resources,” in 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS). IEEE, 2018, pp. 365–375.
[25] S. V. Margariti, V. V. Dimakopoulos, and G. Tsoumanis, “Modeling and simulation tools for fog computing—a comprehensive survey from a cost perspective,” Future Internet, vol. 12, no. 5, p. 89, 2020.
[15] Y. Guo, Y. Zhang, L. Wu, M. Li, X. Cai, and J. Chen, “Edge computing service deployment and task offloading based on multi-task high-dimensional multi-objective optimization,” arXiv preprint arXiv:2312.04101, 2023.
[26] C. Caiazza, C. Cicconetti, V. Luconi, and A. Vecchio, “Measurement-driven design and runtime optimization in edge computing: Methodology and tools,” Computer Networks, vol. 194, p. 108140, 2021.
[16] T. Chen, F. Tan, J. Ai, X. Xiong, C. Wu, and X. Ren, “Joint Optimization of Task Offloading and Service Placement for Digital Twin empowered Mobile Edge Computing,” in Proceedings of the 2024 3rd International Conference on Networks, Communications and Information Technology, 2024, pp. 132–137.
[27] B. Gómez, E. Coronado, J. Villalón, and A. Garrido, “Energy-focused simulation of edge computing architectures in 5g networks,” The Journal of Supercomputing, vol. 80, no. 9, pp. 12 564–12 584, 2024. [28] N. Kaftantzis, D. G. Kogias, and C. Z. Patrikakis, “Exploring the impact of resource management strategies on simulated edge cloud performance: An experimental study,” Network, vol. 4, no. 4, pp. 498–522, 2024.
[17] R. N. Calheiros, R. Ranjan, C. A. F. D. Rose, and R. Buyya, “Cloudsim: A novel framework for modeling and simulation of cloud computing infrastructures and services,” 2009. [Online]. Available: https://arxiv.org/abs/ 0903.2525
[29] L. Belcastro, F. Marozzo, A. Orsino, D. Talia, and P. Trunfio, “Navigating the edge-cloud continuum: A state-ofpractice survey,” arXiv preprint arXiv:2506.02003, 2025.
[18] H. Gupta, A. Vahid Dastjerdi, S. K. Ghosh, and R. Buyya, “ifogsim: A toolkit for modeling and simulation of resource management techniques in the internet of things, 16
[30] D. Kim and Y.-H. Kim, “Dynamic virtual network slicing and orchestration for selective mec services over widearea sdn,” Algorithms, vol. 13, no. 10, p. 245, 2020.
[38] C.-H. Hsiao, Y.-F. Wen, F. Y.-S. Lin, Y.-F. Chen, Y. Huang, Y.-C. Su, and Y.-S. Wu, “An optimizationbased orchestrator for resource access and operation management in sliced 5g core networks,” Sensors, vol. 22, no. 1, p. 100, 2021.
[31] M. Gharbaoui, B. Martini, G. Cecchetti, and P. Castoldi, “Resource orchestration strategies with retrials for latency-sensitive network slicing over distributed telco clouds,” Ieee Access, vol. 9, pp. 132 801–132 817, 2021.
[39] G. Bartolomeo, M. Yosofie, S. Bäurle, O. Haluszczynski, N. Mohan, and J. Ott, “Oakestra white paper: An orchestrator for edge computing,” arXiv preprint arXiv:2207.01577, 2022.
[32] F.-J. Moreno-Muro, M. Garrich, I. Iglesias-Castreño, S. Zahir, and P. Pavón-Mariño, “Emulating softwaredefined disaggregated optical networks in a containerized framework,” Applied Sciences, vol. 11, no. 5, p. 2081, 2021.
[40] A. S. Tanenbaum and H. Bos, Modern Operating Systems, 4th ed. USA: Prentice Hall Press, 2014. [41] C. Xu, J. Guo, J. Zeng, S. Meng, X. Chu, J. Cao, and T. Wang, “Enhancing AI-Generated Content Efficiency Through Adaptive Multi-Edge Collaboration,” in 2024 IEEE 44th International Conference on Distributed Computing Systems (ICDCS), 2024, pp. 960–970.
[33] S. Böhm and G. Wirtz, “Cloud-edge orchestration for smart cities: A review of kubernetes-based orchestration architectures,” EAI Endorsed Trans. Smart Cities, vol. 6, no. 18, p. e2, 2022. [34] H. U. Adoga and D. P. Pezaros, “Towards latency-aware vnf placement on heterogeneous hosts at the network edge,” in GLOBECOM 2023-2023 IEEE Global Communications Conference. IEEE, 2023, pp. 6383–6388.
[42] W. Fan, L. Zhao, X. Liu, Y. Su, S. Li, F. Wu, and Y. Liu, “Collaborative Service Placement, Task Scheduling, and Resource Allocation for Task Offloading With Edge-Cloud Cooperation,” IEEE Transactions on Mobile Computing, vol. 23, no. 1, pp. 238–256, 2024.
[35] A. Leivadeas, G. Kesidis, M. Ibnkahla, and I. Lambadaris, “Vnf placement optimization at the edge and cloud,” Future Internet, vol. 11, no. 3, p. 69, 2019.
[43] Selta, “DigitalPlatforms, Selta enters the fiber market with Volt,” 2024, accessed on 25.06.2024. [Online]. Available: https://selta.com/en/news/corporate-news/ digitalplatforms-selta-volt/
[36] P. Raith, T. Rausch, A. Furutanpey, and S. Dustdar, “faassim: A trace-driven simulation framework for serverless edge computing platforms,” Software: Practice and Experience, vol. 53, no. 12, pp. 2327–2361, 2023.
[44] SiSoftware, “Sandra Lite,” 2020, accessed on 10.06.2024. [Online]. Available: https://sisoftware-sandra-download. com/
[37] X. Shen, J. Gao, W. Wu, K. Lyu, M. Li, W. Zhuang, X. Li, and J. Rao, “Ai-assisted network-slicing based nextgeneration wireless networks,” IEEE Open Journal of Vehicular Technology, vol. 1, pp. 45–66, 2020.
17