RFC 9556

Internet of Things (IoT) Edge Challenges and Functions

๐Ÿ“… published April 2024, from ietf

Part 1 of 9 ๐ŸŽ€

RFC 9556: Internet of Things (IoT) Edge Challenges and Functions โœจ

bestie, the vibes are immaculate. ๐Ÿ’– This one's an Informational doc from the IRTF (not an IETF standard, so no pressure, just vibes ๐Ÿงš). It's dated April 2024, and the authors are J. Hong (ETRI), Y-G. Hong (Daejeon University), X. de Foy (InterDigital Communications, LLC), M. Kovatsch (Huawei Technologies Duesseldorf GmbH), E. Schooler (University of Oxford), and D. Kutscher (HKUST(GZ)). ๐Ÿ‘‘ The ISSN is 2070-1721, and it's a product of the IRTF T2TRG (Thing-to-Thing Research Group). The title block doesn't list anything it obsoletes or updates, so it's a fresh one ๐Ÿฆ‹

Abstract

Okay so the big idea here is that a lot of IoT apps need stuff that a centralized cloud just can't deliver ๐Ÿ˜ญ Think time sensitivity, huge amounts of data, connectivity costs, staying functional when services drop in and out, privacy, and security. ๐Ÿ”ฅ That's why IoT is pulling the Internet toward edge computing. This doc lays out what the emerging IoT edge needs, what challenges come with it, and a general model plus major components. The goal is a shared starting point for future chats in the T2TRG and other IRTF and IETF groups. ๐Ÿ’…

Status of This Memo

This doc is not an Internet Standards Track spec. It's published purely for info, so think of it as a friendly guide, not a rulebook ๐ŸŒธ

It's a product of the Internet Research Task Force (IRTF), which publishes research and development results related to the Internet. Those results might not be ready for deployment, so be careful ๐Ÿ™ˆ This RFC reflects the consensus of the Thing-to-Thing Research Group of the IRTF. Documents the IRSG approves for publication are not candidates for any level of Internet Standard. For the details, check Section 2 of RFC 7841 ๐Ÿง

If you want the latest status, any errata, or a way to send feedback, head to https://www.rfc-editor.org/info/rfc9556 ๐ŸŽ€

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. ๐ŸŒˆ

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, bestie, because they spell out your rights and restrictions for this doc ๐Ÿ“œ

Table of Contents

   1.  Introduction
   2.  Background
     2.1.  Internet of Things (IoT)
     2.2.  Cloud Computing
     2.3.  Edge Computing
     2.4.  Examples of IoT Edge Computing Use Cases
   3.  IoT Challenges Leading toward Edge Computing
     3.1.  Time Sensitivity
     3.2.  Connectivity Cost
     3.3.  Resilience to Intermittent Services
     3.4.  Privacy and Security
   4.  IoT Edge Computing Functions
     4.1.  Overview of IoT Edge Computing
     4.2.  General Model
     4.3.  OAM Components
       4.3.1.  Resource Discovery and Authentication
       4.3.2.  Edge Organization and Federation
       4.3.3.  Multi-Tenancy and Isolation
     4.4.  Functional Components
       4.4.1.  In-Network Computation
       4.4.2.  Edge Storage and Caching
       4.4.3.  Communication
     4.5.  Application Components
       4.5.1.  IoT Device Management
       4.5.2.  Data Management and Analytics
     4.6.  Simulation and Emulation Environments
   5.  Security Considerations
   6.  Conclusion
   7.  IANA Considerations
   8.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction ๐Ÿฆ‹

Okay, so right now a ton of IoT services run on cloud computing platforms, and honestly, that makes sense. Those platforms give you basically unlimited storage and processing power โœจ Relying on back-end cloud computing also brings perks like scalability and efficiency. ๐Ÿ’– But here's the thing: IoT systems are still pretty static when it comes to fitting computation in. It's not that there's zero computation going on. It's that setups tend to get stuck in fixed layouts, like edge gateways plus cloud services ๐Ÿ™ˆ

Meanwhile, IoT devices are cranking out huge amounts of data at the edges of the network ๐Ÿ“ˆ So more and more, that data is being stored, processed, analyzed, and acted on close to where it's created. โญ The needs here are time sensitivity, data volume, connectivity cost, resiliency when connectivity is spotty, privacy, and security. Centralized cloud computing just can't cover all of that ๐Ÿ’€ So we need something more flexible: distribute the computing (and storage) and blend it smoothly into the edge-cloud continuum. ๐ŸŒˆ The doc calls this blend "IoT edge computing" ๐ŸŽ€ This doc covers the background, use cases, challenges, system models, and functional components.

Heads up: this doc doesn't list existing projects, because the IoT edge landscape changes so fast it'd be outdated in five minutes ๐Ÿƒโ€โ™€๏ธ Section 4.1 gives a high-level overview of the field, based on a limited look at standards, research, and open-source and proprietary products in [EDGE-COMPUTING-BACKGROUND].

This doc represents the consensus of the Thing-to-Thing Research Group (T2TRG). Members who are actively building this tech reviewed it extensively. It's not an IETF product, and it's not a standard ๐Ÿซถ

2. Background ๐ŸŒธ

2.1. Internet of Things (IoT) ๐Ÿงš

So "Internet of Things" was coined by Kevin Ashton in 1999 while he was working on Radio-Frequency Identification (RFID) technology [Ashton]. Since then, the idea has grown up a lot ๐Ÿ˜ญ Right now it's about connecting the physical world to the virtual world of computers, usually over wireless networks, where things can send and receive information without a human in the loop. โœจ More recently it's gotten more literal: things are connecting straight to the Internet and converging on Internet and web tech. ๐Ÿ”ฅ

A "Thing" is a physical item that's made available in the IoT, so people, services, and/or other Things can interact with the physical world digitally [REST-IOT]. In this doc, the term "IoT device" refers to the embedded system attached to the Thing ๐Ÿ“

Resource-constrained Things, like sensors, home appliances, and wearables, often have limited storage and processing power. That can cause real headaches for reliability, performance, energy consumption, security, and privacy [Lin] ๐Ÿ’€ Some less-constrained Things can generate a seriously voluminous amount of data ๐Ÿ“Š All of this pushed IoT designs toward integrating Things into bigger distributed systems, like edge or cloud computing systems. It's giving teamwork ๐Ÿซถ

2.2. Cloud Computing ๐Ÿ’œ

Cloud computing is defined in [NIST] like this:

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

The super low cost and massive availability of storage and processing power made room for another model, where virtualized resources can be leased on demand and offered as general utilities ๐Ÿ’… Platform-as-a-Service (PaaS) and cloud computing platforms widely adopted this approach to deliver services over the Internet, and they got both economic and technical wins out of it [Botta] ๐Ÿ‘‘

Right now, an unprecedented volume and variety of data is being generated by Things, and applications at the network edge are consuming it ๐ŸŒˆ In that context, cloud-based service models aren't a good fit for some apps that need very short response times, need access to local personal data, or generate massive amounts of data ๐Ÿ˜ญ Those apps may instead lean on edge computing โญ

2.3. Edge Computing

2.3. Edge Computing ๐ŸŒธ

okay so edge computing, which some people call "fog computing" depending on who you ask ๐ŸŒซ๏ธโœจ bestie, it's giving a brand new paradigm ๐Ÿ’… where a big chunk of computing and storage gets parked at the edge of the Internet, right next to mobile devices, sensors, actuators, or machines. Like, the stuff lives where the data is born [Mahadev] AND where decisions get made or where things interact with the physical world ๐Ÿฆ‹ ("close" is doing a lot of work here, because it can mean topologically close, physically close, latency-close, etc.). It handles downstream data (the stuff coming from cloud services) AND upstream data (the stuff coming from end devices or network elements) ๐Ÿซถ And when people say "fog computing," they usually mean multi-tiered edge computing: several layers of compute infrastructure sitting between end devices and cloud services ๐ŸŒˆ

So an edge device is any computing or networking resource that lives between end-device data sources and cloud-based data centers ๐Ÿ’œ In edge computing, end devices both consume AND produce data ๐ŸŽ€ At the network edge, devices don't just request services and information from the cloud, they also handle computing tasks like processing, storing, caching, and load balancing on data going to and from the cloud [Shi] โœจ This doesn't stop end devices from doing their own computation when they can, either on their own or as part of a distributed edge computing platform ๐Ÿงš

