Use Cases for In-Network Computing

3.1.1. Description

The scenario can be exemplified in an immersive gaming application, where a single user plays a game using a VR headset.
The headset hosts functions that "display" frames to the user, as well as the functions for VR content processing and frame rendering that also incorporate input data received from sensors in the VR headset.¶

Once this application is partitioned into constituent (COIN) programs and deployed throughout a COIN system, utilizing the COIN execution environment, only the "display" (COIN) program may be left in the headset, while the compute intensive real-time VR content processing (COIN) program can be offloaded to a nearby resource rich home PC or a PND in the operator's access network, for a better execution (faster and possibly higher resolution generation).¶

3.1.2. Characterization

Partitioning a mobile application into several constituent (COIN) programs allows for denoting the application as a collection of (COIN) functions for a flexible composition and a distributed execution. In our example above, most functions of a mobile application can be categorized into any of three, "receiving", "processing", and "displaying" function groups.¶

Any device may realize one or more of the (COIN) programs of a mobile application and expose them to the (COIN) system and its constituent (COIN) execution environments. When the (COIN) program sequence is executed on a single device, the outcome is what you see today as applications running on mobile devices.¶

However, the execution of a (COIN) program may be moved to other (e.g., more suitable) devices, including PNDs, which have exposed the corresponding (COIN) program as individual (COIN) program instances to the (COIN) system by means of a 'service identifier'. The result is the equivalent to 'mobile function offloading', for possible reduction of power consumption (e.g., offloading CPU intensive process functions to a remote server) or for improved end user experience (e.g., moving display functions to a nearby smart TV) by selecting more suitably placed (COIN) program instances in the overall (COIN) system.¶

Figure 1 shows one realization of the above scenario, where a 'DPR app' is running on a mobile device (containing the partitioned Display(D), Process(P) and Receive(R) COIN programs) over an SDN network. The packaged applications are made available through a localized 'playstore server'. The mobile application installation is realized as a 'service deployment' process, combining the local app installation with a distributed deployment (and orchestration) of one or more (COIN) programs on most suitable end systems or PNDs ('processing server').¶

                             +----------+ Processing Server
           Mobile            | +------+ |
        +---------+          | |  P   | |
        |   App   |          | +------+ |
        | +-----+ |          | +------+ |
        | |D|P|R| |          | |  SR  | |
        | +-----+ |          | +------+ |         Internet
        | +-----+ |          +----------+            /
        | |  SR | |              |                  /
        | +-----+ |            +----------+     +------+
        +---------+           /|SDN Switch|_____|Border|
                  +-------+ /  +----------+     |  SR  |
                  | 5GAN  |/        |           +------+
                  +-------+         |
      +---------+                   |
      |+-------+|               +----------+
      ||Display||              /|SDN Switch|
      |+-------+|   +-------+ / +----------+
      |+-------+|  /|WIFI AP|/
      ||   D   || / +-------+     +--+
      |+-------+|/                |SR|
      |+-------+|                /+--+
      ||  SR   ||            +---------+
      |+-------+|            |Playstore|
      +---------+            | Server  |
          TV                 +---------+

Such localized deployment could, for instance, be provided by a visiting site, such as a hotel or a theme park. Once the 'processing' (COIN) program is terminated on the mobile device, the 'service routing' (SR) elements in the network route (service) requests instead to the (previously deployed) 'processing' (COIN) program running on the processing server over an existing SDN network. Here, capabilities and other constraints for selecting the appropriate (COIN) program, in case of having deployed more than one, may be provided both in the advertisement of the (COIN) program and the service request itself.¶

As an extension to the above scenarios, we can also envision that content from one processing (COIN) program may be distributed to more than one display (COIN) program, e.g., for multi/many-viewing scenarios, thereby realizing a service-level multicast capability towards more than one (COIN) program.¶

3.1.3. Existing Solutions

The ETSI Mobile Edge Computing (MEC) [ETSI] suite of technologies provides solutions for mobile function offloading by allowing mobile applications to select resources in edge devices to execute functions instead of the mobile device directly. For this, ETSI MEC utilizes a set of interfaces for the selection of suitable edge resources, connecting to so-called MEC application servers, while also allowing for sending data for function execution to the application server.¶

However, the technologies do not utilize micro-services as described in our use case and also do not allow for the dynamic selection and redirection of micro-service calls to varying edge resources rather than a single MEC application server.¶

Also, the selection of the edge resource (the app server) is relatively static, relying on DNS-based endpoint selection, which does not cater to the requirements of the example provided above, where the latency for redirecting to another device lies within few milliseconds for aligning with the framerate of the display micro-service.¶

Lastly, MEC application servers are usually considered resources provided by the network operator through its MEC infrastructure, while our use case here also foresees the placement and execution of micro-services in end user devices.¶

There also exists a plethora of mobile offloading platforms provided through proprietary platforms, all of which follow a similar approach as ETSI MEC in that a selected edge application server is being utilized to send functional descriptions and data for execution.¶

The draft at [APPCENTRES] outlines a number of enabling technologies for the use case, some of which have been realized in an Android-based realization of the micro-services as a single application, which is capable to dynamically redirect traffic to other micro-service instances in the network. This capability, together with the underlying path-based forwarding capability (using SDN) was demonstrated publicly, e.g., at the Mobile World Congress 2018 and 2019.¶

3.1.4. Opportunities

