Source-linked AI summary
ENORM: A Framework For Edge NOde Resource Management
Nan Wang, Blesson Varghese, Michail Matthaiou, Dimitrios S. Nikolopoulos
TL;DR
Cloud-centric computing faces scalability and quality-of-service challenges as device numbers grow, motivating fog computing and edge-node resource management. ENORM integrates edge nodes with cloud applications through provisioning and auto-scaling mechanisms, reducing latency and cloud communication in a game-use-case evaluation.
Problem
Cloud-based infrastructure may degrade in quality of service as billions of devices increase communication and computing demands, while existing resource-management frameworks do not address network-edge nodes.
Method
ENORM integrates edge nodes into the cloud computing ecosystem through resource-limited provisioning and deployment mechanisms plus dynamic edge-resource auto-scaling.
Results
20%-80% lower application latency and up to 95% lower data traffic and communication frequency were observed versus a cloud-only model in a PokéMon Go-like online game use-case.
Takeaways & Limitations
The evaluation demonstrates the feasibility of using ENORM to improve quality of service for many users in a given location through fog-computing deployment.
Takeaways & Limitations
The proposed auto-scaler uses static application priorities rather than dynamic priorities that may change as more users subscribe.
Abstract
from arXiv · showhide
Current computing techniques using the cloud as a centralised server will become untenable as billions of devices get connected to the Internet. This raises the need for fog computing, which leverages computing at the edge of the network on nodes, such as routers, base stations and switches, along with the cloud. However, to realise fog computing the challenge of managing edge nodes will need to be addressed. This paper is motivated to address the resource management challenge. We develop the first framework to manage edge nodes, namely the Edge NOde Resource Management (ENORM) framework. Mechanisms for provisioning and auto-scaling edge node resources are proposed. The feasibility of the framework is demonstrated on a PokeMon Go-like online game use-case. The benefits of using ENORM are observed by reduced application latency between 20% - 80% and reduced data transfer and communication frequency between the edge node and the cloud by up to 95\%. These results highlight the potential of fog computing for improving the quality of service and experience.
1 INTRODUCTION
Cloud-centric computing faces latency, traffic, and communication-frequency challenges as device numbers grow, motivating fog computing and ENORM’s edge-resource management framework.
- Over 25 billion devices were estimated to be added to the network, threatening QoS as existing infrastructure serves more devices.
- Fog computing adds edge nodes near users to reduce communication latency, cloud data traffic, and device–cloud communication frequency.
- ENORM addresses edge-resource management through provisioning, deployment, and dynamic resource allocation mechanisms.
- 20%-80% lower application latency was observed with ENORM than with a cloud-only model.
- Up to 95% reductions in data traffic and communication frequency between the edge node and cloud server were observed.
2 THE ENORM FRAMEWORK
ENORM integrates cloud, edge-node, and user-device tiers so partitioned cloud workloads can be hosted near users while preserving cloud coordination.
- ENORM uses a three-tier architecture comprising cloud, edge-node, and user-device tiers.
- Cloud server managers request edge services, deploy partitioned servers, and receive edge updates for the cloud application’s global view.
- Partitioned edge servers maintain localized user-relevant data while the cloud server maintains the global view.
- The resource allocator tracks free CPU cores and memory while prioritizing the edge node’s basic service over offloaded workloads.
- The auto-scaler dynamically allocates or de-allocates container resources to protect basic services and accommodate workload changes.
3 RESOURCE MANAGEMENT IN ENORM
ENORM’s resource-management procedures provision edge workloads through handshaking, deployment, and termination, while accounting for edge-resource availability and application requirements.
- Provisioning enables cloud servers to offload workloads to edge nodes, while auto-scaling allocates or de-allocates resources according to availability.
- The provisioning mechanism has three stages: handshaking, deployment, and termination.
- A cloud manager can terminate its edge server through the provisioning procedure.
- Handshaking communicates application name, priority, required ports, served users, and latency objective between cloud and edge managers.
- Deployment initializes a container, assigns ports, updates firewall settings, and returns a response to the cloud server manager.
11 end
ENORM manages edge workloads through resource and priority checks, remote deployment of partitioned applications, and termination procedures that can redirect users and migrate data to the cloud.
- ENORM checks resource availability and workload priority before launching an edge container, rejecting requests that fail either check.
- The deployment mechanism installs application-specific packages and a partitioned server image remotely, then redirects users to the edge server.
- Allocated container resources can be adjusted after users connect, increasing or de-allocating resources as needed.
- Termination can remove one or multiple edge services; affected users are redirected to the cloud and local updates are migrated into the cloud’s global data.
12 end
ENORM terminates edge application servers when required and periodically auto-scales their resources to balance limited edge capacity against application latency objectives.
- When an edge application server is terminated, its local updates are migrated to the cloud and affected users are redirected there until another edge node is provisioned.
- ENORM’s auto-scaling mechanism runs periodically because edge servers have limited resources and applications’ resource needs vary with their QoS objectives.
- Resources are added when measured latency exceeds the service objective and removed when latency falls below it.
- Scaling can terminate lower-priority containers when resources are insufficient for higher-priority scale-up requests.
18 end
The auto-scaler prioritizes edge applications, checks available resources and user coverage, and uses network latency objectives to scale, migrate, or terminate services.
- The edge manager maintains application servers and their static priority levels, considering the highest-priority application first.
- The auto-scaler measures network latency and checks whether free edge resources meet each application server’s predefined minimum requirement.
- It verifies user coverage and potential latency reduction before retaining an application at the edge rather than migrating it to the cloud or another edge node.
- Latency above the objective triggers resource allocation, while latency below the objective triggers resource removal.
23 end
The scaling mechanism adjusts container quotas in resource units and avoids progressive lower-priority downsizing by terminating the lowest-priority container when necessary.
- A resource unit consists of one CPU core and 200MB of RAM in the paper’s implementation.
- Scaling up adds one resource unit to a container when additional edge resources are available.
- Scaling down removes one resource unit from the server’s current allocation and updates its resource quota.
- When resources are exhausted, the algorithm terminates the lowest-priority container until sufficient capacity exists for a higher-priority scale-up.
4 AN ONLINE GAME USE-CASE
The iPokeMon use-case tests ENORM by partitioning game state between a cloud server and location-specific edge nodes. The implementation supports dynamic edge deployment, user-data migration, and reduced communication distance for latency-sensitive gameplay.
- Use-case rationale: Location-aware gameplay lets edge nodes manage local user views while the cloud periodically updates the global view.This partitions frequent location-specific changes from less frequent global updates.
- Use-case rationale: iPokeMon is a latency-sensitive, geographically distributed game in which users explore real-world streets and interact with virtual creatures.The game uses an iOS client and a public-cloud server.
- System design: The fog-based design partitions user and location functions between the cloud server and edge nodes, directing only cloud-registered users to edges.The server is manually partitioned at function level.
- System design: Dynamic server addressing lets the cloud manager redirect new players from the cloud to an available edge server.The default configuration points to the cloud until an edge server becomes available.
- System design: Runtime database partitioning copies location-specific users’ Redis keys and values to the edge during deployment and supports their removal when the edge terminates.This enables migration of user-specific data between cloud and edge resources.
- Prototype implementation: The prototype uses an Odroid-XU board as an edge node representing a small-cell base station, while the cloud game server runs on Amazon EC2.The Odroid board connects user-device traffic through a routing node such as a mobile base station.
5 EXPERIMENTAL STUDIES
The evaluation measures ENORM’s provisioning, auto-scaling, latency, data-transfer, and communication-frequency effects in an iPokeMon-like fog-computing use-case. Compared with cloud-only execution, ENORM reduces application latency and substantially limits traffic and requests forwarded to the cloud while incurring modest management overheads.
- Experimental setup: The evaluation stress-tested partitioned iPokeMon servers with Apache JMeter using recorded 20-minute sessions and five-minute experiments averaged over five executions.Both aggressive and mixed virtual-user behaviours were modelled, alongside dynamic edge-node resource utilisation patterns.
- Overheads: Provisioning overhead covers handshaking, deployment, and termination across single-user and multi-user edge-server scenarios.Handshaking identifies an edge node, initialises a container, and establishes the required connection; deployment and termination overheads were also measured.
- Overheads: Less than a 3% increase in provisioning overhead occurred when multiple users connected to edge servers rather than single users.The measured overhead reflects transferring users’ information during deployment and termination, while intermediate states remain at the edge.
- Overheads: Auto-scaling overhead was 5.3 seconds with one container and increased with more containers or users because monitoring requirements grew.This overhead constrains how frequently auto-scaling decisions can be performed on an edge node.
- Service improvement using ENORM: Application latency decreased by approximately 20% against Dublin and nearly 80% against N. Virginia in mixed-user cases, reaching an 83% improvement for 16,384 users.For the 16,384-user multi-server case, a request took 600 ms through N. Virginia compared with less than 100 ms at the edge.
- Service improvement using ENORM: Cloud-bound data transfer fell by over 88% for mixed behaviour and up to 95% for aggressive behaviour, while cloud communication frequency fell by 88%-95%.With 16,384 users, 2,000 MB generated in five minutes became 190 MB sent beyond the edge, and only 8%-12% of requests were forwarded.
- Summary: Across one to 16,384 users, the use-case reported handshaking, deployment, termination, and auto-scaling overheads of 9, 9, 5, and 6 seconds, respectively.The evaluation summary reports only a small increase in these overheads as user count rises.
6 RELATED WORK
Prior work addresses resource management in clusters and clouds, but edge nodes introduce distinct provisioning, deployment, and resource-management challenges. ENORM targets this gap by managing cloud-to-edge workload offloading in a multi-tenant fog architecture.
- Existing distributed resource-management techniques target grids, clusters, and clouds, while edge-specific resource concentration and distance characteristics require additional treatment.
- Reference architectures describe functional layers at a high level, whereas ENORM implements a resource-management architecture for a real-world application.
- Fog computing uses edge nodes for aggregation, device sharing, or user-to-edge offloading, but these models do not fully support cloud-application QoS improvement.
- Applications requiring frequent user-server communication can benefit from placing computation closer to users to reduce communication frequency and response time.
- Research on cloud-to-edge offloading has focused mainly on caching, context-aware browsing, and video preprocessing, leaving resource management minimally studied.
- ENORM advances beyond edge-node discovery by managing resources for already discovered nodes and considering multi-tenancy.
7 CONCLUSIONS
ENORM integrates edge nodes into the computing ecosystem through provisioning, workload deployment, and dynamic resource allocation. In a Pokémon Go-like game, it reduced latency and cloud-edge communication, while its auto-scaling priorities and resource granularity remain constrained.
- ENORM addresses provisioning, workload deployment, and dynamic resource allocation for edge nodes supporting cloud applications.
- The provisioning and auto-scaling mechanisms use simple linear-search implementations suited to resource-constrained edge environments.
- 20%-80% lower application latency was observed with ENORM than with a cloud-only model in a Pokémon Go-like online game.
- Up to 95% reductions were observed in both data traffic and communication frequency between the edge node and cloud server.
- The auto-scaler uses static application priorities rather than dynamic priorities that may change as user subscriptions increase.
- For massively geodistributed applications, latency reductions may be insufficient to motivate edge deployment, although edge computing may still improve QoS.
- ENORM supports single and multiple edge-node environments but does not yet consider application migration between nodes.
- The current auto-scaler adds CPU and memory in fixed units, although other applications may require different resources or granularity.