Several Standards Developing Organizations (SDOs) and industry forums have written down their own definitions of edge and fog computing, so let's peek at the vibes ๐Ÿ‘‘

  • ISO defines edge computing as a "form of distributed computing in which significant processing and data storage takes place on nodes which are at the edge of the network" [ISO_TR] ๐Ÿ“
  • ETSI defines multi-access edge computing as a "system which provides an IT service environment and cloud-computing capabilities at the edge of an access network which contains one or more type of access technology, and in close proximity to its users" [ETSI_MEC_01] ๐ŸŒธ
  • The Industry IoT Consortium (IIC) (now incorporating what was formerly OpenFog) defines fog computing as "a horizontal, system-level architecture that distributes computing, storage, control and networking functions closer to the users along a cloud-to-thing continuum" [OpenFog] ๐Ÿฆ‹

Based on all of these, the general philosophy of edge computing is distributing the required functions close to users and data ๐Ÿ’– The difference from classic local systems is that it uses management and orchestration features borrowed from cloud computing ๐Ÿ”ฅ

Different industries talk about edge computing with different terms and reference models ๐Ÿ™ˆ but in practice these approaches are not incompatible and may integrate with each other ๐Ÿซถ

  • The telecommunication industry tends to deploy edge computing services over a Network Function Virtualization (NFV) infrastructure, at aggregation points, or in proximity to the user equipment (e.g., gNodeBs) [ETSI_MEC_03] ๐Ÿ“ก๐Ÿ’œ
  • Enterprise and campus solutions often read edge computing as an "edge cloud," that is, a smaller data center directly connected to the local network (often referred to as "on-premise") ๐Ÿข๐ŸŽ€
  • The automation industry defines the edge as the connection point between IT and Operational Technology (OT) โš™๏ธ So edge computing sometimes means applying IT solutions to OT problems, like analytics, more-flexible user interfaces, or simply having more computing power than an automation controller ๐Ÿ’€โœจ

2.4. Examples of IoT Edge Computing Use Cases โœจ

okay bestie, IoT edge computing can show up in home, industry, grid, healthcare, city, transportation, agriculture, and/or educational scenarios ๐Ÿก๐Ÿญ. We're only gonna look at a few examples so we can spot the differentiating requirements, and the other use cases get references so you can go digging ๐Ÿ”.

Smart Factory ๐Ÿญ

As part of the Fourth Industrial Revolution, smart factories run real-time processes built on IT technologies like artificial intelligence and big data ๐Ÿค–. ngl, even a very small environmental change in a smart factory can lead to lower production efficiency or product quality problems ๐Ÿ˜ญ. So simple but time-sensitive processing can happen at the edge, like controlling the temperature and humidity in the factory or running machines based on real-time collection of each machine's operational status ๐ŸŒก๏ธ. However, data that needs highly precise analysis, like machine life-cycle management or accident risk prediction, can be sent to a central data center for processing ๐Ÿข.

The use of edge computing in a smart factory [Argungu] can reduce the cost of network and storage resources by cutting the communication load to the central data center or server ๐Ÿ’ธ. It's also possible to improve process efficiency and facility asset productivity through real-time prediction of failures, and to cut the cost of failure with preliminary measures ๐Ÿ› ๏ธ. In the existing manufacturing field, production facilities are run manually according to a program entered in advance. Edge computing in a smart factory, though, enables tailoring solutions by analyzing data at each production facility and machine level ๐ŸŽฏ. Digital twins [Jones] of IoT devices have been jointly used with edge computing in industrial IoT scenarios [Chen] ๐Ÿ‘ฏ.

Smart Grid โšก

In future smart-city scenarios, the smart grid will be critical in ensuring highly available and efficient energy control in city-wide electricity management [Mehmood] ๐ŸŒ†. Edge computing is expected to play a significant role in these systems. It improves the transmission efficiency of electricity, helps react to and restore power after a disturbance, reduces operation costs, and lets energy be reused effectively, since these operations involve local decision-making ๐Ÿง . On top of that, edge computing can help monitor power generation and power demand and make local electrical energy storage decisions in smart grid systems ๐Ÿ”‹โœจ.

Smart Agriculture ๐ŸŒพ

Smart agriculture integrates information and communication technologies with farming technology ๐Ÿšœ. Intelligent farms use IoT technology to measure and analyze parameters such as temperature, humidity, sunlight, carbon dioxide, and soil quality in crop cultivation facilities ๐ŸŒฑ. Depending on the analysis results, control devices are used to set the environmental parameters to an appropriate state. Remote management is also possible through mobile devices, like smartphones ๐Ÿ“ฑ.

In existing farms, simple systems, like management according to temperature and humidity, can be easily and inexpensively implemented using IoT technology [Tanveer] ๐ŸŒค๏ธ. Field sensors gather data on field and crop condition. That data is then transmitted to cloud servers that process it and recommend actions. Edge computing can reduce the volume of back-and-forth data transmissions significantly, which means cost and bandwidth savings ๐Ÿ’ฐ. Locally generated data can be processed at the edge, and local computing and analytics can drive local actions ๐ŸŽฌ. With edge computing, it's easy for farmers to select large amounts of data for processing, and data can be analyzed even in remote areas with poor access conditions ๐Ÿž๏ธ. Other applications include dashboarding, for example to visualize the farm status, as well as enhancing Extended Reality (XR) applications that require edge audio and/or video processing ๐Ÿฅฝ. Since the number of people working on farming has been decreasing over time, increasing automation enabled by edge computing can be a driving force for future smart agriculture [OGrady] ๐Ÿค–๐ŸŒฝ.

Smart Construction ๐Ÿ—๏ธ

Safety is critical at construction sites, periodt ๐Ÿฆบ. Every year, many construction workers lose their lives because of falls, collisions, electric shocks, and other accidents [BigRentz] ๐Ÿ˜ข. So solutions have been developed to improve construction site safety, including real-time identification of workers, monitoring of equipment location, and predictive accident prevention ๐Ÿšง. To deploy these solutions, many cameras and IoT sensors have been installed on construction sites to measure noise, vibration, gas concentration, etc. Typically, the data from these measurements is collected in on-site gateways and sent to remote cloud servers for storage and analysis โ˜๏ธ. That way, an inspector can check the information stored on the cloud server to investigate an incident ๐Ÿ”Ž. However, this approach can get expensive because of transmission costs (for example, of video streams over a mobile network connection) and because of usage fees for private cloud services ๐Ÿ“‰.

Using edge computing [Yue], data generated at the construction site can be processed and analyzed on an edge server located within or near the site ๐Ÿ–ฅ๏ธ. Only the result of this processing needs to be transferred to a cloud server, which reduces transmission costs ๐Ÿ’…. It's also possible to locally generate warnings to prevent accidents in real time ๐Ÿšจ.

Self-Driving Car ๐Ÿš—

Edge computing plays a crucial role in safety-focused self-driving car systems [Badjie] ๐Ÿ›ฃ๏ธ. With a multitude of sensors, such as high-resolution cameras, radars, Light Detection and Ranging (LiDAR) systems, sonar sensors, and GPS systems, autonomous vehicles generate vast amounts of real-time data ๐Ÿ“ก. Local processing using edge computing nodes allows for efficient collection and analysis of this data, so the car can monitor vehicle distances and road conditions and respond promptly to unexpected situations ๐Ÿ‘€. Roadside computing nodes can also be leveraged to offload tasks when necessary, for example when the car's local processing capacity is insufficient because of hardware constraints or a large data volume ๐Ÿซถ.

For instance, when the car ahead slows down, a self-driving car adjusts its speed to maintain a safe distance. Or when a roadside signal changes, it adapts its behavior accordingly ๐Ÿšฆ. In another example, cars with self-parking features use local processing to analyze sensor data, determine suitable parking spots, and execute precise parking maneuvers without relying on external processing or connectivity ๐Ÿ…ฟ๏ธ. It's also possible to use in-cabin cameras coupled with local processing to monitor the driver's attention level and detect signs of drowsiness or distraction ๐Ÿ˜ด. The system can issue warnings or implement preventive measures to ensure driver safety ๐Ÿ›ก๏ธ.

Edge computing empowers self-driving cars by enabling real-time processing, reducing latency, enhancing data privacy, and optimizing bandwidth usage ๐Ÿ‘‘. By leveraging local processing capabilities, self-driving cars can make rapid decisions, adapt to changing environments, and deliver safer and more efficient autonomous driving experiences ๐Ÿฆ‹.

Digital Twin ๐Ÿชž