• The packaging of (COIN) programs into existing mobile application packaging may enable the migration from current (mobile) device-centric execution of those mobile applications toward a possible distributed execution of the constituent (COIN) programs that are part of the overall mobile application.¶
• The orchestration for deploying (COIN) program instances in specific end systems and PNDs alike may open up the possibility for localized infrastructure owners, such as hotels or venue owners, to offer their compute capabilities to their visitors for improved or even site-specific experiences.¶
• The execution of (current mobile) app-level (COIN) programs may speed up the execution of said (COIN) program by relocating the execution to more suitable devices, including PNDs.¶
• The support for service-level routing of requests (service routing in [APPCENTRES] may support higher flexibility when switching from one (COIN) program instance to another, e.g., due to changing constraints for selecting the new (COIN) program instance.¶
• The ability to identify service-level COIN elements will allow for routing service requests to those COIN elements, including PNDs, therefore possibly allowing for new COIN functionality to be included in the mobile application.¶
• The support for constraint-based selection of a specific (COIN) program instance over others (constraint-based routing in [APPCENTRES]) may allow for a more flexible and app-specific selection of (COIN) program instances, thereby allowing for better meeting the app-specific and end user requirements.¶

3.1.5. Research Questions

• RQ 3.1.1: How to combine service-level orchestration frameworks with app-level packaging methods?¶
• RQ 3.1.2: How to reduce latencies involved in (COIN) program interactions where (COIN) program instance locations may change quickly?¶
• RQ 3.1.3: How to signal constraints used for routing requests towards (COIN) program instances in a scalable manner?¶
• RQ 3.1.4: How to identify (COIN) programs and program instances?¶
• RQ 3.1.5: How to identify a specific choice of (COIN) program instances over others?¶
• RQ 3.1.6: How to provide affinity of service requests towards (COIN) program instances, i.e., longer-term transactions with ephemeral state established at a specific (COIN) program instance?¶
• RQ 3.1.7: How to provide constraint-based routing decisions at packet forwarding speed?¶
• RQ 3.1.8: What COIN capabilities may support the execution of (COIN) programs and their instances?¶

3.1.6. Requirements

• Req 3.1.1: Any COIN system MUST provide means for routing of service requests between resources in the distributed environment.¶
• Req 3.1.2: Any COIN system MUST provide means for identifying services exposed by (COIN) programs for directing service requests.¶
• Req 3.1.3: Any COIN system MUST provide means for identifying (COIN) program instances for directing (affinity) requests to a specific (COIN) program instance.¶
• Req 3.1.4: Any COIN system MUST provide means for dynamically choosing the best possible service sequence of one or more (COIN) programs for a given application experience, i.e., support for chaining (COIN) program executions.¶
• Req 3.1.5: Means for discovering suitable (COIN) programs SHOULD be provided.¶
• Req 3.1.6: Any COIN system MUST provide means for pinning the execution of a service of a specific (COIN) program to a specific resource, i.e., (COIN) program instance in the distributed environment.¶
• Req 3.1.7: Any COIN system SHOULD provide means for packaging micro-services for deployments in distributed networked computing environments.¶
• Req 3.1.8: The packaging MAY include any constraints regarding the deployment of (COIN) program instances in specific network locations or compute resources, including PNDs.¶
• Req 3.1.9: Such packaging SHOULD conform to existing application deployment models, such as mobile application packaging, TOSCA orchestration templates or tar balls or combinations thereof.¶
• Req 3.1.10: Any COIN system MUST provide means for real-time synchronization and consistency of distributed application states.¶

3.2.1. Description

Virtual Reality (VR), Augmented Reality (AR), and immersive media, now globally referred to as Extended Reality (XR) and the bases for the metaverse, are the drivers of a number of advances in interactive technologies. While initially associated with gaming and entertainment, metaverse applications now include remote diagnosis, maintenance, telemedicine, manufacturing and assembly, intelligent agriculture, smart cities, and immersive classrooms. XR is one example of the multisource-multidestination problem that combines video and haptics in interactive multi-party interactions under strict delay requirements.¶

Indeed, XR applications require real-time interactivity for immersive and increasingly mobile immersive applications with tactile and time-sensitive data. Because high bandwidth is needed for high resolution images and local rendering for 3D images and holograms, they are difficult to run over traditional networks which limits some of its potential benefits in the collaborative space. As a consequence, innovation is needed to unlock the full potential of the applications.¶

3.2.2. Characterization

XR experiences, especially those involving collaboration, are difficult to deliver with a client-server cloud-based solution as they require a combination of: stream synchronization, low delays and delay variations, means to recover from losses and optimized caching and rendering as close as possible to the user at the network edge. Furthermore, when XR deals with personal information and protected content, XR application must also provide a secure environment and ensure user privacy. Additionally, the sheer amount of data needed for and generated by the XR applications, such as video holography, put them squarely in the realm of data-driven applications that can use recent trend analysis and mechanisms, as well as machine learning to find the optimal caching and processing solution and hopefully reduce the size of the data that needs transiting through the network. Other mechanims such as data filtering and reduction, functional distribution and partitioning are also needed to accommodate the low delay needs for the same applications.¶

Those characterisitics of XR makes it ideal to profit from some COIN capabilities to enable XR over networks. COIN can enable the distribution of the service components across different nodes on the path from content source to rendering destination. For example, data filtering, image rendering, and video processing leveraging different HW capabilities with combinations of CPU and GPU at the network edge and in the fog, where the content is consumed, represent possible remedies for the high bandwidth demands of XR. Machine learning across the network nodes can better manage the data flows by distributing them over more adequate paths. In order to provide adequate quality of experience, multi-variate and heterogeneous resource allocation and goal optimization problems need to be solved, likely requiring advanced analysis and articificial intelligence. For the purpose of this document, it is important to note that the use of COIN for XR does not imply a specific protocol but targets an architecture enabling the deployment of the services. In this context, similar considerations as for Section 3.1 apply.¶

3.2.3. Existing Solutions

XR profits from extensive research in the past years in gaming, machine learning, network telemetry, high resolution imaging, smart cities, and IoT. Information Centric Networking (and related) approaches that combine publish subscribe and distributed storage are also very suited for the multisource-multidestination applications of XR. Hence XR solutions exist and are more and more deployed outside entertainment, and with the focus on the Metaverse the number of publications related to XR has skyrocketed.¶

However, in terms of networking which is the focus of this document current deployments remain mostly one-way: information is sent to the destination, rendered and displayed based on local processing. A lot of the video information goes upstream. There are still very little truly interactive immersive media applications over networks except within a single subnetwork that is characteristic of some smart cities, manufacturing applications or training.¶

3.2.4. Opportunities

While delay is inherently related to information transmission and if we continue the analogy of the computer board to highlight some of the COIN capabilities in terms of computation and storage but also allocation of resources, there are some opportunities that XR could take advantage of:¶

• Reduced latency: 20 ms is usually cited as an upper limit for XR applications. Storage and preprocessing of scenes in local elements (includng in the mobile network) could extend the reach of XR applications at least over the extended edge.¶
• Video transmission: The use of better transcoding, advanced context-based compression algorithms, pre-fetching and pre-caching, as well as movement prediction all help to reduce bandwidth consumption. While this is now limited to local processing it is not outside the realm of COIN to push some of these functionalities to the network especially as realted to caching/fetching but also context based flow direction and aggregation.¶
• Monitoring: Since bandwidth and data are fundamental for XR deployment, COIN functionality could help to better monitor and distribute the XR services over collaborating network elements to optimize end-to-end performance.¶
• Functional decomposition: Advanced functional decomposition, localization, and discovery of computing and storage resources in the network can help to optimize user experience in general.¶
• Intelligent network management and configuration: The move to artificial intelligence in network management to learn about flows and adapt resources based on both dataplane and control plane programmability can help the overall deployment of XR services.¶

3.2.5. Research Questions

• RQ 3.2.1: Can current PNDs provide the speed required for executing complex filtering operations, including metadata analysis for complex and dynamic scene rendering?¶
• RQ 3.2.2: Where should PNDs equipped with these operations be located for optimal performance gains?¶
• RQ 3.2.3: How can the interoperability of CPU/GPU be optimized and used jointly with PNDs to combine low-level packet filtering and redirection with the higher layer processing needed for image processing, feature selection, and haptics?¶
• RQ 3.2.4: Can the use of joint learning algorithms across both data center and edge computers be used to create optimal function allocation and the creation of semi-permanent datasets and analytics for usage trending and flow management resulting in better localization of XR functions?¶
• RQ 3.2.5: Can COIN improve the dynamic distribution of control, forwarding, and storage resources and related usage models in XR?¶
• RQ 3.2.6: How COIN provide the necessary infrastructure for the use of interactive XR everywhere?¶

3.2.6. Requirements

• Req 3.2.1: COIN systems for XR MUST allow joint collaboration across networks not just as part of the same subnetwork.¶
• Req 3.2.2: COIN systems for XR SHOULD provide multi-stream combining in the network for multi-views and efficient transmission.¶
• Req 3.2.3: COIN systems for XR SHOULD be able to dynamically include extra streams for data-intensive services and processes.¶
• Req 3.2.4: COIN systems for XR MAY use edge networking and computing for improved performance and performance management independent of a cloud connection.¶
• Req 3.2.5: COIN systems for XR MAY integrate local and fog caching with cloud-based pre-rendering.¶
• Req 3.2.6: COIN systems for XR SHOULD jointly optimize COIN and higher layer protocols to reduce latency especially in data-intensive applications at the edge.¶
• Req 3.2.7: COIN systems for XR SHOULD support nomadicity and mobility.¶
• Req 3.2.8: COIN systems for XR SHOULD provide means for performance optimization that reduces transmitted data and optimizes loss protection.¶
• Req 3.2.9: COIN systems for XR MAY provide means for trend analysis and telemetry.¶
• Req 3.2.10: COIN systems for XR SHOULD integrate PNDs with holography, 3D displays, and image rendering processors for offering to improve service location selections.¶
• Req 3.2.11: COIN systems for XR MAY provide means for managing the quality of XR sessions through reduced in-network congestion and improve flow delivery by determining how to prioritize XR data.¶

3.3.1. Description

This use case covers live productions of the performing arts where the performers and audience are in different physical locations. The performance is conveyed to the audience through multiple networked streams which may be tailored to the requirements of individual audience members; and the performers receive live feedback from the audience.¶

There are two main aspects: i) to emulate as closely as possible the experience of live performances where the performers and audience are co-located in the same physical space, such as a theater; and ii) to enhance traditional physical performances with features such as personalization of the experience according to the preferences or needs of the audience members.¶

