Network Working Group C. A. Kamienski
Internet-Draft Federal University of ABC (UFABC)
Intended status: Informational M. Santos
Expires: 26 April 2027 Federal Institute of Sertão (IFSertão)
M. D. Felice
University of Bologna
23 October 2026
Application-Centric Considerations for Deployment over the IoT Computing
Continuum
draft-kamienski-iot-deployment-00
Abstract
Smart applications increasingly depend on the Internet of Things
(IoT) and distributed computing environments spanning constrained
devices, edge nodes, cloudlets, and cloud infrastructure,
collectively known as the edge–cloud, or computing continuum. This
document uses the term IoT computing continuum to highlight the
importance of IoT-specific constraints and requirements within this
broader context. Although prior work has addressed communication
aspects and edge functions in these environments, as noted in RFC
9556 and comprehensive surveys of the computing continuum, there has
been comparatively less focus on application-centric issues such as
deployment, placement, and lifecycle management. This document
identifies key challenges and conceptual considerations for deploying
smart applications across the IoT computing continuum, aiming to
provide a unified architectural perspective and vocabulary to guide
ongoing research within the IRTF and inform future standardization
initiatives.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://CarlosKamienski.github.io/Internet-Draft/draft-kamienski-iot-
deployment.html. Status information for this document may be found
at https://datatracker.ietf.org/doc/draft-kamienski-iot-deployment/.
Source for this draft and an issue tracker can be found at
https://github.com/CarlosKamienski/Internet-Draft.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Kamienski, et al. Expires 26 April 2027 [Page 1]
Internet-Draft IoTinummDeploy October 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 26 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Background: The IoT Computing Continuum . . . . . . . . . . . 6
5. An Application-Centric View of the Continuum . . . . . . . . 7
5.1. Applications as Distributed Functional Graphs . . . . . . 7
5.2. Decoupling Application Logic from Execution
Environments . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Placement and Distribution Across the Continuum . . . . . 8
5.4. Application Lifecycle Beyond Initial Deployment . . . . . 8
6. Challenges in Smart Application Development and Deployment . 9
7. Conceptual Deployment Model . . . . . . . . . . . . . . . . . 10
8. Illustrative Scenarios . . . . . . . . . . . . . . . . . . . 12
8.1. Smart Irrigation in Precision Agriculture . . . . . . . . 12
8.2. Drone-Based Delivery in Urban Environments . . . . . . . 13
8.3. Discussion . . . . . . . . . . . . . . . . . . . . . . . 15
9. The Role of AI Agents in Application Deployment . . . . . . . 15
9.1. Agents as Enablers of the Deployment Process . . . . . . 16
9.2. Deployment of the Agents Themselves . . . . . . . . . . . 17
10. Relationship to Ongoing Research and Standardization . . . . 17
10.1. Device Update, Discovery, and Management . . . . . . . . 18
10.2. Computing in the Network and Intent . . . . . . . . . . 19
10.3. Agent Communication and Dialog Management . . . . . . . 19
Kamienski, et al. Expires 26 April 2027 [Page 2]
Internet-Draft IoTinummDeploy October 2026
10.4. Descriptions of Things and Application Abstractions . . 20
11. Research Directions . . . . . . . . . . . . . . . . . . . . . 20
12. Security Considerations . . . . . . . . . . . . . . . . . . . 22
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
15. Informative References . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The Internet of Things (IoT) has evolved from simple data-collection
systems into a foundation for complex, data-driven smart applications
across domains such as smart cities, precision agriculture,
industrial automation, and healthcare. These applications
increasingly depend on distributed computing resources to sense,
process, and act on data close to where it is generated, while also
leveraging large-scale cloud infrastructures for coordination,
analytics, and long-term storage.
This evolution has led to the emergence of a distributed computing
environment spanning multiple stages, from highly constrained devices
and gateways to edge nodes, cloudlets, and centralized cloud
platforms. The literature commonly describes this environment as the
edge-cloud continuum, IoT-edge-cloud continuum, or simply the
computing continuum. Comprehensive perspectives on the evolution of
this paradigm are provided in [CONTINUUM-SURVEY]. In this document,
the term IoT computing continuum emphasizes the presence of
constrained IoT devices and the domain-specific requirements they
introduce.
Recent research and standardization efforts have highlighted this
continuum and discussed challenges related to edge functions, data
handling, and communication across heterogeneous environments,
including IETF and IRTF work such as [RFC9556]. However, much of the
existing discussion remains infrastructure- or communication-centric,
with comparatively less focus on the implications for smart
application deployment and lifecycle management.
From an application perspective, smart services are no longer
confined to a single execution environment. Instead, they comprise
multiple functions that must be placed, coordinated, and potentially
migrated across stages of the IoT computing continuum to meet
requirements for latency, resilience, scalability, privacy, and
energy efficiency. In practice, these decisions are often handled
manually or through ad hoc mechanisms, leading to fragmented
solutions and limited portability across deployments.
Kamienski, et al. Expires 26 April 2027 [Page 3]
Internet-Draft IoTinummDeploy October 2026
The lack of a shared, application-centric view of deployment over the
IoT computing continuum creates challenges for both researchers and
practitioners. It complicates systematic reasoning about application
structure, hinders the comparison of alternative approaches, and
makes it difficult to identify common requirements that could inform
future research and standardization activities.
This document contributes to this discussion by examining smart
application deployment across the IoT computing continuum from a
conceptual and architectural perspective. Rather than proposing
specific mechanisms or protocols, it identifies key challenges,
clarifies terminology, and outlines considerations relevant to
ongoing research within the Thing-to-Thing Research Group (T2TRG) of
the Internet Research Task Force (IRTF).
2. Scope and Non-Goals
This document focuses on conceptual and architectural considerations
for deploying smart applications across the IoT computing continuum.
It focuses on challenges, common patterns, and terminology arising
from distributed application logic across heterogeneous computing
environments, including constrained IoT devices, edge nodes, and
cloud platforms. The intent is to support research-oriented
discussion and provide a shared frame of reference for ongoing and
future IRTF work. The discussion explicitly considers the interplay
between application development and deployment, while remaining
agnostic to specific tools, workflows, or operational practices.
The document does not specify concrete deployment mechanisms,
protocols, or interfaces. It does not define a reference
architecture or mandate how applications should be structured,
deployed, or managed in practice. Instead, it describes the problem
space and highlights issues relevant across multiple technologies,
deployment models, and research efforts.
In particular, the following items are explicitly outside the scope
of this document:
* The specification of new communication protocols, APIs, or data
models.
* The definition of normative requirements, including the use of
requirement keywords such as MUST, SHOULD, or MAY.
* The standardization of specific platforms, frameworks, or
programming models for IoT application deployment.
Kamienski, et al. Expires 26 April 2027 [Page 4]
Internet-Draft IoTinummDeploy October 2026
* Detailed performance evaluations or quantitative comparisons
between alternative solutions.
By clearly delineating its scope and non-goals, this document
complements existing and ongoing efforts in the computing continuum,
including work on communication, edge functions, and operational
aspects, while maintaining a technology-agnostic, application-centric
perspective.
3. Terminology
This document uses the following terms with the meanings indicated
below. These definitions clarify usage in this document and are not
meant to redefine existing terminology used elsewhere.
*Internet of Things (IoT):* A system paradigm involving
interconnected physical objects equipped with sensing, actuation,
processing, and communication capabilities, operating under resource
constraints, as discussed in [RFC7452].
*Constrained Devices:* Devices with limited processing power, memory,
energy availability, or communication capabilities. The use of the
term _constrained_ in this document follows the terminology defined
in [I-D.ietf-iotops-7228bis].
*IoT Computing Continuum:* A distributed execution environment
spanning constrained IoT devices, edge nodes, cloud platforms, and
network elements that provide suitable processing capabilities.
Application functions may execute at different stages, depending on
their requirements and the capabilities and constraints of each
environment. These stages are not restricted to general-purpose
computing hosts: programmable network elements can also execute
eligible functions as part of the continuum, integrating the notion
of Computing in the Network (COIN). The shorthand term _IoTinuum_
has been used in related work to denote this same concept [IOTINUUM].
This document uses the expanded form throughout for clarity and
alignment with terminology used in related standardization efforts.
*Edge Node:* An intermediate computing node between constrained
devices and centralized cloud infrastructure, providing computation,
storage, and networking closer to data sources, as described in
[RFC9556].
*Orchestration and Choreography:* Two coordination styles for
distributed applications. Orchestration refers to coordination
driven by explicit control logic, while choreography relies on
decentralized interactions among components without a central
coordinator.
Kamienski, et al. Expires 26 April 2027 [Page 5]
Internet-Draft IoTinummDeploy October 2026
4. Background: The IoT Computing Continuum
The increasing distribution of computation across networked systems
has led to the emergence of what is commonly described as a computing
continuum, spanning centralized cloud infrastructures, intermediate
edge and fog nodes, and highly constrained end devices
[CONTINUUM-SURVEY]. This paradigm reflects a shift away from
strictly centralized processing models toward more distributed
execution, driven by requirements related to latency, bandwidth
efficiency, resilience, data locality, and regulatory constraints.
Within the context of the Internet of Things (IoT), this continuum
acquires additional characteristics that distinguish it from more
general edge-cloud computing environments. IoT deployments involve
large numbers of heterogeneous devices with severe resource
constraints, intermittent connectivity, and close interaction with
the physical world through sensing and actuation [RFC7452]. As a
result, computation is often pushed closer to data sources not only
for performance reasons, but also to enable timely control actions,
reduce energy consumption, and preserve privacy.
Recent research and standardization activities have explored
different aspects of this continuum. In particular, work within the
IETF and IRTF has highlighted the importance of edge computing and
has discussed functional components and challenges associated with
operating across distributed environments [RFC9556]. Existing
documents have examined edge functions for data processing, storage,
and communication, as well as the roles of gateways and intermediate
nodes in bridging constrained devices to cloud services. These
efforts provide an important foundation for understanding the
structural and operational properties of the continuum.
This document takes a complementary rather than competing
perspective. While [RFC9556] characterizes functional components and
infrastructure-level challenges, focusing on edge functions and the
communication fabric that supports them, this document shifts
attention to the application layer that runs on top of that
infrastructure. Specifically, it considers how smart applications,
composed of multiple interdependent functions, are decomposed,
placed, coordinated, and managed across the heterogeneous stages
enabled by that infrastructure. Application-centric concerns such as
functional decomposition, placement, coordination style, and
lifecycle management are largely orthogonal to the infrastructure
view and remain comparatively underexplored in current
standardization discussions.
Kamienski, et al. Expires 26 April 2027 [Page 6]
Internet-Draft IoTinummDeploy October 2026
This document adopts the term _IoT computing continuum_ to refer to
this distributed execution environment, encompassing constrained IoT
devices, edge nodes, cloud platforms, and network elements with
processing capabilities. The continuum naturally accommodates
Computing in the Network (COIN): application processing can include
eligible functions executed within the network. For example,
filtering, aggregation, or preprocessing may execute in a
programmable network element when its capabilities and the
application semantics permit. This does not imply that every network
element is programmable or that every application function is
suitable for in-network execution. Building on existing work, the
focus here is on understanding how the properties of the IoT
computing continuum influence application deployment, placement, and
lifecycle management, rather than on defining specific technologies
or architectural solutions.
5. An Application-Centric View of the Continuum
Traditional IoT architectures often treat applications as tightly
coupled to specific execution environments, typically assuming fixed
roles for devices, gateways, and cloud services. In the context of
the IoT computing continuum, this assumption no longer holds. Smart
applications must be understood as distributed entities whose
behavior emerges from the coordinated execution of multiple
components across heterogeneous computing stages. An application-
centric view is therefore essential for reasoning about deployment,
adaptation, and lifecycle management in such environments.
5.1. Applications as Distributed Functional Graphs
From an application-centric perspective, smart applications can be
modeled as collections of interdependent functions rather than as
monolithic software artifacts. These functions interact through
well-defined data and control dependencies, forming a logical
application graph that captures the application's structure
independently of where its components execute. This representation
enables reasoning about application behavior, dependencies, and
composition without prematurely binding functions to specific devices
or platforms.
Viewing applications as distributed functional graphs is particularly
relevant in IoT environments, where different functions may have
distinct requirements for latency, computational resources, sensor or
actuator access, and interaction with external services. By
separating the application's logical structure from its physical
deployment, this model supports more flexible placement and
adaptation strategies across the continuum.
Kamienski, et al. Expires 26 April 2027 [Page 7]
Internet-Draft IoTinummDeploy October 2026
5.2. Decoupling Application Logic from Execution Environments
A key implication of the application-centric view is decoupling
application logic from execution environments. Application
functionality should be expressed in a way that is independent of
specific hardware platforms, operating systems, or runtime
environments. This decoupling enables portability across
heterogeneous devices and supports dynamic reassignment of
application components as execution conditions change.
In the IoT computing continuum, execution environments vary widely in
terms of resource availability, connectivity, and operational
constraints. Binding application logic too early to a particular
environment limits the ability to adapt to failures, load variations,
or evolving requirements. An application-centric approach instead
treats execution environments as abstract resources onto which
application functions can be mapped, allowing deployment decisions to
be revisited over time.
5.3. Placement and Distribution Across the Continuum
Once application logic is decoupled from execution environments,
placing application functions becomes a first-class concern.
Placement decisions determine where an application's functions
execute within the IoT computing continuum, from constrained devices
and gateways to edge nodes and cloud platforms. These decisions
directly affect end-to-end application properties, including latency,
reliability, energy consumption, and data locality.
Importantly, placement is not static. In many scenarios, application
components may need to be redistributed in response to changes in
workload, network conditions, or operational context. An
application-centric view highlights the need to reason about
placement and distribution as dynamic processes intrinsic to how
smart applications operate across the continuum.
5.4. Application Lifecycle Beyond Initial Deployment
In centralized systems, application deployment is often treated as a
one-time event followed by relatively infrequent updates. In
contrast, the IoT computing continuum introduces a more complex and
dynamic application lifecycle. Beyond initial deployment,
applications may undergo continuous adaptation, including updates,
reconfiguration, scaling, component migration, and partial
redeployment across different continuum stages.
Kamienski, et al. Expires 26 April 2027 [Page 8]
Internet-Draft IoTinummDeploy October 2026
Managing this lifecycle is particularly challenging in IoT
environments due to device heterogeneity, intermittent connectivity,
and the coexistence of multiple administrative domains. An
application-centric perspective emphasizes that lifecycle management
must be considered holistically, encompassing not only software
updates but also the ongoing coordination of distributed application
components. Understanding these lifecycle aspects is essential for
identifying common challenges and research questions related to
deployment and operation in the IoT computing continuum.
6. Challenges in Smart Application Development and Deployment
The IoT computing continuum introduces challenges that fundamentally
affect both the development and deployment of smart applications.
Unlike centralized environments, where development and deployment can
often be treated as loosely coupled phases, the heterogeneity,
distribution, and dynamism of the continuum create strong
interdependencies among application design choices, deployment
decisions, and runtime behavior. As a result, development and
deployment concerns cannot be addressed effectively in isolation.
A primary challenge stems from the bidirectional influence between
application development and deployment constraints. Development
decisions, such as functional decomposition, communication patterns,
and state management, directly affect deployment feasibility across
constrained devices, edge nodes, and cloud platforms.
At the same time, deployment realities, resource availability,
network conditions, latency requirements, and energy constraints
often impose limitations that shape or even redefine application
design. This mutual influence complicates traditional workflows that
assume stable execution environments and late-stage deployment
decisions.
Heterogeneity across the continuum further amplifies this challenge.
Execution environments vary widely in hardware capabilities,
operating systems, runtime support, and management interfaces.
Developers must therefore anticipate deployment diversity early in
development, while deployment mechanisms must accommodate application
abstractions that span multiple platforms.
Without integrated development and deployment considerations,
solutions tend to become fragile, tightly coupled to specific
environments, and difficult to evolve.
Another challenge arises from the dynamic nature of deployment in the
IoT computing continuum. Smart applications often need to adapt to
changing conditions, such as workload variations, mobility,
Kamienski, et al. Expires 26 April 2027 [Page 9]
Internet-Draft IoTinummDeploy October 2026
intermittent connectivity, or evolving physical contexts. Supporting
such adaptation requires continuous feedback between runtime behavior
and development-time assumptions.
Static deployment models and rigid application designs limit
responsiveness to these dynamics, underscoring the need for
approaches that treat deployment as an ongoing process rather than a
one-time event.
These challenges align with principles commonly associated with
DevOps practices, which emphasize continuous integration, continuous
deployment, and feedback loops between development and operations.
However, transferring DevOps concepts to the IoT computing continuum
is non-trivial. Conventional DevOps pipelines typically target
cloud-centric environments and assume homogeneous infrastructure,
reliable connectivity, and centralized control.
In contrast, IoT scenarios involve constrained devices, distributed
execution across multiple continuum stages, and, in many cases,
multiple administrative domains, which complicates the application of
traditional DevOps assumptions.
Finally, the lack of shared abstractions and terminology for
reasoning about development and deployment across the continuum makes
it difficult to compare approaches and identify common requirements.
When the interplay between development and deployment is not made
explicit, solutions often remain ad hoc and platform-specific.
Addressing this gap requires an application-centric perspective that
explicitly acknowledges development--deployment interdependencies and
treats them as first-class concerns. This perspective is essential
for advancing research on smart application deployment and informing
future standardization efforts for the IoT computing continuum.
7. Conceptual Deployment Model
This section outlines a conceptual model for reasoning about the
deployment of smart applications across the IoT computing continuum.
The model supports analysis and discussion rather than prescribing
specific mechanisms, architectures, or workflows. It provides a
shared abstraction that captures how application structure, execution
environments, and coordination mechanisms interact in heterogeneous,
dynamic IoT scenarios.
At the core of the model is the separation between application logic
and execution environments. Application logic is represented
independently of its execution location, allowing reasoning about
functionality, dependencies, and interaction patterns without binding
Kamienski, et al. Expires 26 April 2027 [Page 10]
Internet-Draft IoTinummDeploy October 2026
components to specific devices or platforms. Execution environments
are treated as abstract resources characterized by capabilities,
constraints, and operational context, such as computational power,
connectivity, proximity to data sources, and energy availability.
Execution environments can include programmable network elements as
well as general-purpose computing nodes. Placement therefore selects
both a location and a type of execution environment. A function is
eligible for execution within the network only if the element
supports its computation, state, data access, and interaction
requirements. Constraints on the processing model, memory,
persistent state, and management interfaces can make only part of an
application suitable for such placement. Network forwarding
responsibilities and application processing may also share resources,
so deployment feasibility depends on their interaction.
In this model, a smart application is a set of functional components
connected through data and control dependencies, forming a logical
application graph. Deployment maps these components onto available
execution environments across the IoT computing continuum. This
mapping determines where components execute, but it does not, by
itself, define how they coordinate during execution. As a result,
deployment decisions must be considered together with coordination
strategies that govern interactions among distributed components.
Application components can coordinate in different ways, most notably
through orchestration and choreography. In an orchestration style,
explicit control logic drives coordination by managing execution
order, data flow, and component interactions. This style provides a
global view of application behavior and can simplify reasoning about
end-to-end execution, but it may introduce centralization and
scalability concerns in highly distributed environments. In
contrast, choreography relies on local interactions and shared
interaction rules, letting components coordinate in a decentralized
way without a single point of control. This style can improve
scalability and resilience, but it may complicate global reasoning
and debugging.
The choice between orchestration and choreography, or combinations
thereof, is closely tied to deployment decisions and to the
characteristics of the IoT computing continuum. Resource
constraints, network conditions, mobility, and administrative
boundaries may favor one coordination style over another at different
stages of the continuum. Moreover, coordination strategies may need
to evolve over time as applications adapt to changing conditions,
reinforcing the dynamic nature of deployment.
Kamienski, et al. Expires 26 April 2027 [Page 11]
Internet-Draft IoTinummDeploy October 2026
The conceptual deployment model, therefore, treats placement,
coordination, and lifecycle management as interrelated concerns.
Beyond initial placement, deployment includes reconfiguration,
scaling, migration, and adapting coordination strategies. Runtime
observations, including performance metrics and failure events,
provide feedback that can inform both deployment decisions and future
iterations of application design. By explicitly incorporating
coordination styles into the deployment model, this abstraction
provides a more concrete foundation for discussing development--
deployment interdependencies in the IoT computing continuum, while
remaining agnostic to specific technologies or implementations.
8. Illustrative Scenarios
We present two illustrative scenarios that ground the conceptual
deployment model discussed earlier. The scenarios demonstrate how
application-centric concepts, deployment decisions, and coordination
styles manifest in realistic settings, without prescribing specific
technologies or architectures. The first scenario describes a smart
irrigation application deployed in operational agricultural settings,
providing a concrete reference for placement and lifecycle concerns
under real-world constraints. The second scenario describes a drone-
based delivery application that spans a broader range of continuum
stages and exhibits a richer interplay between coordination styles.
8.1. Smart Irrigation in Precision Agriculture
This scenario is grounded in the SWAMP platform [SWAMP], which
describes an IoT-based precision-irrigation architecture and
deployments for four pilots in Brazil and Europe. Its configurable
distribution of components across cloud and farm-side fog resources
supports the discussion of deployment diversity and reuse across
farms. In particular, the MATOPIBA deployment description includes
local processing and resilience to Internet disconnections. The
placement and lifecycle considerations below build on that
operational motivation; they are not a claim that the paper evaluates
every adaptation mechanism discussed here.
Smart irrigation applications collect environmental data, such as
soil moisture and weather conditions, and use it to determine how
much, when, and where to irrigate. In operational deployments, these
applications typically span constrained field sensors, low-power
gateways that act as radio concentrators, on-premises edge nodes in
farm facilities, and cloud services for analytics, forecasting, and
long-term storage. End users interact with the application through
mobile or web interfaces to inspect data and approve irrigation
plans.
Kamienski, et al. Expires 26 April 2027 [Page 12]
Internet-Draft IoTinummDeploy October 2026
From an application-centric perspective, the irrigation scenario
exemplifies how functional decomposition maps naturally onto multiple
continuum stages. Sensing and local preprocessing functions execute
on constrained devices and field gateways. Intermediate functions,
such as data filtering, sensor calibration, and disconnection
resilience, run on on-premises edge nodes near the irrigation
infrastructure and remain operational even when cloud connectivity is
unavailable. More computationally intensive functions, including
data fusion, soil moisture forecasting, and irrigation optimization,
run on cloud platforms that offer greater resources and broader data
visibility.
A defining property of this scenario is the need to keep operating
with intermittent wide-area connectivity, common in rural
deployments. Functions on on-premises edge nodes must sustain
essential behavior when cloud services are temporarily unreachable,
such as enforcing safety thresholds or running simplified local
models, and reconcile state once connectivity is restored. This
requirement directly shapes how developers decompose application
functions and where they deploy them, illustrating the bidirectional
influence between development and deployment concerns discussed
earlier.
The irrigation scenario also highlights that deployment decisions
extend beyond initial placement. Over time, functions may be
updated, reconfigured, or extended to incorporate new models or new
sensor modalities, and the same application logic may need to be
deployed across multiple farms with different infrastructure
configurations. These lifecycle aspects underscore the relevance of
an application-centric view that treats deployment as an ongoing
process rather than a one-time event.
8.2. Drone-Based Delivery in Urban Environments
The delivery-service setting and the need for autonomous local
collision avoidance are motivated by [DRONE-DELIVERY]. That study
evaluates non-cooperative geometric collision-avoidance strategies
through simulation and analytical modeling, and explains why local
strategies remain relevant when communication is unavailable or
emergency detours are needed. The distribution of functions across
edge nodes, cloudlets, and cloud platforms described below is an
illustrative deployment extension; it is not an experimentally
validated architecture from that study. In particular, autonomous
non-cooperative avoidance is not choreography, which concerns
interactions among components.
Kamienski, et al. Expires 26 April 2027 [Page 13]
Internet-Draft IoTinummDeploy October 2026
A drone-based delivery application uses unmanned aerial vehicles to
deliver packages in urban areas. The application comprises multiple
functional components, including mission planning, navigation,
sensing, local coordination, and backend services for order
management and analytics. From an application-centric perspective,
these components form a logical application graph, with dependencies
reflecting data flows and control interactions among functions. The
application operates across the full span of the IoT computing
continuum, leveraging constrained onboard devices, nearby edge nodes,
operator-provided cloudlets, and cloud platforms.
Low-level sensing, actuation, and real-time navigation run directly
on the drone because of strict latency and control requirements.
Local coordination and situational awareness functions may execute on
nearby edge nodes or gateways that aggregate information from
multiple drones operating in the same area. Operator-provided
cloudlets, for example, those associated with 5G or future 6G
infrastructure, can host functions that support cooperative behavior
among drones, such as collision avoidance assistance and shared
situational awareness. Backend services, including mission planning,
optimization, logging, and analytics, typically run on cloud
platforms that provide greater computational resources and global
system visibility.
This scenario particularly illustrates the coexistence of different
coordination styles within a single application. Mission planning
and high-level task assignment naturally follow an orchestration
style, in which a centralized component coordinates delivery
schedules and routes based on global system state. In contrast,
local interactions among drones, such as collision avoidance or
cooperative sensing, follow a choreography style, relying on
decentralized interactions and shared interaction rules without a
single controlling entity. Both coordination styles coexist within
the same application and are influenced by deployment choices across
the continuum, demonstrating that the distinction between
orchestration and choreography is not merely theoretical but reflects
concrete architectural trade-offs.
Deployment decisions in this scenario are also inherently dynamic.
As drones move through different environments or face changing
network conditions, mappings of coordination functions to edge nodes
or cloudlets may need revision, while backend services remain
centralized. The application lifecycle extends beyond initial
deployment, with components updated, reconfigured, or migrated in
response to changes in delivery demand, individual drone failures, or
variations in network availability.
Kamienski, et al. Expires 26 April 2027 [Page 14]
Internet-Draft IoTinummDeploy October 2026
8.3. Discussion
Together, these two scenarios illustrate the spectrum of smart
applications that operate over the IoT computing continuum. The
first grounds the discussion in operational deployments with
documented constraints, particularly around intermittent connectivity
and the need for resilient edge behavior. The second reveals the
broader architectural space where placement, coordination, and
lifecycle concerns fully manifest, including the explicit coexistence
of orchestration and choreography within a single application. Both
share the fundamental property that application behavior emerges from
the coordinated execution of distributed functions across
heterogeneous stages, reinforcing the need for application-centric
perspectives on deployment and lifecycle management.
9. The Role of AI Agents in Application Deployment
The previously discussed conceptual deployment model considers
placement, coordination, and lifecycle management as interconnected
and inherently dynamic concerns. As the scale, heterogeneity, and
dynamism of the Internet of Things (IoT) computing continuum
increase, addressing these concerns through static policies or manual
procedures becomes increasingly challenging, especially when
application workloads demonstrate heterogeneous and context-sensitive
behavior. AI agents, defined as autonomous software entities capable
of perceiving their environment, reasoning about objectives, and
acting upon deployment infrastructure, present a promising solution
for managing this complexity. Foundational research on multi-agent
systems [WOOLDRIDGE-AGENTS] offers established abstractions for
understanding agent behavior. This section analyzes the role of such
agents from an application-centric perspective, without specifying
particular agent architectures, frameworks, or protocols.
AI agents are connected to application deployment in two
complementary ways. First, agents can facilitate the deployment
process by assisting with or automating decisions regarding the
placement, coordination, adaptation, and lifecycle management of
application functions. Second, agents themselves are software
components that require execution within the continuum. Therefore,
their deployment must also be considered, subject to the same
placement criteria as application functions. The following
discussion examines these two roles sequentially.
Kamienski, et al. Expires 26 April 2027 [Page 15]
Internet-Draft IoTinummDeploy October 2026
9.1. Agents as Enablers of the Deployment Process
In their first role, AI agents support deploying the services that
comprise a smart application across the IoT computing continuum.
Given a logical application graph and a set of available execution
environments, agents can evaluate candidate mappings of functions to
continuum stages, considering application-level requirements such as
latency, resilience, energy consumption, and data locality, as well
as runtime observations of infrastructure conditions. Beyond initial
placement, agents can drive lifecycle operations, including
reconfiguration, scaling, migration, and partial redeployment, in
response to workload variations, mobility, connectivity disruptions,
or evolving physical contexts.
A concrete example arises in deploying inference workloads based on
large language models, where placement decisions must balance
latency, cost, and resilience to connectivity disruptions.
Preliminary work by the authors suggests that agent-driven adaptive
placement strategies can outperform static configurations,
particularly under variable demand or intermittent wide-area
connectivity.
Agent-assisted deployment does not presuppose a particular
coordination style. A single agent with global visibility may
coordinate deployment decisions in an orchestration style, while
multiple agents interacting through shared rules may realize
deployment coordination in a choreography style. The Model Context
Protocol [MCP] supports interactions between applications and tools
or contextual resources, while the Agent2Agent protocol [A2A]
supports interactions among agents. Neither protocol, by itself,
determines whether an application follows orchestration,
choreography, or a hybrid arrangement; that choice depends on the
distribution of coordination logic and decision authority.
The IETF Agent Communication Protocols (agentproto) Working Group
[AGENTPROTO] addresses a complementary concern: the correlation,
lifecycle, and continuity of agentic dialogs across participants,
intermediaries, and trust boundaries. Such capabilities are relevant
when deployment agents exchange observations and actions across the
continuum, including when an interaction resumes after interruption,
or a participant changes network attachment. Dialog management does
not itself preserve application state or guarantee the completion of
a deployment action. The group's charter does not standardize agent
decision-making or planning semantics, and therefore does not
determine placement policies or the application's coordination style.
Kamienski, et al. Expires 26 April 2027 [Page 16]
Internet-Draft IoTinummDeploy October 2026
Agents distributed across the continuum may exchange information on
local resource availability, observed conditions, and pending
deployment actions. These interactions can combine local knowledge
available near constrained devices with global objectives maintained
on cloud platforms. Their use requires distinguishing communication
and dialog continuity from the application-level rules that govern
deployment decisions and recovery.
9.2. Deployment of the Agents Themselves
In their secondary role, agents function as deployable entities. As
software components, they require execution environments that provide
sufficient computational power, memory, and connectivity. Agents can
operate anywhere in the IoT computing continuum, including gateways,
edge nodes, cloudlets, and cloud platforms. The selected deployment
stage influences the timeliness of agent decisions, the degree of
local context awareness, and resilience to connectivity disruptions.
Constrained devices require special consideration, as many lack
sufficient resources to support a full agent runtime. Nevertheless,
deployment strategies must often account for device-level conditions.
A proxy-based approach addresses this challenge: a lightweight proxy
on the constrained device represents it to a nearby agent, such as a
gateway or edge node, which then reasons on the device's behalf.
This method enables agent-based deployment at even the most resource-
limited stages of the continuum, while adhering to the constraints
outlined in [I-D.ietf-iotops-7228bis].
Agent deployment is recursive: the mechanisms agents use to deploy
application functions also apply to the agents themselves. The
placement, migration, and lifecycle management of agents present
challenges analogous to those for application components, but they
also raise additional concerns about trust, accountability, and
control, especially when agents operate autonomously across multiple
administrative domains. The Research Directions section identifies
open questions associated with this dual role.
10. Relationship to Ongoing Research and Standardization
The issues discussed in this document build on existing research and
standardization efforts on edge computing and the computing
continuum, including work within the IETF and IRTF (e.g., [RFC9556])
and broader academic perspectives (e.g., [CONTINUUM-SURVEY]). Within
the IRTF, the T2TRG has explored programmability, coordination, and
interoperability among connected devices.
Kamienski, et al. Expires 26 April 2027 [Page 17]
Internet-Draft IoTinummDeploy October 2026
Several concrete research efforts have examined application-centric
aspects of the IoT computing continuum and informed the perspective
adopted in this document. Work on the notion of an IoT computing
continuum as a unifying framework for reasoning about development and
deployment choices has clarified the role of distributed application
stages [IOTINUUM]. Complementary work on deployment-aware
approaches, such as IoTDeploy, has explored how application
components can be systematically placed and migrated across continuum
stages while preserving application-level properties [IOTDEPLOY].
More recent efforts have investigated integrated frameworks for
developing and deploying continuum-aware smart applications,
providing concrete examples of how application-centric abstractions
can be realized in practice. These efforts are cited here as
representative of ongoing work in the area, not as prescriptive
references; this document remains agnostic to specific frameworks or
implementations.
Community-driven efforts, including workshops focused on future
Internet research, have also discussed application deployment over
the IoT computing continuum in the context of IETF and IRTF
engagement, as exemplified by [WPIETF2025]. This document
complements these efforts by adopting an application-centric
perspective on deployment and lifecycle management.
10.1. Device Update, Discovery, and Management
The SUIT firmware update architecture [RFC9019] addresses secure
firmware updates for IoT devices. It provides lifecycle foundations
for device software, while application deployment raises additional
questions about compatibility and coordinated transitions across
device firmware, edge services, and cloud functions.
CoRE work provides complementary mechanisms. The Resource Directory
[RFC9176] supports resource registration and lookup, including for
endpoints that cannot remain continuously available. The CoAP
Management Interface [CORE-COMI], an expired work-in-progress draft,
is relevant to accessing management data in constrained environments.
Resource discovery and management can provide inputs and operations
for deployment, but they do not, by themselves, describe an
application's entire dependency graph or determine a safe multi-
component transition. Investigating how to compose existing
mechanisms is preferable to assuming a new management interface is
needed.
Kamienski, et al. Expires 26 April 2027 [Page 18]
Internet-Draft IoTinummDeploy October 2026
10.2. Computing in the Network and Intent
The IoT computing continuum can naturally integrate Computing in the
Network (COIN), with eligible application functions executing in
processing-capable network elements. Work in COINRG [COINRG]
explored using network resources for computation and the relationship
between computing and networking. From this application-centric
perspective, a network element with suitable processing capabilities
can serve as an execution environment for an application function.
This extends placement beyond choosing among device, edge, and cloud
hosts to considering processing within the network itself.
For example, an application may place filtering, aggregation, or
preprocessing in a programmable network element while retaining other
functions on devices, edge hosts, or cloud platforms. Such a
placement is conditional on execution capabilities, application
semantics, resource limits, and administrative permissions. The
connection to COIN is therefore part of the deployment model: the
application graph can be mapped onto heterogeneous environments that
include both computing hosts and processing-capable network elements.
No particular in-network programming model or protocol is prescribed.
This connection is distinct from the relationship to CoRE described
above. CoRE discovery and management mechanisms are relevant to
finding and managing constrained resources and their interfaces. On
the other hand, COIN concerns using network elements as execution
environments. The two perspectives can complement each other, but
the model does not assume that an in-network execution environment
exposes a CoRE interface.
NMRG's work on intent-based networking, including the concepts and
definitions in [RFC9315], is relevant to expressing desired outcomes
separately from operational actions. A research question here is how
application objectives, such as retaining local behavior during
disconnection, can be translated into deployment constraints and
checked against observed behavior. This document does not specify
such a mapping.
10.3. Agent Communication and Dialog Management
The agentproto Working Group [AGENTPROTO] is chartered to define a
baseline agentic dialog management protocol and a reference
architecture integrating related protocol building blocks. Its scope
includes dialog identifiers, lifecycle semantics, and propagation of
dialog context over existing IETF protocols. Here, dialog context
refers to identifiers and lifecycle state used for correlation and
continuity, rather than model prompts, retrieved documents, or
conversation memory.
Kamienski, et al. Expires 26 April 2027 [Page 19]
Internet-Draft IoTinummDeploy October 2026
This work is relevant to agents that coordinate deployment across
heterogeneous execution environments and administrative boundaries.
Correlating interactions and maintaining dialogs through
interruptions can support exchanges among agents, operators, and
tools in either orchestrated or choreographed applications. The
relationship is complementary: this document considers which
functions and agents execute where, how their responsibilities are
coordinated, and how application behavior is preserved. Agentproto
addresses interoperability of the dialogs used in those interactions.
Its charter explicitly leaves agent decision-making and planning
semantics outside its scope and does not replace application-layer
protocols such as MCP or A2A. A migration of an application function
or agent therefore still requires separate handling of execution
state, authority, and application recovery.
10.4. Descriptions of Things and Application Abstractions
The Semantic Definition Format (SDF) [RFC9880] describes data and
interaction models of Things. W3C WoT Thing Descriptions [WOT-TD]
describe Things and their interaction affordances, including
information used to access those interactions. Both are candidates
for reuse when describing the device-facing capabilities on which
application functions depend.
Neither is treated here as a complete deployment language. Open
questions include how such descriptions can be related to function
dependencies, runtime requirements, permissible placements, state
migration, and degraded operation. The appropriate reuse,
composition, or extension of existing descriptions requires
investigation before proposing new application-centric abstractions.
11. Research Directions
The challenges and conceptual considerations discussed in this
document point to several open research directions for smart
application development and deployment across the IoT computing
continuum. These directions are not exhaustive. Instead, they
highlight areas that require further investigation to better
understand how application structure, deployment decisions,
coordination strategies, and lifecycle management interact in
heterogeneous and dynamic environments.
One research direction concerns defining application-centric
abstractions for deployment. This investigation can start with
existing descriptions of Things, including SDF [RFC9880] and WoT
Thing Descriptions [WOT-TD], and assess which deployment information
can be reused and which is still missing. While existing work has
extensively explored infrastructure-level aspects of edge and
Kamienski, et al. Expires 26 April 2027 [Page 20]
Internet-Draft IoTinummDeploy October 2026
continuum computing, a clear need remains for abstractions that let
applications express functional decomposition, dependencies, and non-
functional requirements independently of specific execution
environments. Such abstractions would enable more systematic
reasoning about placing, migrating, and adapting application
components across stages of the IoT computing continuum,
complementing existing architectural perspectives on edge computing
[RFC9556] and broader analyses of the computing continuum
[CONTINUUM-SURVEY].
A second research direction involves integrated approaches to
application development and deployment. In the IoT computing
continuum, development-time decisions about application structure,
communication patterns, and state management are tightly coupled with
deployment constraints, such as resource availability, connectivity,
and latency. Traditional workflows that treat development and
deployment as largely independent phases are therefore insufficient.
Further research is needed to explore models, methodologies, and
tools that explicitly account for this interdependence and that
support feedback loops between design-time assumptions and runtime
observations, building on early deployment-aware approaches such as
those discussed in [IOTDEPLOY].
Coordination strategies for distributed applications constitute
another important research direction. Orchestration and choreography
are complementary styles for coordinating distributed application
components, each with distinct trade-offs in scalability, resilience,
observability, and manageability. Understanding how these
coordination styles can be combined, adapted, or dynamically
transitioned as applications evolve and deployment conditions change
remains an open problem. This includes investigating how
coordination strategies interact with placement decisions, fault
handling, and lifecycle operations across heterogeneous execution
environments in the IoT computing continuum.
Automation and intelligence in deployment and lifecycle management
are another research area. Given the scale, heterogeneity, and
dynamism of IoT environments, manual deployment, configuration, and
adaptation quickly become impractical. Research into automated,
declarative, or policy-driven approaches for placement, migration,
and reconfiguration may help address these challenges, provided that
such approaches remain transparent, controllable, and aligned with
application-level objectives. These mechanisms must also account for
IoT-specific constraints, including limited resources, intermittent
connectivity, and decentralized control across administrative
domains.
Kamienski, et al. Expires 26 April 2027 [Page 21]
Internet-Draft IoTinummDeploy October 2026
An additional research direction builds on the dual role of AI agents
in deployment discussed earlier in this document. That discussion
raises open questions that remain largely unresolved: a) how agent
responsibilities should be distributed between application-level and
infrastructure-level concerns; b) how inter-agent interactions can be
made secure, auditable, and aligned with Internet architectural
principles, particularly when agents interact across administrative
domains and heterogeneous environments; c) how orchestration and
choreography styles may be combined dynamically in agent-based
deployment; d) how the placement and lifecycle of the agents
themselves, including proxy-based representation of constrained
devices, can be managed without introducing new points of fragility
or centralization. Emerging interaction frameworks such as [MCP] and
[A2A] remain evolving, and further research is needed to assess how
agent-based mechanisms can complement application-centric deployment
models in the IoT computing continuum.
Finally, a broader need remains for shared terminology and conceptual
frameworks that facilitate comparison across research efforts and
support dialogue with standardization activities. Without a common
vocabulary for reasoning about application-centric deployment and
lifecycle management in the IoT computing continuum, research results
risk remaining fragmented and difficult to generalize.
Informational documents that clarify the problem space, such as this
one, can help align research agendas and identify areas where future
standardization efforts within the IRTF or the IETF may be
beneficial.
12. Security Considerations
This document does not specify protocols, mechanisms, or
architectures and therefore does not directly introduce new security
vulnerabilities. However, the concepts discussed have important
security implications worth considering.
In the IoT computing continuum, application components are
distributed across heterogeneous and potentially untrusted execution
environments, increasing the attack surface and complicating
traditional security assumptions. Deployment decisions influence
trust boundaries, data exposure, and the ability to isolate faults or
compromised components.
Coordination strategies also have security implications.
Orchestration-based approaches may introduce centralized control
points that attackers can target, while choreography-based approaches
rely on decentralized interactions that require robust
authentication, authorization, and trust management among components.
Kamienski, et al. Expires 26 April 2027 [Page 22]
Internet-Draft IoTinummDeploy October 2026
The tight coupling between development and deployment further
emphasizes the need to consider security throughout the application
lifecycle. Deployment changes, component migration, or runtime
adaptation can invalidate design-time assumptions about trust,
isolation, and access control. As a result, security considerations
must be revisited whenever application structure, placement, or
coordination strategies evolve.
Finally, the distributed, multi-domain nature of the IoT computing
continuum raises challenges in identity management, secure
communication, and policy enforcement across administrative
boundaries. While this document does not address these challenges,
they underscore the importance of integrating security considerations
into research and standardization efforts for application-centric
deployment and lifecycle management.
13. IANA Considerations
This document has no IANA actions.
14. Acknowledgments
The authors acknowledge CGI.br (Brazilian Internet Steering
Committee) for its support through the IETF/IRTF participation
program, which enabled engagement in research and discussions within
the Internet Research Task Force (IRTF).
15. Informative References
[A2A] A2A Project, "Agent2Agent (A2A) Protocol", 2024,
.
[AGENTPROTO]
IETF, "Agent Communication Protocols Working Group
Charter", Charter charter-ietf-agentproto-01, 8 October
2026, .
[COINRG] IRTF, "Computing in the Network Research Group Charter",
n.d.,
.
Kamienski, et al. Expires 26 April 2027 [Page 23]
Internet-Draft IoTinummDeploy October 2026
[CONTINUUM-SURVEY]
Bittencourt, L. F., Rodrigues-Filho, R., Spillner, J., De
Turck, F., Santos, J., da Fonseca, N. L. S., Rana, O.,
Parashar, M., and I. Foster, "The Computing Continuum:
Past, Present, and Future", Computer Science Review Vol.
58, Article 100782, DOI 10.1016/j.cosrev.2025.100782,
2025, .
[CORE-COMI]
IETF CoRE Working Group, "CoAP Management Interface
(CORECONF)", Work in Progress, Internet-Draft, draft-ietf-
core-comi-21, 2 March 2026,
.
[DRONE-DELIVERY]
de Oliveira, F. M. C., Bittencourt, L. F., Bianchi, R. A.
C., and C. A. Kamienski, "Drones in the Big City:
Autonomous Collision Avoidance for Aerial Delivery
Services", IEEE Transactions on Intelligent Transportation
Systems Vol. 25, No. 5, pp. 4657-4674,
DOI 10.1109/TITS.2023.3329029, May 2024,
.
[I-D.ietf-iotops-7228bis]
Bormann, C., Ersue, M., Keränen, A., and C. Gomez,
"Terminology for Constrained-Node Networks", Work in
Progress, Internet-Draft, draft-ietf-iotops-7228bis-10, 6
July 2026, .
[IOTDEPLOY]
Oliveira, F. B., Di Felice, M., and C. Kamienski,
"IoTDeploy: Deployment of IoT Smart Applications over the
Computing Continuum", Internet of Things Vol. 28, Article
101348, DOI 10.1016/j.iot.2024.101348, 2024,
.
[IOTINUUM] Kamienski, C., Zyrianoff, I., Bittencourt, L. F., and M.
Di Felice, "IoTinuum: The IoT Computing Continuum",
IEEE Proceedings of the 20th International Conference on
Distributed Computing in Smart Systems and the Internet of
Things (DCOSS-IoT), pp. 732-739, DOI 10.1109/DCOSS-
IoT61029.2024.00114, 2024,
.
[MCP] Anthropic, "Model Context Protocol Specification", 2024,
.
Kamienski, et al. Expires 26 April 2027 [Page 24]
Internet-Draft IoTinummDeploy October 2026
[RFC7452] Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
"Architectural Considerations in Smart Object Networking",
RFC 7452, DOI 10.17487/RFC7452, March 2015,
.
[RFC9019] Moran, B., Tschofenig, H., Brown, D., and M. Meriac, "A
Firmware Update Architecture for Internet of Things",
RFC 9019, DOI 10.17487/RFC9019, April 2021,
.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, .
[RFC9315] Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
Tantsura, "Intent-Based Networking - Concepts and
Definitions", RFC 9315, DOI 10.17487/RFC9315, October
2022, .
[RFC9556] Hong, J., Hong, Y., de Foy, X., Kovatsch, M., Schooler,
E., and D. Kutscher, "Internet of Things (IoT) Edge
Challenges and Functions", RFC 9556, DOI 10.17487/RFC9556,
April 2024, .
[RFC9880] Koster, M., Ed., Bormann, C., Ed., and A. Keränen,
"Semantic Definition Format (SDF) for Data and
Interactions of Things", RFC 9880, DOI 10.17487/RFC9880,
January 2026, .
[SWAMP] Kamienski, C., Soininen, J., Taumberger, M., Dantas, R.,
Toscano, A., Salmon Cinotti, T., Filev Maia, R., and A.
Torre Neto, "Smart Water Management Platform: IoT-Based
Precision Irrigation for Agriculture", Sensors Vol. 19,
No. 2, Article 276, DOI 10.3390/s19020276, 11 January
2019, .
[WOOLDRIDGE-AGENTS]
Wooldridge, M., "An Introduction to MultiAgent Systems",
John Wiley and Sons 2nd Edition, 2009.
[WOT-TD] W3C, "Web of Things (WoT) Thing Description 1.1", 5
December 2023, .
Kamienski, et al. Expires 26 April 2027 [Page 25]
Internet-Draft IoTinummDeploy October 2026
[WPIETF2025]
Kamienski, C. A. and M. A. B. Santos, "Smart Application
Deployment over the IoT Computing Continuum",
WPIETF Workshop Pre-IETF/IRTF, Brazilian Computer Society
(SBC), available via SBC Open Library (SOL), 2025.
Authors' Addresses
Carlos Alberto Kamienski
Federal University of ABC (UFABC)
Email: carlos.kamienski@ufabc.edu.br
Marco Santos
Federal Institute of Sertão (IFSertão)
Email: marcelo.santos@ifsertao-pe.edu.br
Marco Di Felice
University of Bologna
Email: marco.difelice3@unibo.it
Kamienski, et al. Expires 26 April 2027 [Page 26]