A digital twin can simulate different scenarios and predict outcomes based on real-time data collected from the physical environment ๐Ÿงช. This simulation capability supports proactive maintenance, optimization of operations, and prediction of potential issues or failures. Decision makers can use digital twins to test and validate different strategies, identify inefficiencies, and optimize performance [CertMagic] ๐Ÿ“Š.

With edge computing, real-time data is collected, processed, and analyzed directly at the edge, which allows for accurate monitoring and simulation of physical assets ๐ŸŽฏ. Moreover, edge computing effectively minimizes latency, enabling rapid responses to dynamic conditions, because computational resources are brought closer to the physical object ๐Ÿƒโ€โ™€๏ธ. Running digital twin processing at the edge helps organizations get timely insights and make informed decisions that maximize efficiency and performance ๐Ÿ’–.

Other Use Cases ๐ŸŒˆ

Artificial intelligence (AI) and machine learning (ML) systems at the edge empower real-time analysis, faster decision-making, reduced latency, improved operational efficiency, and personalized experiences across various industries, by bringing AI and ML capabilities closer to edge devices ๐Ÿง ๐Ÿ’œ.

In addition, oneM2M has studied several IoT edge computing use cases, which are documented in [oneM2M-TR0001], [oneM2M-TR0018], and [oneM2M-TR0026]. The edge-computing-related requirements raised through the analysis of these use cases are captured in [oneM2M-TS0002] ๐Ÿ“š.

3. IoT Challenges Leading toward Edge Computing ๐Ÿง—โ€โ™€๏ธ

This section describes the challenges faced by the IoT that are motivating the adoption of edge computing ๐Ÿ’…. These are distinct from the research challenges applicable to IoT edge computing, some of which are mentioned in Section 4 ๐Ÿ”ฌ.

IoT technology is being used with increasingly demanding applications in domains such as industrial, automotive, and healthcare, and that leads to new challenges ๐Ÿ˜ค. For example, industrial machines, such as laser cutters, produce over 1 terabyte of data per hour, and similar amounts can be generated in autonomous cars [NVIDIA] ๐Ÿคฏ. 90% of IoT data is expected to be stored, processed, analyzed, and acted upon close to the source [Kelly], as cloud computing models alone cannot address these new challenges [Chiang] ๐Ÿซฃ.

Below, we discuss IoT use case requirements that are moving cloud capabilities to be more proximate, distributed, and disaggregated ๐ŸŒ.

3.1. Time Sensitivity โฑ๏ธ

Often, many industrial control systems, such as manufacturing systems, smart grids, and oil and gas systems, require stringent end-to-end latency between the sensor and control nodes ๐ŸŽข. While some IoT applications may require latency below a few tens of milliseconds [Weiner], industrial robots and motion control systems have use cases with cycle times in the order of microseconds [IEC_IEEE_60802] ๐Ÿค–โšก. In some cases, speed-of-light limitations may simply prevent cloud-based solutions. However, that isn't the only challenge when it comes to time sensitivity ๐Ÿ™ˆ. Guarantees for bounded latency and jitter ([RFC8578], Section 7) are also important for industrial IoT applications ๐Ÿ’œ. This means control packets must arrive with as little variation as possible and within a strict deadline โฐ. Given the best-effort characteristics of the Internet, this challenge is virtually impossible to address without using end-to-end guarantees for individual message delivery and continuous data flows ๐Ÿ˜ญ๐Ÿซถ.

3.2. Connectivity Cost

Okay so bestie, some IoT setups don't really have a bandwidth problem when they upload stuff to the cloud ๐ŸŒธ Like, in theory both 5G and Wi-Fi 6 can top out at 10 gigabits per second (that's 4.5 terabytes per hour!! ๐Ÿ˜ญ), so big uplinks are totally possible. BUT keeping that kind of high-bandwidth connection running all the time is unjustifiable and impractical for most IoT apps, ngl ๐Ÿ’€ In some settings, like aeronautical communication, higher communication costs make it even harder to upload much of anything ๐Ÿ›ฉ๏ธ So minimizing reliance on high-bandwidth connectivity is a requirement ๐Ÿ’… One way to do that is processing data at the edge and then sending only the summarized or actionable insights up to the cloud. Main character energy, fr ๐ŸŽ€

3.3. Resilience to Intermittent Services

Many IoT devices, like sensors, actuators, and controllers, have super limited hardware resources, so they can't rely only on their own resources to handle their computing and/or storage needs ๐Ÿฅบ They need reliable, uninterrupted, or resilient services to boost what they can do for their application tasks. This is hard, and sometimes straight-up impossible, to pull off with cloud services for stuff like vehicles, drones, or oil rigs that have on-and-off network connectivity ๐Ÿ›ธ Plot twist though: a cloud backend might want to access device data even when the device is asleep ๐Ÿ˜ด Iconic behavior, honestly ๐Ÿฆ‹

3.4. Privacy and Security

When IoT services are deployed at home, personal info can be learned from detected usage data ๐Ÿ  For example, you can figure out someone's employment, family status, age, and income just by analyzing smart meter data [ENERGY]. Yikes ๐Ÿ˜ฌ Policy makers have started putting out frameworks that limit how personal data gets used and impose strict requirements on data controllers and processors โš–๏ธ Data stored indefinitely in the cloud also raises the risk of data leakage, for instance through attacks on rich targets ๐ŸŽฏ Not me being scared of a honeypot cloud ๐Ÿ’€

It's often argued that industrial systems don't have privacy implications because no personal data is gathered ๐Ÿญ But data from those systems is often highly sensitive, since you might be able to infer trade secrets, like the setup of production lines ๐Ÿคซ So owners of these systems are generally reluctant to upload IoT data to the cloud. Totally valid, periodt ๐Ÿ’œ

Furthermore, passive observers can perform traffic analysis on device-to-cloud paths ๐Ÿ‘€ Therefore, hiding traffic patterns associated with sensor networks can be another requirement for edge computing ๐Ÿงš

  1. IoT Edge Computing Functions โœจ

We're going to look at the current state of IoT edge computing first (Section 4.1), and then define a general system model (Section 4.2) ๐ŸŒˆ This gives us context for the IoT edge computing functions, which are listed in Sections 4.3, 4.4, and 4.5. Let's get into it, bestie ๐Ÿซถ

4.1. Overview of IoT Edge Computing

This section gives an overview of where IoT edge computing stands right now (at the time of writing). It's based on a limited review of standards, research, and open-source and proprietary products in [EDGE-COMPUTING-BACKGROUND] ๐Ÿ“š

IoT gateways are a super common class of IoT edge computing products ๐ŸŒ. Both open-source ones (like EdgeX Foundry or Home Edge) and proprietary ones exist. The gateway provides a local service on customer premises and gets remotely managed through a cloud service โ˜๏ธ IoT communication protocols are typically used between IoT devices and the gateway. That includes a Constrained Application Protocol (CoAP) [RFC7252], Message Queuing Telemetry Transport (MQTT) [MQTT5], and lots of specialized IoT protocols (like Open Platform Communications Unified Architecture (OPC UA) and Data Distribution Service (DDS) in the industrial IoT space) ๐Ÿญ Meanwhile, the gateway talks to the distant cloud, typically using HTTPS ๐Ÿ”’ Virtualization platforms let you deploy virtual edge computing functions (using Virtual Machines (VMs) and application containers), including IoT gateway software, on servers in the mobile network infrastructure (at base stations and concentration points), edge data centers (in central offices), and regional data centers near central offices ๐Ÿ—ผ End devices are envisioned to become computing devices in forward-looking projects, but they aren't commonly used at the time of writing ๐Ÿ”ฎ

In addition to open-source and proprietary solutions, a horizontal IoT service layer is standardized by the oneM2M standards body. The goal is to reduce fragmentation, increase interoperability, and promote reuse in the IoT ecosystem ๐Ÿ” Also, ETSI Multi-access Edge Computing (MEC) developed an IoT API [ETSI_MEC_33] that enables the deployment of heterogeneous IoT platforms and gives a means to configure the various components of an IoT system โš™๏ธ

Physical or virtual IoT gateways can host application programs that are typically built using an SDK, so they can access local services through a programmatic API ๐Ÿ’ป Edge cloud system operators host their customers' application VMs or containers on servers located in or near access networks that can implement local edge services ๐Ÿ“ก For example, mobile networks can provide edge services for radio network information, location, and bandwidth management ๐Ÿ“ถ

Resilience in the IoT can mean being able to operate autonomously during periods of disconnectedness, to preserve the integrity and safety of the controlled system, possibly in a degraded mode ๐Ÿ›ก๏ธ IoT devices and gateways are often expected to run in always-on and unattended modes, using fault detection and unassisted recovery functions ๐Ÿค–