Examples of personalization include:¶

• Viewpoint selection such as choosing a specific seat in the theater or for more advanced positioning of the audience member's viewpoint outside of the traditional seating - amongst, above or behind the performers (but within some limits which may be imposed by the performers or the director for artistic reasons);¶
• Augmentation of the performance with subtitles, audio-description, actor-tagging, language translation, advertisements/product-placement, other enhancements/filters to make the performance accessible to disabled audience members (removal of flashing images for epileptics, alternative color schemes for color-blind audience members, etc.).¶

3.3.2. Characterization

There are several chained functional entities which are candidates for being deployed as (COIN) programs:¶

• Performer aggregation and editing functions¶
• Distribution and encoding functions¶

• Personalization functions¶

  • to select which of the existing streams should be forwarded to the audience member¶
  • to augment streams with additional metadata such as subtitles¶
  • to create new streams after processing existing ones, e.g., to interpolate between camera angles to create a new viewpoint or to render point clouds from the audience member's chosen perspective¶
  • to undertake remote rendering according to viewer position, e.g., creation of VR headset display streams according to audience head position - when this processing has been offloaded from the viewer's end-system to the COIN function due to limited processing power in the end-system, or to limited network bandwidth to receive all of the individual streams to be processed.¶
• Audience feedback sensor processing functions¶
• Audience feedback aggregation functions¶

These are candidates for deployment as (COIN) Programs in PNDs rather than being located in end-systems (at the performers' site, the audience members' premises or in a central cloud location) for several reasons:¶

• Personalization of the performance according to audience preferences and requirements makes it unfeasible to be done in a centralized manner at the performer premises: the computational resources and network bandwidth would need to scale with the number of audience members' personalized streams.¶
• Rendering of VR headset content to follow viewer head movements has an upper bound on lag to maintain viewer QoE, which requires the processing to be undertaken sufficiently close to the viewer to avoid large network latencies.¶
• Viewer devices may not have the processing-power to undertake the personalization or the viewers' network may not have the capacity to receive all of the constituent streams to undertake the personalization functions.¶
• There are strict latency requirements for live and interactive aspects that require the deviation from the direct network path from performers to audience to be minimized, which reduces the opportunity to route streams via large-scale processing capabilities at centralized data-centers.¶

3.3.3. Existing solutions

Note: Existing solutions for some aspects of this use case are covered in the Mobile Application Offloading, Extended Reality, and Content Delivery Networks use cases.¶