Life-cycle management of services and applications on physical IoT gateways is generally cloud based ๐Ÿ”„ Edge cloud management platforms and products (such as StarlingX, Akraino Edge Stack, or proprietary products from major cloud providers) adapt cloud management technologies (e.g., Kubernetes) to the edge cloud. That means smaller, distributed computing devices running outside a controlled data center ๐Ÿ—๏ธ Typically, the service and application life cycle uses an NFV-like management and orchestration model ๐ŸŽ›๏ธ

The platform generally enables advertising or consuming services hosted on the platform (e.g., the Mp1 interface in ETSI MEC supports service discovery and communication). It also enables communication with local and remote endpoints (e.g., message routing function in IoT gateways) ๐Ÿ“จ The platform is usually extensible to edge applications, because it can advertise a service that other edge applications can consume ๐Ÿงฉ The IoT communication services include protocol translation, analytics, and transcoding ๐ŸŽฌ Communication between edge computing devices is enabled in tiered or distributed deployments ๐Ÿชœ

An edge cloud platform may enable pass-through without storage, or local storage (e.g., on IoT gateways) ๐Ÿ’พ Some edge cloud platforms use distributed storage, such as that provided by a distributed storage platform (e.g., EdgeFS and Ceph). In more experimental settings, they use an Information-Centric Networking (ICN) network. For example, systems such as Chipmunk [Chipmunk] and Kua [Kua] have been proposed as distributed information-centric object stores ๐Ÿงช External storage, for example on databases in a distant or local IT cloud, is typically used for filtered data deemed worthy of long-term storage. Although, in some cases, it may be used for all data, for example when required for regulatory reasons ๐Ÿ“

Stateful computing is the default on most systems, VMs, and containers ๐Ÿง  Stateless computing is supported on platforms providing a "serverless computing" service (also known as function-as-a-service, e.g., using stateless containers), or on systems based on named function networking ๐Ÿช„

In many IoT use cases, a typical network usage pattern is a high-volume uplink, with some form of traffic reduction enabled by processing over edge computing devices ๐Ÿ“ˆ Alternatives to traffic reduction include deferred transmission (to off-peak hours or using physical shipping) ๐Ÿ“ฆ Downlink traffic includes application control and software updates ๐ŸŽฎ Downlink-heavy traffic patterns aren't excluded, but they're more often associated with non-IoT usage (e.g., video Content Delivery Networks (CDNs)) ๐Ÿฟ

4.2. General Model ๐Ÿงฉ

okay bestie, edge computing is expected to be a HUGE deal ๐Ÿ’– for launching new IoT services that mix big data and AI, all powered by flexible in-network computing platforms โœจ. There are tons of ways to do edge computing, so this section sketches out one general model and lists the logical functions that come with it. In practice, this model can get mapped onto different architectures, like:

  • A single IoT gateway, or a hierarchy of IoT gateways, typically connected to the cloud (e.g., to extend the centralized cloud-based management of IoT devices and data to the edge). The IoT gateway plays a common role in providing access to a heterogeneous set of IoT devices and sensors, handling IoT data, and delivering IoT data to its final destination in a cloud network. An IoT gateway requires interactions with the cloud; however, it can also operate independently in a disconnected mode. ๐ŸŒธ
  • A set of distributed computing nodes, for example, embedded in switches, routers, edge cloud servers, or mobile devices. Some IoT devices have sufficient computing capabilities to join these distributed systems thanks to advances in hardware technology. In this model, edge computing nodes can collaborate to share resources. ๐Ÿฆ‹
  • A hybrid system involving both IoT gateways and supporting functions in distributed computing nodes. ๐Ÿ‘‘

So in the general model shown in Figure 1, the edge computing domain connects to IoT devices (southbound connectivity), possibly to a remote (e.g., cloud) network (northbound connectivity), and to a service operator's system. Edge computing nodes provide multiple logical functions or components, and not every system will have all of them. They may be implemented in a centralized or distributed fashion, at the network edge, or through interworking between the edge network and remote cloud networks. ๐Ÿซถ

            +---------------------+
            |   Remote Network    |  +---------------+
            |(e.g., cloud network)|  |   Service     |
            +-----------+---------+  |   Operator    |
                        |            +------+--------+
                        |                   |
         +--------------+-------------------+-----------+
         |            Edge Computing Domain             |
         |                                              |
         |   One or more computing nodes                |
         |   (IoT gateway, end devices, switches,       |
         |   routers, mini/micro-data centers, etc.)    |
         |                                              |
         |   OAM Components                             |
         |   - Resource Discovery and Authentication    |
         |   - Edge Organization and Federation         |
         |   - Multi-Tenancy and Isolation              |
         |   - ...                                      |
         |                                              |
         |   Functional Components                      |
         |   - In-Network Computation                   |
         |   - Edge Caching                             |
         |   - Communication                            |
         |   - Other Services                           |
         |   - ...                                      |
         |                                              |
         |   Application Components                     |
         |   - IoT Devices Management                   |
         |   - Data Management and Analytics            |
         |   - ...                                      |
         |                                              |
         +------+--------------+-------- - - - -+- - - -+
                |              |       |        |       |
                |              |          +-----+--+
           +----+---+    +-----+--+    |  |Compute |    |
           |  End   |    |  End   | ...   |Node/End|
           |Device 1|    |Device 2| ...|  |Device n|    |
           +--------+    +--------+       +--------+
                                       + - - - - - - - -+

Figure 1: Model of IoT Edge Computing

In the distributed model shown in Figure 2, the edge computing domain is made up of IoT edge gateways and IoT devices that double as computing nodes. Edge computing domains connect to a remote (e.g., cloud) network and to their respective service operator's system. The computing nodes provide logical functions, for example, as part of distributed machine learning or distributed image processing applications. IoT devices have limited processing capabilities, so they need support from other nodes. In a distributed machine learning application, the training process for AI services can run at IoT edge gateways or in cloud networks, while the prediction (inference) service runs in the IoT devices. Similarly, in a distributed image processing application, some image processing functions can run at the edge or in the cloud. To limit the amount of data uploaded to central cloud functions, IoT edge devices may pre-process data. ๐Ÿงš

         +----------------------------------------------+
         |            Edge Computing Domain             |
         |                                              |
         | +--------+    +--------+        +--------+   |
         | |Compute |    |Compute |        |Compute |   |
         | |Node/End|    |Node/End|  ....  |Node/End|   |
         | |Device 1|    |Device 2|  ....  |Device m|   |
         | +----+---+    +----+---+        +----+---+   |
         |      |             |                 |       |
         |  +---+-------------+-----------------+--+    |
         |  |           IoT Edge Gateway           |    |
         |  +-----------+-------------------+------+    |
         |              |                   |           |
         +--------------+-------------------+-----------+
                        |                   |
            +-----------+---------+  +------+-------+
            |   Remote Network    |  |   Service    |
            |(e.g., cloud network)|  |  Operator(s) |
            +-----------+---------+  +------+-------+
                        |                   |
         +--------------+-------------------+-----------+
         |              |                   |           |
         |  +-----------+-------------------+------+    |
         |  |           IoT Edge Gateway           |    |
         |  +---+-------------+-----------------+--+    |
         |      |             |                 |       |
         | +----+---+    +----+---+        +----+---+   |
         | |Compute |    |Compute |        |Compute |   |
         | |Node/End|    |Node/End|  ....  |Node/End|   |
         | |Device 1|    |Device 2|  ....  |Device n|   |
         | +--------+    +--------+        +--------+   |
         |                                              |
         |            Edge Computing Domain             |
         +----------------------------------------------+
 Figure 2: Example of Machine Learning over a Distributed IoT Edge
                          Computing System

Next up, we list the major edge computing domain components. They're loosely sorted into Operations, Administration, and Maintenance (OAM), functional, and application components ๐ŸŽ€, and the lines between these classes may not always be crystal clear, depending on the actual system architecture. Some representative research challenges are tied to those functions. Our input came from coauthors, participants of T2TRG meetings, and some comprehensive reviews of the field ([Yousefpour], [Zhang2], and [Khan]). ๐Ÿ“š

4.3. OAM Components โš™๏ธ

Edge computing OAM goes beyond the network-related OAM functions listed in [RFC6291]. On top of infrastructure (network, storage, and computing resources), edge computing systems can also include computing environments (for VMs, software containers, and functions), IoT devices, data, and code. ๐Ÿ’œ