3.3.4. Opportunities

• Executing media processing and personalization functions on-path as (COIN) Programs in PNDs can avoid detour/stretch to central servers, thus reducing latency and bandwidth consumption. For example, the overall delay for performance capture, aggregation, distribution, personalization, consumption, capture of audience response, feedback processing, aggregation, and rendering should be achieved within an upper bound of latency (the tolerable amount is to be defined, but in the order of 100s of ms to mimic performers perceiving audience feedback, such as laughter or other emotional responses in a theater setting).¶
• Processing of media streams allows (COIN) Programs, PNDs and the wider (COIN) System/Environment to be contextually aware of flows and their requirements which can be used for determining network treatment of the flows, e.g., path selection, prioritization, multi-flow coordination, synchronization and resilience.¶

3.3.5. Research Questions:

• RQ 3.3.1: In which PNDs should (COIN) Programs for aggregation, encoding and personalization functions be located? Close to the performers or close to the audience members?¶
• RQ 3.3.2: How far from the direct network path from performer to audience should (COIN) programs be located, considering the latency implications of path-stretch and the availability of processing capacity at PNDs? How should tolerances be defined by users?¶
• RQ 3.3.3: Should users decide which PNDs should be used for executing (COIN) Programs for their flows or should they express requirements and constraints that will direct decisions by the orchestrator/manager of the COIN System?¶
• RQ 3.3.4: How to achieve synchronization across multiple streams to allow for merging, audio-video interpolation, and other cross-stream processing functions that require time synchronization for the integrity of the output? How can this be achieved considering that synchronization may be required between flows that are: i) on the same data pathway through a PND/router, ii) arriving/leaving through different ingress/egress interfaces of the same PND/router, iii) routed through disjoint paths through different PNDs/routers? This RQ raises issues associated with synchronisation across multiple media streams and sub-streams [RFC7272] as well as time synchronisation between PNDs/routers on multiple paths [RFC8039].¶
• RQ 3.3.5: Where will COIN Programs be executed? In the data-plane of PNDs, in other on-router computational capabilities within PNDs, or in adjacent computational nodes?¶
• RQ 3.3.6: Are computationally-intensive tasks - such as video stitching or media recognition and annotation (cf. Section 3.2) - considered as suitable candidate (COIN) Programs or should they be implemented in end-systems?¶
• RQ 3.3.7: If the execution of COIN Programs is offloaded to computational nodes outside of PNDs, e.g. for processing by GPUs, should this still be considered as COIN? Where is the boundary between COIN capabilities and explicit routing of flows to endsystems?¶

3.3.6. Requirements

• Req 3.3.1: Users SHOULD be able to specify requirements on network and processing metrics (such as latency and throughput bounds).¶
• Req 3.3.2 The COIN System SHOULD be able to respect user-specified requirements and constraints when routing flows and selecting PNDs for executing (COIN) Programs.¶
• Req 3.3.3: A COIN System SHOULD be able to synchronize flow treatment and processing across multiple related flows which may be on disjoint paths.¶

4.1.1. Description

The control of physical processes and components of industrial production lines is essential for the growing automation of production and ideally allows for a consistent quality level. Traditionally, the control has been exercised by control software running on programmable logic controllers (PLCs) located directly next to the controlled process or component. This approach is best-suited for settings with a simple model that is focused on a single or few controlled components.¶

Modern production lines and shop floors are characterized by an increasing number of involved devices and sensors, a growing level of dependency between the different components, and more complex control models. A centralized control is desirable to manage the large amount of available information which often has to be pre-processed or aggregated with other information before it can be used. PLCs are not designed for this array of tasks and computations could theoretically be moved to more powerful devices. These devices are no longer close to the controlled objects and induce additional latency. Moving compute functionality onto COIN execution environments inside the network offers a new solution space to these challenges, providing new compute locations with much smaller latencies.¶

4.1.2. Characterization

A control process consists of two main components as illustrated in Figure 2: a system under control and a controller. In feedback control, the current state of the system is monitored, e.g., using sensors, and the controller influences the system based on the difference between the current and the reference state to keep it close to this reference state.¶

 reference
   state      ------------        --------    Output
---------->  | Controller | ---> | System | ---------->
           ^  ------------        --------       |
           |                                     |
           |   observed state                    |
           |                    ---------        |
            -------------------| Sensors | <-----
                                ---------

Apart from the control model, the quality of the control primarily depends on the timely reception of the sensor feedback which can be subject to tight latency constraints, often in the single-digit millisecond range. While low latencies are essential, there is an even greater need for stable and deterministic levels of latency, because controllers can generally cope with different levels of latency, if they are designed for them, but they are significantly challenged by dynamically changing or unstable latencies. The unpredictable latency of the Internet exemplifies this problem if, e.g., off-premise cloud platforms are included.¶

4.1.3. Existing Solutions

Control functionality is traditionally executed on PLCs close to the machinery. These PLCs typically require vendor-specific implementations and are often hard to upgrade and update which makes such control processes inflexible and difficult to manage. Moving computations to more freely programmable devices thus has the potential of significantly improving the flexibility. In this context, directly moving control functionality to (central) cloud environments is generally possible, yet only feasible if latency constraints are lenient.¶

Early approaches such as [RUETH] and [VESTIN] have already shown the general applicability of leveraging COIN for in-network control.¶

4.1.4. Opportunities

• Performing simple control logic on PNDs and/or in COIN execution environments can bring the controlled system and the controller closer together, possibly satisfying the tight latency requirements.¶
• Creating a coupled control that is exercised via (i) simplified approximations of more complex control algorithms deployed in COIN execution environments, and (ii) more complex overall control schemes deployed in the cloud can allow for quicker, yet more inaccurate responses from within the network while still providing for sufficient control accuracy at higher latencies from afar.¶

4.1.5. Research Questions

• RQ 4.1.1: How to derive simplified versions of the global (control) function?¶

  • How to account for the limited computational precision of PNDs, typically only allowing for integer precision computation, while floating-point precision is needed by most control algorithms (cf. [KUNZE-APPLICABILITY])?¶
  • How to find suitable tradeoffs regarding simplicity of the control function ("accuracy of the control") and implementation complexity ("implementability")?¶