Operation-related functions include performance monitoring for Service Level Agreement (SLA) measurements, fault management, and provisioning for links, nodes, compute and storage resources, platforms, and services. Administration covers network/compute/storage resources, platform and service discovery, configuration, and planning. Discovery during normal operation (e.g., discovery of compute or storage nodes by endpoints) is typically not included in OAM; however, in this document, we do not address it separately. Management covers monitoring and diagnosing failures, plus ways to minimise their occurrence and take corrective actions. This may include software update management and high service availability through redundancy and multipath communication. Centralized (e.g., Software-Defined Networking (SDN)) and decentralized management systems can both be used. Finally, we arbitrarily chose to address data management as an application component; however, in some systems, data management may be considered similar to a network management function. ๐Ÿฆ‹

We further detail a few relevant OAM components. โœจ

4.3.1. Resource Discovery and Authentication ๐Ÿ”

Discovery and authentication may target platforms and infrastructure resources, such as computing, networking, and storage, as well as other resources, such as IoT devices, sensors, data, code units, services, applications, and users interacting with the system. In a broker-based system, an IoT gateway can act as a broker to discover IoT resources. More decentralized solutions can also be used instead of or alongside broker-based solutions; for example, CoAP enables multicast discovery of an IoT device, and CoAP service discovery enables one to obtain a list of resources made available by this device [RFC7252]. For device authentication, current centralized gateway-based systems rely on installing a secret on IoT devices and computing devices (e.g., a device certificate stored in a hardware security module, or a combination of code and data stored in a trusted execution environment). ๐Ÿ”

Related challenges include:

  • Discovery, authentication, and trust establishment between IoT devices, compute nodes, and platforms, with regard to concerns such as mobility, heterogeneous devices and networks, scale, multiple trust domains, constrained devices, anonymity, and traceability. ๐Ÿ’…
  • Intermittent connectivity to the Internet, removing the need to rely on a third-party authority [Echeverria]. ๐ŸŒˆ
  • Resiliency to failure [Harchol], denial-of-service attacks, and easier physical access for attackers. ๐Ÿ’€

4.3.2. Edge Organization and Federation โœจ

okay so bestie, once edge devices have discovered and authenticated each other ๐Ÿซถ, they can get themselves organized (or self-organize!) into hierarchies or clusters ๐Ÿฆ‹. The structure can be anything from totally centralized to peer-to-peer, or it can be super tied up with other systems ๐Ÿ’…. These groups can also team up into federations with other edges or with remote clouds ๐Ÿ‘‘.

Related challenges include:

  • Support for scaling and enabling fault tolerance or self-healing [Jeong] ๐Ÿ˜ญ. A hierarchical organization helps with scaling, and another option that could work alongside it is multicast [RFC7390] [CORE-GROUPCOMM-BIS] ๐ŸŒˆ. Some folks also look at relying on blockchains [Ali] ๐Ÿ”—.
  • Integration of edge computing with virtualized Radio Access Networks (Fog RAN) [SFC-FOG-RAN] and 5G access networks ๐Ÿ“ก.
  • Sharing resources in multi-vendor and multi-operator scenarios to optimize criteria such as profit [Anglano], resource usage, latency, and energy consumption ๐Ÿ’ธ.
  • Capacity planning, placement of infrastructure nodes to minimize delay [Fan], cost, energy, etc. ๐Ÿ—บ๏ธ
  • Incentives for participation, for example, in peer-to-peer federation schemes ๐Ÿ“.
  • Design of federated AI over IoT edge computing systems [Brecko], for example, for anomaly detection ๐Ÿง .

4.3.3. Multi-Tenancy and Isolation ๐ŸŽ€

okay so some IoT edge computing systems use virtualized (compute, storage, and networking) resources to handle secure multi-tenancy at the edge ๐Ÿ . This gives us "edge clouds" that share properties with remote clouds and can reuse some of their ecosystems ๐ŸŒธ. Virtualization function management is mostly covered by ETSI NFV and MEC standards and recommendations ๐Ÿ“š. Projects like [LFEDGE-EVE] go even further and cover virtualization and its management in distributed edge computing settings โœจ.

Related challenges include:

  • Adapting cloud management platforms to the edge to account for its distributed nature, heterogeneity, need for customization, and limited resources (for example, using Conflict-free Replicated Data Types (CRDTs) [Jeffery] or intent-based management mechanisms [Cao]) ๐Ÿงฉ.
  • Minimizing virtual function instantiation time and resource usage โฑ๏ธ.

4.4. Functional Components ๐Ÿ’œ

4.4.1. In-Network Computation ๐Ÿ’ป

okay so a core function of IoT edge computing is enabling local computation on a node at the network edge ๐Ÿ”ฅ. This is typically for application-layer processing, like processing input data from sensors, making local decisions, preprocessing data, and offloading computation on behalf of a device, service, or user ๐Ÿงš. Related functions include orchestrating computation (in a centralized or distributed manner) and managing application life cycles ๐Ÿ”„. In-network computation can vary in capability. For example, computing nodes can host virtual machines, software containers, software actors, unikernels running stateful or stateless code, or a rule engine providing an API to register actions in response to conditions (such as an IoT device ID, sensor values to check, thresholds, etc.) ๐Ÿฆ„.

Edge offloading includes offloading to and from an IoT device and to and from a network node ๐Ÿ“ค. [Cloudlets] describes an example of offloading computation from an end device to a network node ๐Ÿ’œ. In contrast, oneM2M is an example of a system that lets a cloud-based IoT platform transfer resources and tasks to a target edge node [oneM2M-TR0052] ๐ŸŒค๏ธ. Once transferred, the edge node can directly support the IoT devices it serves with the service offloaded by the cloud (e.g., group management, location management, etc.) ๐Ÿซถ.

QoS can be provided in some systems through the combination of network QoS (e.g., traffic engineering or wireless resource scheduling) and compute and storage resource allocations ๐Ÿ“ถ. For example, in some systems, a bandwidth manager service can be exposed to enable allocation of bandwidth to or from an edge computing application instance ๐ŸŽฏ.

In-network computation can leverage the underlying services provided using data generated by IoT devices and access networks ๐ŸŒˆ. Such services include IoT device location, radio network information, bandwidth management, and congestion management (e.g., the congestion management feature of oneM2M [oneM2M-TR0052]) ๐Ÿ™Œ.

Related challenges include:

  • Computation placement: in a centralized or distributed (e.g., peer-to-peer) manner, selecting an appropriate compute device ๐Ÿงญ. The selection is based on available resources, location of data input and data sinks, compute node properties, etc., with varying goals. These goals include end-to-end latency, privacy, high availability, energy conservation, or network efficiency (for example, using load-balancing techniques to avoid congestion) ๐Ÿ’….
  • Onboarding code on a platform or computing device and invoking remote code execution, possibly as part of a distributed programming model and with respect to similar concerns of latency, privacy, etc. For example, offloading can be included in a vehicular scenario [Grewe] ๐Ÿš—. These operations should deal with heterogeneous compute nodes [Schafer] and may also support end devices, including IoT devices, as compute nodes [Larrea] ๐Ÿ“ฒ.
  • Adapting Quality of Results (QoR) for applications where a perfect result is not necessary [Li] ๐Ÿ’ฏ.
  • Assisted or automatic partitioning of code. For example, for application programs [COIN-APPCENTRES] or network programs [REQS-P4COMP] โœ‚๏ธ.
  • Supporting computation across trust domains. For example, verifying computation results ๐Ÿ”.
  • Supporting computation mobility: relocating an instance from one compute node to another while maintaining a given service level; session continuity when communicating with end devices that are mobile, possibly at high speed (e.g., in vehicular scenarios); defining lightweight execution environments for secure code mobility, for example, using WebAssembly [Nieke] ๐ŸŽ๏ธ.
  • Defining, managing, and verifying SLAs for edge computing systems; pricing is a challenging task ๐Ÿท๏ธ.

4.4.2. Edge Storage and Caching ๐Ÿ—„๏ธ

okay so local storage or caching lets us do local data processing (e.g., preprocessing or analysis) as well as delayed data transfer to the cloud or delayed physical shipping ๐Ÿ“ฆ. An edge node may offer local data storage (where persistence is subject to retention policies), caching, or both ๐Ÿ’พ. Generally, "caching" refers to temporary storage to improve performance without persistence guarantees ๐Ÿ’จ. An edge-caching component manages data persistence; for example, it schedules the removal of data when it is no longer needed ๐Ÿงน. Other related aspects include authentication and encryption of data ๐Ÿ”’. Edge storage and caching can take the form of a distributed storage system ๐ŸŒ.