• RQ 4.1.2: How to distribute the simplified versions in the network?¶

  • Can there be different control levels, e.g., "quite inaccurate & very low latency" (PNDs, deep in the network), "more accurate & higher latency" (more powerful COIN execution environments, farer away), "very accurate & very high latency" (cloud environments, far away)?¶
  • Who decides which control instance is executed and how?¶
  • How do the different control instances interact?¶

4.1.6. Requirements

• Req 4.1.1: The interaction between the COIN execution environments and the global controller SHOULD be explicit.¶
• Req 4.1.2: The interaction between the COIN execution environments and the global controller MUST NOT negatively impact the control quality.¶
• Req 4.1.3: Actions of the COIN execution environments MUST be overridable by the global controller.¶
• Req 4.1.4: Functions in COIN execution environments SHOULD be executed with predictable delay.¶
• Req 4.1.5: Functions in COIN execution environments MUST be executed with predictable accuracy.¶

4.2.1. Description

In modern industrial networks, processes and machines are extensively monitored by distributed sensors with a large spectrum of capabilities, ranging from simple binary (e.g., light barriers) to sophisticated sensors with varying degrees of resolution. Sensors further serve different purposes, as some are used for time-critical process control while others represent redundant fallback platforms. Overall, there is a high level of heterogeneity which makes managing the sensor output a challenging task.¶

Depending on the deployed sensors and the complexity of the observed system, the resulting overall data volume can easily be in the range of several Gbit/s [GLEBKE]. These volumes are often already difficult to handle in local environments and it becomes even more challenging when off-premise clouds are used for managing the data. While large networking companies can simply upgrade their infrastructure to accommodate the accruing data volumes, most industrial companies operate on tight infrastructure budgets and upgrading is hence not always feasible or possible. A major challenge is thus to devise a methodology that is able to handle such amounts of data over limited access links.¶

Data filtering and pre-processing, similar to the considerations in Section 3.2, can be building blocks for new solutions in this space. Such solutions, however, might also have to address the added challenge of business data leaving the premises and control of the company. As this data could include sensitive information or valuable business secrets, additional security measures have to be taken. Yet, typical security measures such as encrypting the data make filtering or pre-processing approaches hardly applicable as they typically work on unencrypted data. Consequently, incorporating security into these approaches, either by adding functionality for handling encrypted data or devising general security measures, is thus an additional auspicious field for research.¶

4.2.2. Characterization

In essence, the described monitoring systems consist of sensors that produce large volumes of monitoring data. This data is then transmitted to additional components that provide data processing and analysis capabilities or simply store the data in large data silos.¶

As sensors are often set up redundantly, part of the collected data might also be redundant. Moreover, sensors are often hard to configure or not configurable at all which is why their resolution or sampling frequency is often larger than required. Consequently, it is likely that more data is transmitted than is needed or desired, prompting the deployment of filtering techniques. For example, COIN programs deployed in the on-premise network could filter out redundant or undesired data before it leaves the premise using simple traffic filters, thus reducing the required (upload) bandwidths. The available sensor data could be scaled down using packet-based sub-sampling or using filtering as long as the sensor value is in an uninteresting range while forwarding with a higher resolution once the sensor value range becomes interesting (cf. [KUNZE-SIGNAL]). While the former variant is oblivious to the semantics of the sensor data, the latter variant requires an understanding of the current sensor levels. In any case, it is important that end-hosts are informed about the filtering so that they can distinguish between data loss and data filtered out on purpose.¶

In practice, the collected data is further processed using manifold computations. Some of them are very complex or need the complete sensor data during the computation, but there are also simpler operations which can already be done on subsets of the overall dataset or earlier on the communication path as soon as all data is available. One example is finding the maximum of all sensor values which can either be done iteratively at each intermediate hop or at the first hop, where all data is available. Using expert knowledge about the exact computation steps and the concrete transmission path of the sensor data, simple computation steps can thus be deployed in the on-premise network, again reducing the overall data volume.¶

4.2.3. Existing Solutions

Current approaches for handling such large amounts of information typically build upon stream processing frameworks such as Apache Flink. While they allow for handling large volume applications, they are tied to performant server machines and upscaling the information density also requires a corresponding upscaling of the compute infrastructure.¶

4.2.4. Opportunities

• (Semantic) packet filtering based on packet header and payload, as well as multi-packet information can (drastically) reduce the data volume, possibly even without losing any important information.¶
• (Semantic) data (pre-)processing, e.g., in the form of computations across multiple packets and potentially leveraging packet payload, can also reduce the data volume without losing any important information.¶

4.2.5. Research Questions

• RQ 4.2.1: How can the overall data processing pipeline be divided into individual processing steps that could then be deployed as COIN functionality?¶

• RQ 4.2.2: How to design COIN programs for (semantic) packet filtering?¶

  • Which criteria for filtering make sense?¶

• RQ 4.2.3: Which kinds of COIN programs can be leveraged for (pre-)processing steps?¶

  • How complex can they become?¶
• RQ 4.2.4: How to distribute and coordinate COIN programs?¶
• RQ 4.2.5: How to dynamically change COIN programs?¶

• RQ 4.2.6: How to incorporate the (pre-)processing and filtering steps into the overall system?¶

  • How can changes to the data by COIN programs be signaled to the end-hosts?¶

4.2.6. Requirements

• Req 4.2.1: Filters and preprocessors MUST conform to application-level syntax and semantics.¶
• Req 4.2.2: Filters and preprocessors MAY leverage packet header and payload information.¶
• Req 4.2.3: Filters and preprocessors SHOULD be reconfigurable at run-time.¶

4.3.1. Description

Despite an increasing automation in production processes, human workers are still often necessary. Consequently, safety measures have a high priority to ensure that no human life is endangered. In traditional factories, the regions of contact between humans and machines are well-defined and interactions are simple. Simple safety measures like emergency switches at the working positions are enough to provide a good level of safety.¶

Modern factories are characterized by increasingly dynamic and complex environments with new interaction scenarios between humans and robots. Robots can either directly assist humans or perform tasks autonomously. The intersect between the human working area and the robots grows and it is harder for human workers to fully observe the complete environment. Additional safety measures are essential to prevent accidents and support humans in observing the environment.¶