Related challenges include:

  • Cache and data placement: using cache positioning and data placement strategies to minimize data retrieval delay [Liu] and energy consumption. Caches may be positioned in the access-network infrastructure or on end devices ๐Ÿ“.
  • Maintaining consistency, freshness, reliability, and privacy of data stored or cached in systems that are distributed, constrained, and dynamic (e.g., due to node mobility, energy-saving regimes, and disruptions) and which can have additional data governance constraints on data storage location. For example, [Mortazavi] describes leveraging a hierarchical storage organization. Freshness-related metrics include the age of information [Yates] that captures the timeliness of information received from a sender (e.g., an IoT device) โณ.

4.4.3. Communication ๐Ÿ“ก

okay so an edge cloud may provide a northbound data plane or management plane interface to a remote network, such as a cloud, home, or enterprise network โ˜๏ธ. This interface does not exist in stand-alone (local-only) scenarios ๐Ÿ๏ธ. To support it when it exists, an edge computing component needs to expose an API, deal with authentication and authorization, and support secure communication ๐Ÿ”‘.

An edge cloud may also provide an API or interface to local or mobile users, for example, to provide access to services and applications or to manage data published by local or mobile devices ๐Ÿ“ฑ.

Edge computing nodes communicate with IoT devices over a southbound interface, typically for data acquisition and IoT device management ๐Ÿ›ฐ๏ธ.

Communication brokering is a typical function of IoT edge computing ๐Ÿค. It facilitates communication with IoT devices, enables clients to register as recipients for data from devices, forwards traffic to or from IoT devices, and enables various data discovery and redistribution patterns (for example, north-south with clouds and east-west with other edge devices [EDGE-DATA-DISCOVERY-OVERVIEW]) ๐Ÿ”€. Another related aspect is dispatching alerts and notifications to interested consumers both inside and outside the edge computing domain ๐Ÿ””. Protocol translation, analytics, and video transcoding can also be performed when necessary ๐ŸŽฌ. Communication brokering may be centralized in some systems, for example, using a hub-and-spoke message broker, or distributed with message buses, possibly in a layered bus approach ๐Ÿ•ธ๏ธ. Distributed systems can leverage direct communication between end devices over device-to-device links ๐Ÿคณ. A broker can ensure communication reliability and traceability and, in some cases, transaction management ๐Ÿ“.

Related challenges include:

  • Defining edge computing abstractions, such as PaaS [Yangui], suitable for users and cloud systems to interact with edge computing systems, and dealing with interoperability issues, such as data-model heterogeneity ๐Ÿงฉ.
  • Enabling secure and resilient communication between IoT devices and a remote cloud, for example, through multipath support ๐Ÿ›ค๏ธ.

4.5. Application Components ๐Ÿฐ

IoT edge computing can host applications, such as those mentioned in Section 2.4. While describing the components of individual applications is out of our scope, some of those applications share similar functions, such as IoT device management and data management, as described below ๐ŸŽ€.

4.5.1. IoT Device Management ๐Ÿ› ๏ธ

okay so IoT device management includes managing information about IoT devices, including their sensors and how to communicate with them ๐Ÿ“‹. Edge computing tackles the scalability challenges of a large number of IoT devices by splitting the scalability domain into local (e.g., edge) networks and remote networks ๐ŸŒ. For example, in the context of the oneM2M standard, a device management functionality (called "software campaign" in oneM2M) enables the installation, deletion, activation, and deactivation of software functions and services on a potentially large number of edge nodes [oneM2M-TR0052] ๐Ÿ’ฟ. Using a dashboard or management software, a service provider issues these requests through an IoT cloud platform that supports the software campaign functionality ๐Ÿ–ฅ๏ธ.

The challenges listed in Section 4.3.1 may be applicable to IoT device management as well ๐Ÿฅน.

4.5.2. Data Management and Analytics โœจ

Okay bestie, data is where the magic happens ๐Ÿฆ‹ Storing and processing data at the edge is a huge part of IoT edge computing, and it directly tackles the big IoT challenges from Section 3. Analyzing data with AI/ML tasks right at the edge can seriously benefit from specialized hardware support on the computing nodes ๐Ÿค–๐Ÿ”ฅ

Here's what's giving "challenge" energy:

  • Data privacy and security ๐Ÿ” Handling data while sharing, processing, discovering, or managing it means dealing with resource usage, security, and privacy. Some examples are showing data in views that bundle related data together [Zhang], protecting data communication between authenticated peers [Basudan], classifying data by privacy, importance, and validity, and compressing and encrypting it. You can even use homomorphic encryption to process encrypted data directly [Stanciu] ๐Ÿง 
  • Edge data discovery ๐Ÿ” Streaming data, metadata, and events are harder to find because of siloization and a lack of standards. This gets worse in dynamic environments like vehicular networks and in heterogeneous ones [EDGE-DATA-DISCOVERY-OVERVIEW] ๐Ÿš—
  • Data-driven programming models ๐Ÿ’ป Models such as event-based ones [Renart] bring their own problems, including handling naming and data abstractions.
  • Data integration ๐Ÿงฉ It gets messy when there's no data standardization, or when different sources use different ontologies [Farnbauer-Schmidt].
  • Machine learning at the edge ๐Ÿค– Limited resources, privacy, and dynamic and heterogeneous environments make deploying ML at the edge tricky. The fixes include making ML more lightweight and distributed (for example, enabling distributed inference at the edge), supporting shorter training times and simplified models, and supporting models that can be compressed for efficient communication [Murshed] โœจ
  • Edge and cloud together โ˜๏ธ Edge computing can support IoT services on its own, but it can also connect to cloud computing. So the relationship between IoT edge computing and cloud computing, when it comes to data management, is another potential challenge [ISO_TR] ๐Ÿ’…

4.6. Simulation and Emulation Environments ๐Ÿงช

IoT edge computing brings new challenges for the simulation and emulation tools that researchers and developers use ๐Ÿ˜ญ A mix of applications, networks, and computing technologies can coexist in one distributed system, which makes modeling really hard. Scale, mobility, and resource management are extra challenges too [SimulatingFog].

There are two main kinds of tools. Simulators run simplified application logic on top of a fog network model. Emulators let you deploy actual applications, usually in software containers, over a cloud infrastructure (for example, Docker and Kubernetes). That infrastructure runs over a network that emulates edge conditions like variable delays, throughput, and mobility events ๐ŸŒˆ To gain scale, emulated and simulated systems can be used together in hybrid federation-based approaches [PseudoDynamicTesting]. To gain realism, physical devices can be interconnected with emulated systems.

Some related work and platforms are the publicly accessible MEC sandbox work recently started in ETSI [ETSI_Sandbox], and open-source simulators and emulators, like the [AdvantEDGE] emulator and the tools cited in [SimulatingFog]. EdgeNet [Senel] is a globally distributed edge cloud for Internet researchers. It uses nodes contributed by institutions and is built on Docker for containerization and Kubernetes for deployment and node management ๐Ÿ“

Digital twins are virtual instances of a physical system (the twin) that are continually updated with that system's performance, maintenance, and health status data throughout its life cycle [Madni] ๐Ÿ‘ฏ Unlike an emulation or simulated environment, a digital twin, once generated, is kept in sync by its physical twin. That physical twin can be many things, including an IoT device, an edge device, or an edge network. Digital twins are said to go beyond emulation, with accelerated business processes, enhanced productivity, and faster innovation at reduced costs [NETWORK-DIGITAL-TWIN-ARCH] ๐Ÿ’œ

5. Security Considerations ๐Ÿ›ก๏ธ

Privacy and security are big drivers for adopting edge computing for the IoT (Section 3.4). As discussed in Section 4.3.1, authentication and trust (among computing nodes, management nodes, and end devices) can get really challenging as scale, mobility, and heterogeneity increase ๐Ÿ˜ฌ The sometimes disconnected nature of edge resources can help avoid relying on third-party authorities. Distributed edge computing is exposed to reliability and denial-of-service attacks โš ๏ธ Personal or proprietary IoT data leakage is also a major threat, especially because of how distributed these systems are (Section 4.5.2).

Furthermore, blockchain-based distributed IoT edge computing must be designed for privacy, since public blockchain addressing does not guarantee absolute anonymity [Ali]. Not me being this serious, but this one is a must-know ๐Ÿ’€