4.3.2. Characterization

Industrial safety measures are typically hardware solutions because they have to pass rigorous testing before they are certified and deployment-ready. Standard measures include safety switches and light barriers. Additionally, the working area can be explicitly divided into 'contact' and 'safe' areas, indicating when workers have to watch out for interactions with machinery.¶

These measures are static solutions, potentially relying on specialized hardware, and are challenged by the increased dynamics of modern factories where the factory configuration can be changed on demand. Software solutions offer higher flexibility as they can dynamically respect new information gathered by the sensor systems, but in most cases they cannot give guaranteed safety. COIN systems could leverage the increased availability of sensor data and the detailed monitoring of the factories to enable additional safety measures with shorter response times and higher guarantees. Different safety indicators within the production hall could be combined within the network so that PNDs can give early responses if a potential safety breach is detected. For example, the positions of human workers and robots could be tracked and robots could be stopped when they get too close to a human in a non-working area or if a human enters a defined safety zone. More advanced concepts could also include image data or combine arbitrary sensor data.¶

4.3.3. Existing Solutions

Due to the importance of safety, there is a wide range of software-based approaches aiming at enhancing security. One example are tag-based systems, e.g., using RFID, where drivers of forklifts can be warned if pedestrian workers carrying tags are nearby. Such solutions, however, require setting up an additional system and do not leverage existing sensor data.¶

4.3.4. Opportunities

• Executing safety-critical COIN functions on PNDs could allow for early emergency reactions based on diverse sensor feedback with low latencies.¶

4.3.5. Research Questions

• RQ 4.3.1: Which additional safety measures can be provided?¶

  • Do these measures actually improve safety?¶
• RQ 4.3.2: Which sensor information can be combined and how?¶

4.3.6. Requirements

• Req 4.3.1: COIN-based safety measures MUST NOT degrade existing safety measures.¶
• Req 4.3.2: COIN-based safety measures MAY enhance existing safety measures.¶

5.1.1. Description

Delivery of content to end users often relies on Content Delivery Networks (CDNs). CDNs store said content closer to end users for latency-reduced delivery and they often utilize DNS-based indirection to serve the request on behalf of the origin server.¶

5.1.2. Characterization

From the perspective of this draft, a CDN can be interpreted as a (network service level) set of (COIN) programs. These programs implement a distributed logic for first distributing content from the origin server to the CDN ingress and then further to the CDN replication points which ultimately serve the user-facing content requests.¶

5.1.3. Existing Solutions

CDN technologies have been well described and deployed in the existing Internet. Core technologies like Global Server Load Balancing (GSLB) [GSLB] and Anycast server solutions are used to deal with the required indirection of a content request (usually in the form of an HTTP request) to the most suitable local CDN server. Content is replicated from seeding servers, which serve as injection points for content from content owners/producers, to the actual CDN servers, who will eventually serve the user's request. The replication architecture and mechanisms itself differs from one (CDN) provider to another, and often utilizes private peering or network arrangements in order to distribute the content internationally and regionally.¶

Studies such as those in [FCDN] have shown that content distribution at the level of named content, utilizing efficient (e.g., Layer 2) multicast for replication towards edge CDN nodes, can significantly increase the overall network and server efficiency. It also reduces indirection latency for content retrieval as well as required edge storage capacity by benefiting from the increased network efficiency to renew edge content more quickly against changing demand.¶

5.1.4. Opportunities

• Supporting service-level routing of requests (service routing in [APPCENTRES]) to specific (COIN) program instances may improve on end user experience in faster retrieving (possibly also more, e.g., better quality) content.¶
• Supporting the constraint-based selection of a specific (COIN) program instance over others (constraint-based routing in [APPCENTRES]) may improve the overall end user experience by selecting a 'more suitable' (COIN) program instance over another, e.g., avoiding/reducing overload situations in specific (COIN) program instances.¶
• Supporting Layer 2 capabilities for multicast (compute interconnection and collective communication in [APPCENTRES]) may increase the network utilization and therefore increase the overall system utilization.¶

5.1.5. Research Questions

In addition to the research questions in Section 3.1.5:¶

• RQ 5.1.1: How to utilize L2 multicast to improve on CDN designs? How to utilize COIN capabilities in those designs?¶
• RQ 5.1.2: What forwarding methods may support the required multicast capabilities (see [FCDN])?¶
• RQ 5.1.3: What are the right routing constraints that reflect both compute and network capabilities?¶
• RQ 5.1.4: Could traffic steering be performed on the data path and per service request? If so, what would be performance improvements?¶
• RQ 5.1.5: How could storage be traded off against frequent, multicast-based replication (see [FCDN])?¶
• RQ 5.1.6: What scalability limits exist for L2 multicast capabilities? How to overcome them?¶

5.1.6. Requirements

Requirements 3.1.1 through 3.1.6 also apply for CDN service access. In addition:¶

• Req 5.1.1: Any solution SHOULD utilize Layer 2 multicast transmission capabilities for responses to concurrent service requests.¶

5.2.1. Description

Layer 2 connected compute resources, e.g., in regional or edge data centers, base stations, and even end user devices, provide the opportunity for infrastructure providers to offer CFaaS-like offerings to application providers. App and service providers may utilize the compute fabric exposed by this CFaaS offering for the purposes defined through their applications and services. In other words, the compute resources can be utilized to execute the desired (COIN) programs of which the application is composed, while utilizing the interconnection between those compute resources to do so in a distributed manner.¶

5.2.2. Characterization

We foresee those CFaaS offerings to be tenant-specific, a tenant here defined as the provider of at least one application. For this, we foresee an interaction between CFaaS provider and tenant to dynamically select the appropriate resources to define the demand side of the fabric. Conversely, we also foresee the supply side of the fabric to be highly dynamic with resources being offered to the fabric through, e.g., user-provided resources (whose supply might depend on highly context-specific supply policies) or infrastructure resources of intermittent availability such as those provided through road-side infrastructure in vehicular scenarios.¶

The resulting dynamic demand-supply matching establishes a dynamic nature of the compute fabric that in turn requires trust relationships to be built dynamically between the resource provider(s) and the CFaaS provider. This also requires the communication resources to be dynamically adjusted to suitably interconnect all resources into the (tenant-specific) fabric exposed as CFaaS.¶

5.2.3. Existing Solutions

There exist a number of technologies to build non-local (wide area) Layer 2 networks, which in turn allows for connecting compute resources for a distributed computational task. 5G-LAN [SA2-5GLAN] specifies a cellular L2 bearer for interconnecting L2 resources within a single cellular operator. The work in [ICN5GLAN] outlines using a path-based forwarding solution over 5G-LAN as well as SDN-based LAN connectivity together with an ICN-based naming of IP and HTTP-level resources to achieve computational interconnections, including scenarios such as those outlined in Section 3.1. L2 network virtualization (see, e.g., [L2Virt]) is one of the methods used for realizing so-called 'cloud-native' applications for applications developed with 'physical' networks in mind, thus forming an interconnected compute and storage fabric.¶

5.2.4. Opportunities

• Supporting service-level routing of compute resource requests (service routing in [APPCENTRES]) may allow for utilizing the wealth of compute resources in the overall CFaaS fabric for execution of distributed applications, where the distributed constituents of those applications are realized as (COIN) programs and executed within a COIN system as (COIN) program instances.¶
• Supporting the constraint-based selection of a specific (COIN) program instance over others (constraint-based routing in [APPCENTRES]) will allow for optimizing both the CFaaS provider constraints as well as tenant-specific constraints.¶
• Supporting Layer 2 capabilities for multicast (compute interconnection and collective communication in [APPCENTRES]) will allow for increasing both network utilization but also possible compute utilization (due to avoiding unicast replication at those compute endpoints), thereby decreasing total cost of ownership for the CFaaS offering.¶

5.2.5. Research Questions

In addition to the research questions in Section 3.1.5:¶

• RQ 5.2.1: How to convey tenant-specific requirements for the creation of the L2 fabric?¶
• RQ 5.2.2: How to dynamically integrate resources, particularly when driven by tenant-level requirements and changing service-specific constraints?¶
• RQ 5.2.3: How to utilize COIN capabilities to aid the availability and accountability of resources, i.e., what may be (COIN) programs for a CFaaS environment that in turn would utilize the distributed execution capability of a COIN system?¶

5.2.6. Requirements

Requirements 3.1.1 through 3.1.6 also apply for the provisioning of services atop the CFaaS. In addition:¶

• Req 5.2.1: Any solution SHOULD expose means to specify the requirements for the tenant-specific compute fabric being utilized for the service execution.¶
• Req 5.2.2: Any solution SHOULD allow for dynamic integration of compute resources into the compute fabric being utilized for the app execution; those resources include, but are not limited to, end user provided resources. From a COIN system perspective, new resources must be possible to be exposed as possible (COIN) execution environments.¶
• Req 5.2.3: Any solution MUST provide means to optimize the interconnection of compute resources, including those dynamically added and removed during the provisioning of the tenant-specific compute fabric.¶
• Req 5.2.4: Any solution MUST provide means for ensuring that availability and usage of resources is accounted for.¶

5.3.1. Description

The term "virtual network programming" is proposed to describe mechanisms by which tenants deploy and operate COIN programs in their virtual network. Such COIN programs can, e.g., be P4 programs, OpenFlow rules, or higher layer programs. This feature can enable other use cases described in this draft to be deployed using virtual networks services, over underlying networks such as datacenters, mobile networks, or other fixed or wireless networks.¶

For example, COIN programs could perform the following on a tenant's virtual network:¶

• Allow or block flows, and request rules from an SDN controller for each new flow, or for flows to or from specific hosts that need enhanced security¶
• Forward a copy of some flows towards a node for storage and analysis¶
• Update counters based on specific sources/destinations or protocols, for detailed analytics¶
• Associate traffic between specific endpoints, using specific protocols, or originated from a given application, to a given slice, while other traffic uses a default slice¶
• Experiment with a new routing protocol (e.g., ICN), using a P4 implementation of a router for this protocol¶

5.3.2. Characterization

To provide a concrete example of virtual COIN programming, we consider a use case using a 5G underlying network, the 5GLAN virtualization technology, and the P4 programming language and environment. Section 5.1 of [I-D.ravi-icnrg-5gc-icn] provides a description of the 5G network functions and interfaces relevant to 5GLAN, which are otherwise specified in [TS23.501] and [TS23.502]. From the 5GLAN service customer/tenant standpoint, the 5G network operates as a switch.¶

In the use case depicted in Figure 3, the tenant operates a network including a 5GLAN network segment (seen as a single logical switch), as well as fixed segments. The mobile devices (or User Equipment nodes) UE1, UE2, UE3 and UE4 are in the same 5GLAN, as well as Device1 and Device2 (through UE4). This scenario can take place in a plant or enterprise network, using, e.g., a 5G Non-Public Network. The tenant uses P4 programs to determine the operation of both the fixed and 5GLAN switches. The tenant provisions a 5GLAN P4 program into the mobile network, and can also operate a controller.¶

                                     ..... Tenant ........
                          P4 program :                   :
                          deployment :         Operation :
                                     V                   :
  +-----+  air interface +----------------+              :
  | UE1 +----------------+                |              :
  +-----+                |                |              :
                         |                |              :
  +-----+                |                |              V
  | UE2 +----------------+     5GLAN      |      +------------+
  +-----+                |    Logical     +------+ Controller |
                         |     Switch     |  P4  +-------+----+
  +-----+                |                |  runtime     |
  | UE3 +----------------+                |  API         |
  +-----+                |                |              |
                         |                |              |
  +-----+                |                |              |