Edge computing also brings security solutions though ๐Ÿซถ Keeping privacy is a major use case for IoT edge computing, since sensitive data gets computed closer to where it's generated. An edge cloud can be used to take actions based on sensitive data, or to anonymize or aggregate data before it's sent to a remote cloud server. Edge computing communication brokering functions can also be used to secure communication between edge and cloud networks ๐Ÿ”’

6. Conclusion ๐ŸŽ€

IoT edge computing plays an essential role, working alongside the cloud, in enabling IoT systems in certain situations ๐ŸŒธ In this document, we presented use cases and listed the core challenges the IoT faces that drive the need for IoT edge computing. So the first part of this document may help focus future research on the aspects of IoT edge computing where it's most useful โœจ The second part presents a general system model and a structured overview of the related research challenges and work. The structure, based on the system model, isn't meant to be restrictive. It exists so there's a link between individual research areas and where they apply in an IoT edge computing system ๐Ÿ‘‘

7. IANA Considerations ๐Ÿงš

This document has no IANA actions. Nothing to register here, periodt ๐Ÿ’…

8. Informative References ๐Ÿ“š

[AdvantEDGE] "AdvantEDGE, Mobile Edge Emulation Platform", commit 8f6edbe, May 2023, <https://github.com/InterDigitalInc/AdvantEDGE>.

[Ali] Ali, M., Vecchio, M., and F. Antonelli, "Enabling a Blockchain-Based IoT Edge", IEEE Internet of Things Magazine, vol. 1, no.2, pp. 24-29, DOI 10.1109/IOTM.2019.1800024, December 2018, <https://doi.org/10.1109/IOTM.2019.1800024>.

[Anglano] Anglano, C., Canonico, M., Castagno, P., Guazzone, M., and M. Sereno, "A game-theoretic approach to coalition formation in fog provider federations", 2018 Third International Conference on Fog and Mobile Edge Computing (FMEC), DOI 10.1109/fmec.2018.8364054, April 2018, <https://doi.org/10.1109/fmec.2018.8364054>.

[Argungu] Argungu, J., Idina, M., Chalawa, U., Ummar, M., Bello, S., Arzika, I., and B. Mala, "A Survey of Edge Computing Approaches in Smart Factory", International Journal of Advanced Research in Computer and Communication Engineering, Vol. 12, Issue 9, September 2023.

[Ashton] Ashton, K., "That 'Internet of Things' Thing", RFID Journal, vol. 22, no. 7, pp. 97-114, June 2009, <http://www.itrco.jp/libraries/RFIDjournal-That%20Internet%20of%20Things%20Thing.pdf>.

[Badjie] Badjie, B., "The Future of Autonomous Driving Systems with Edge Computing", September 2023, <https://medium.com/@bakarykumba1996/the-future-of-autonomous-driving-systems-with-edge-computing-8c919597c4ee>.

[Basudan] Basudan, S., Lin, X., and K. Sankaranarayanan, "A Privacy-Preserving Vehicular Crowdsensing-Based Road Surface Condition Monitoring System Using Fog Computing", IEEE Internet of Things Journal, vol. 4, no. 3, pp. 772-782, DOI 10.1109/jiot.2017.2666783, June 2017, <https://doi.org/10.1109/jiot.2017.2666783>.

[BigRentz] BigRentz, "41 Construction Safety Statistics for 2024", February 2024, <https://www.bigrentz.com/blog/construction-safety-statistics>.

[Botta] Botta, A., de Donato, W., Persico, V., and A. Pescapรฉ, "Integration of Cloud computing and Internet of Things: A survey", Future Generation Computer Systems, vol. 56, pp. 684-700, DOI 10.1016/j.future.2015.09.021, March 2016, <https://doi.org/10.1016/j.future.2015.09.021>.

[Brecko] Brecko, A., Kajรกti, E., Koziorek, J., and I. Zolotovรก, "Federated Learning for Edge Computing: A Survey", Applied Sciences 12(18):9124, DOI 10.3390/app12189124, September 2022, <https://doi.org/10.3390/app12189124>.

[Cao] Cao, L., Merican, A., Tootaghaj, D., Ahmed, F., Sharma, P., and V. Saxena, "eCaaS: A Management Framework of Edge Container as a Service for Business Workload", Proceedings of the 4th International Workshop on Edge Systems, Analytics and Networking, DOI 10.1145/3434770.3459741, April 2021, <https://doi.org/10.1145/3434770.3459741>.

[CertMagic] CertMagic, "Digital Twin Technology: Simulating Real-World Scenarios for Enhanced Decision Making", May 2023, <https://certmagic.medium.com/digital-twin-technology-simulating-real-world-scenarios-for-enhanced-decision-making-8844c51e856d>.

[Chen] Chen, B., Wan, J., Celesti, A., Li, D., Abbas, H., and Q. Zhang, "Edge Computing in IoT-Based Manufacturing", IEEE Communications Magazine, vol. 56, no. 9, pp. 103-109, DOI 10.1109/mcom.2018.1701231, September 2018, <https://doi.org/10.1109/mcom.2018.1701231>.

[Chiang] Chiang, M. and T. Zhang, "Fog and IoT: An Overview of Research Opportunities", IEEE Internet of Things Journal, vol. 3, no. 6, pp. 854-864, DOI 10.1109/jiot.2016.2584538, December 2016, <https://doi.org/10.1109/jiot.2016.2584538>.

[Chipmunk] Shin, Y., Park, S., Ko, N., and A. Jeong, "Chipmunk: Distributed Object Storage for NDN", Proceedings of the 7th ACM Conference on Information-Centric Networking, ACM, DOI 10.1145/3405656.3420231, September 2020, <https://doi.org/10.1145/3405656.3420231>.

[Cloudlets] Satyanarayanan, M., Bahl, P., Caceres, R., and N. Davies, "The Case for VM-Based Cloudlets in Mobile Computing", IEEE Pervasive Computing, vol. 8, no. 4, pp. 14-23, DOI 10.1109/mprv.2009.82, October 2009, <https://doi.org/10.1109/mprv.2009.82>.

[COIN-APPCENTRES] Trossen, D., Sarathchandra, C., and M. Boniface, "In-Network Computing for App-Centric Micro-Services", Work in Progress, Internet-Draft, draft-sarathchandra-coin-appcentres-04, 26 January 2021, <https://datatracker.ietf.org/doc/html/draft-sarathchandra-coin-appcentres-04>.

okay bestie, the citations keep coming ๐Ÿ“šโœจ these are the sources the RFC leans on for all the edge and IoT background, so here's every single one, fully intact ๐Ÿ’…

that's the whole reference list, bestie!! ๐ŸŒˆ๐Ÿ’œ

[oneM2M-TR0001] Mladin, C., "Use Cases Collection", oneM2M, v4.2.0, TR 0001, October 2018, <https://member.onem2m.org/Application/documentapp/downloadLatestRevision/default.aspx?docID=28153>.

[oneM2M-TR0018] Lu, C. and M. Jiang, "Industrial Domain Enablement", oneM2M, v2.5.2, TR 0018, February 2019, <https://member.onem2m.org/Application/documentapp/downloadLatestRevision/default.aspx?docID=29334>.

[oneM2M-TR0026] Yamamoto, K., Mladin, C., and V. Kueh, "Vehicular Domain Enablement", oneM2M, TR 0026, January 2020, <https://member.onem2m.org/Application/documentapp/downloadLatestRevision/default.aspx?docID=31410>.

[oneM2M-TR0052] Yamamoto, K. and C. Mladin, "Study on Edge and Fog Computing in oneM2M systems", oneM2M, TR 0052, September 2020, <https://member.onem2m.org/Application/documentapp/downloadLatestRevision/default.aspx?docID=32633>.

[oneM2M-TS0002] He, S., "TS 0002, Requirements", oneM2M, TS 0002, February 2019, <https://member.onem2m.org/Application/documentapp/downloadLatestRevision/default.aspx?docID=29274>.

[OpenFog] OpenFog Consortium, "OpenFog Reference Architecture for Fog Computing", February 2017, <https://iiconsortium.org/pdf/OpenFog_Reference_Architecture_2_09_17.pdf>.

[PseudoDynamicTesting] Ficco, M., Esposito, C., Xiang, Y., and F. Palmieri, "Pseudo-Dynamic Testing of Realistic Edge-Fog Cloud Ecosystems", IEEE Communications Magazine, vol. 55, no. 11, pp. 98-104, DOI 10.1109/mcom.2017.1700328, November 2017, <https://doi.org/10.1109/mcom.2017.1700328>.