+-+ UE4 +----------------+                |              |
| +-----+                +----------------+              |
|                                                        |
| Fixed or wireless connection                           |
|                                    P4 runtime API      |
|  +---------+           +-------------------------------+
+--+ Device1 |           |
|  +---------+           |
|                        |
|  +---------+    +------+-----+
`--+ Device2 +----+ P4 Switch  +--->(fixed network)
   +---------+    +------------+

5.3.3. Existing Solutions

Research has been conducted, for example by [Stoyanov], to enable P4 network programming of individual virtual switches. To our knowledge, no complete solution has been developed for deploying virtual COIN programs over mobile or datacenter networks.¶

5.3.4. Opportunities

Virtual network programming by tenants could bring benefits such as:¶

• A unified programming model, which can facilitate porting COIN programs between data centers, 5G networks, and other fixed and wireless networks, as well as sharing controller, code and expertise.¶
• Increasing the level of customization available to customers/tenants of mobile networks or datacenters compared to typical configuration capabilities. For example, 5G network evolution points to an ever increasing specialization and customization of private mobile networks, which could be handled by tenants using a programming model similar to P4.¶
• Using network programs to influence underlying network services, e.g., request specific QoS for some flows in 5G or datacenters, to increase the level of in-depth customization available to tenants.¶

5.3.5. Research Questions

• RQ 5.3.1: Underlying Network Awareness: a virtual COIN program can be able to influence, and be influenced by, the underling network. Since some information and actions may be available on some nodes and not others, underlying network awareness may impose additional constraints on distributed network programs location.¶
• RQ 5.3.2: Splitting/Distribution: a virtual COIN program may need to be deployed across multiple computing nodes, leading to research questions around instance placement and distribution. For example, program logic should be applied exactly once or at least once per packet, while allowing optimal forwarding path by the underlying network. Research challenges include defining manual (by the programmer) or automatic methods to distribute COIN programs that use a low or minimal amount of resources. Distributed P4 programs are studied in [I-D.hsingh-coinrg-reqs-p4comp] and [Sultana].¶
• RQ 5.3.3: Multi-Tenancy Support: multiple virtual COIN program instances can run on the same compute node. While mechanisms were proposed for P4 multi-tenancy in a switch [Stoyanov], research questions remain about isolation between tenants and fair repartition of resources.¶
• RQ 5.3.4: Security: how can tenants and underlying networks be protected against security risks, including overuse or misuse of network resources, injection of traffic, or access to unauthorized traffic?¶
• RQ 5.3.5: Higher layer processing: can a virtual network model facilitate the deployment of COIN programs acting on application layer data? This is an open question since the present section focused on packet/flow processing.¶

5.3.6. Requirements

• Req 5.3.1: A COIN system supporting virtualization SHOULD enable tenants to deploy COIN programs onto their virtual networks.¶
• Req 5.3.2: A virtual COIN program SHOULD process flows/packets once and only once (or at least once for idempotent operations), even if the program is distributed over multiple PNDs.¶
• Req 5.3.3: Multi-tenancy SHOULD be supported for virtual COIN programs, i.e., instances of virtual COIN programs from different tenants can share underlying PNDs. This includes requirements for secure isolation between tenants, and fair (or policy-based) sharing of computing resources.¶
• Req 5.3.4: Virtual COIN programs SHOULD support mobility of endpoints.¶

6.1.1. Description

There is a growing range of use cases demanding for the realization of AI capabilities among distributed endpoints. Such demand may be driven by the need to increase overall computational power for large-scale problems. From a COIN perspective, those capabilities may be realized as (COIN) programs and executed throughout the COIN system, including in PNDs.¶

Some solutions may desire the localization of reasoning logic, e.g., for deriving attributes that better preserve privacy of the utilized raw input data. Quickly establishing (COIN) program instances in nearby compute resources, including PNDs, may even satisfy such localization demands on-the-fly (e.g., when a particular use is being realized, then terminated after a given time).¶

6.1.2. Characterization

Examples for large-scale AI problems include biotechnology and astronomy related reasoning over massive amounts of observational input data. Examples for localizing input data for privacy reasons include radar-like application for the development of topological mapping data based on (distributed) radio measurements at base stations (and possibly end devices), while the processing within radio access networks (RAN) already constitutes a distributed AI problem to a certain extent albeit with little flexibility in distributing the execution of the AI logic.¶

6.1.3. Existing Solutions

Reasoning frameworks, such as TensorFlow, may be utilized for the realization of the (distributed) AI logic, building on remote service invocation through protocols such as gRPC [GRPC] or MPI [MPI] with the intention of providing an on-chip NPU (neural processor unit) like abstraction to the AI framework.¶

A number of activities on distributed AI exist in the area of developing the 5th and 6th generation mobile network with various activities in the 3GPP SDO as well as use cases developed for the ETSI MEC initiative mentioned in previous use cases.¶

6.1.4. Opportunities

• Supporting service-level routing of requests (service routing in [APPCENTRES]), with AI services being exposed to the network and executed as part of (COIN) programs in selected (COIN) program instances, may provide a highly distributed execution of the overall AI logic, thereby addressing, e.g., localization but also computational concerns (scale-in/out).¶
• The support for constraint-based selection of a specific (COIN) program instance over others (constraint-based routing in [APPCENTRES]) may allow for utilizing the most suitable HW capabilities (e.g., support for specific AI HW assistance in the COIN element, including a PND), while also allowing to select resources, e.g., based on available compute ability such as number of cores to be used.¶
• Supporting collective communication between multiple instances of AI services, i.e., (COIN) program instances, may positively impact network but also compute utilization by moving from unicast replication to network-assisted multicast operation.¶

6.1.5. Research Questions

In addition to the research questions in Section 3.1.5:¶

• RQ 6.1.1: What are the communication patterns that may be supported by collective communication solutions?¶
• RQ 6.1.2: How to achieve scalable multicast delivery with rapidly changing receiver sets?¶
• RQ 6.1.3: What COIN capabilities may support the collective communication patterns found in distributed AI problems?¶
• RQ 6.1.4: How to provide a service routing capability that supports any invocation protocol (beyond HTTP)?¶

6.1.6. Requirements

Requirements 3.1.1 through 3.1.6 also apply for general distributed AI capabilities. In addition:¶

• Req 6.1.1: Any COIN system MUST provide means to specify the constraints for placing (AI) execution logic in the form of (COIN) programs in certain logical execution points (and their associated physical locations), including PNDs.¶
• Req 6.1.2: Any COIN system MUST provide support for app/micro-service specific invocation protocols for requesting (COIN) program services exposed to the COIN system.¶