[Renart] Renart, E., Diaz-Montes, J., and M. Parashar, "Data-Driven Stream Processing at the Edge", 2017 IEEE 1st International Conference on Fog and Edge Computing (ICFEC), DOI 10.1109/icfec.2017.18, May 2017, <https://doi.org/10.1109/icfec.2017.18>.

[REQS-P4COMP] Singh, H. and M. Montpetit, "Requirements for P4 Program Splitting for Heterogeneous Network Nodes", Work in Progress, Internet-Draft, draft-hsingh-coinrg-reqs-p4comp-03, 18 February 2021, <https://datatracker.ietf.org/doc/html/draft-hsingh-coinrg-reqs-p4comp-03>.

[REST-IOT] Kerรคnen, A., Kovatsch, M., and K. Hartke, "Guidance on RESTful Design for Internet of Things Systems", Work in Progress, Internet-Draft, draft-irtf-t2trg-rest-iot-13, 25 January 2024, <https://datatracker.ietf.org/doc/html/draft-irtf-t2trg-rest-iot-13>.

[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, <https://www.rfc-editor.org/info/rfc6291>.

[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for the Constrained Application Protocol (CoAP)", RFC 7390, DOI 10.17487/RFC7390, October 2014, <https://www.rfc-editor.org/info/rfc7390>.

[RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", RFC 8578, DOI 10.17487/RFC8578, May 2019, <https://www.rfc-editor.org/info/rfc8578>.

[Schafer] Schรคfer, D., Edinger, J., VanSyckel, S., Paluska, J., and C. Becker, "Tasklets: Overcoming Heterogeneity in Distributed Computing Systems", 2016 IEEE 36th International Conference on Distributed Computing Systems Workshops (ICDCSW), DOI 10.1109/icdcsw.2016.22, June 2016, <https://doi.org/10.1109/icdcsw.2016.22>.

[Senel] ลženel, B., Mouchet, M., Cappos, J., Fourmaux, O., Friedman, T., and R. McGeer, "EdgeNet: A Multi-Tenant and Multi-Provider Edge Cloud", Proceedings of the 4th International Workshop on Edge Systems, Analytics and Networking, DOI 10.1145/3434770.3459737, April 2021, <https://doi.org/10.1145/3434770.3459737>.

[SFC-FOG-RAN] Bernardos, C. J. and A. Mourad, "Service Function Chaining Use Cases in Fog RAN", Work in Progress, Internet-Draft, draft-bernardos-sfc-fog-ran-10, 22 October 2021, <https://datatracker.ietf.org/doc/html/draft-bernardos-sfc-fog-ran-10>.

[Shi] Shi, W., Cao, J., Zhang, Q., Li, Y., and L. Xu, "Edge Computing: Vision and Challenges", IEEE Internet of Things Journal, vol. 3, no. 5, pp. 637-646, DOI 10.1109/jiot.2016.2579198, October 2016, <https://doi.org/10.1109/jiot.2016.2579198>.

[SimulatingFog] Svorobej, S., Takako Endo, P., Bendechache, M., Filelis-Papadopoulos, C., Giannoutakis, K., Gravvanis, G., Tzovaras, D., Byrne, J., and T. Lynn, "Simulating Fog and Edge Computing Scenarios: An Overview and Research Challenges", Future Internet, vol. 11, no. 3, pp. 55, DOI 10.3390/fi11030055, February 2019, <https://doi.org/10.3390/fi11030055>.

[Stanciu] Stanciu, V., Steen, M., Dobre, C., and A. Peter, "Privacy-Preserving Crowd-Monitoring Using Bloom Filters and Homomorphic Encryption", Proceedings of the 4th International Workshop on Edge Systems, Analytics and Networking, DOI 10.1145/3434770.3459735, April 2021, <https://doi.org/10.1145/3434770.3459735>.

[Tanveer] Tanveer, S., Sree, N., Bhavana, B., and D. Varsha, "Smart Agriculture System using IoT", 2022 IEEE World Conference on Applied Intelligence and Computing (AIC), Sonbhadra, India, pp. 482-486, DOI 10.1109/AIC55036.2022.9848948, August 2022, <https://doi.org/10.1109/AIC55036.2022.9848948>.

[Weiner] Weiner, M., Jorgovanovic, M., Sahai, A., and B. Nikolie, "Design of a low-latency, high-reliability wireless communication system for control applications", 2014 IEEE International Conference on Communications (ICC), DOI 10.1109/icc.2014.6883918, June 2014, <https://doi.org/10.1109/icc.2014.6883918>.

[Yangui] Yangui, S., Ravindran, P., Bibani, O., Glitho, R., Ben Hadj-Alouane, N., Morrow, M., and P. Polakos, "A platform as-a-service for hybrid cloud/fog environments", 2016 IEEE International Symposium on Local and Metropolitan Area Networks (LANMAN), DOI 10.1109/lanman.2016.7548853, June 2016, <https://doi.org/10.1109/lanman.2016.7548853>.

[Yates] Yates, R. and S. Kaul, "The Age of Information: Real-Time Status Updating by Multiple Sources", IEEE Transactions on Information Theory, vol. 65, no. 3, pp. 1807-1827, DOI 10.1109/tit.2018.2871079, March 2019, <https://doi.org/10.1109/tit.2018.2871079>.

[Yousefpour] Yousefpour, A., Fung, C., Nguyen, T., Kadiyala, K., Jalali, F., Niakanlahiji, A., Kong, J., and J. Jue, "All one needs to know about fog computing and related edge computing paradigms: A complete survey", Journal of Systems Architecture, vol. 98, pp. 289-330, DOI 10.1016/j.sysarc.2019.02.009, September 2019, <https://doi.org/10.1016/j.sysarc.2019.02.009>.

[Yue] Yue, Q., Mu, S., Zhang, L., Wang, Z., Zhang, Z., Zhang, X., Wang, Y., and Z. Miao, "Assisting Smart Construction With Reliable Edge Computing Technology", Frontiers in Energy Research, Sec. Smart Grids, Vol. 10, DOI 10.3389/fenrg.2022.900298, May 2022, <https://doi.org/10.3389/fenrg.2022.900298>.

[Zhang] Zhang, Q., Zhang, X., Zhang, Q., Shi, W., and H. Zhong, "Firework: Big Data Sharing and Processing in Collaborative Edge Environment", 2016 Fourth IEEE Workshop on Hot Topics in Web Systems and Technologies (HotWeb), DOI 10.1109/hotweb.2016.12, October 2016, <https://doi.org/10.1109/hotweb.2016.12>.

[Zhang2] Zhang, J., Chen, B., Zhao, Y., Cheng, X., and F. Hu, "Data Security and Privacy-Preserving in Edge Computing Paradigm: Survey and Open Issues", IEEE Access, vol. 6, pp. 18209-18237, DOI 10.1109/access.2018.2820162, March 2018, <https://doi.org/10.1109/access.2018.2820162>.

Acknowledgements

Bestie, the authors want to give a huge shout-out ๐Ÿซถ to Joo-Sang Youn, Akbar Rahman, Michel Roy, Robert Gazda, Rute Sofia, Thomas Fossati, Chonggang Wang, Marie-Josรฉ Montpetit, Carlos J. Bernardos, Milan Milenkovic, Dale Seed, JaeSeung Song, Roberto Morabito, Carsten Bormann, and Ari Kerรคnen for their valuable comments and suggestions on this document. ๐Ÿ’œโœจ

Authors' Addresses

Jungha Hong
ETRI
218 Gajeong-ro, Yuseung-Gu
Daejeon
34129
Republic of Korea
Email: jhong@etri.re.kr


Yong-Geun Hong
Daejeon University
62 Daehak-ro, Dong-gu
Daejeon
300716
Republic of Korea
Email: yonggeun.hong@gmail.com


Xavier de Foy
InterDigital Communications, LLC
1000 Sherbrooke West
Montreal  H3A 3G4
Canada
Email: xavier.defoy@interdigital.com


Matthias Kovatsch
Huawei Technologies Duesseldorf GmbH
Riesstr. 25 C // 3.OG
80992 Munich
Germany
Email: ietf@kovatsch.net


Eve Schooler
University of Oxford
Parks Road
Oxford
OX1 3PJ
United Kingdom
Email: eve.schooler@gmail.com


Dirk Kutscher
Hong Kong University of Science and Technology (Guangzhou)
No.1 Du Xue Rd
Guangzhou
China
Email: ietf@dkutscher.net
๐Ÿ“ฆ where this page comes from