Internet Research Task Force (IRTF) I. Kunze
Request for Comments: 9817 K. Wehrle
Category: Informational RWTH Aachen
ISSN: 2070-1721 D. Trossen
DaPaDOT Tech
M-J. Montpetit
SLICES-RI
X. de Foy
InterDigital Communications, LLC
D. Griffin
M. Rio
UCL
August 2025
Computing in the Network (COIN) comes with the prospect of deploying processing functionality on networking devices such as switches and network interface cards. While such functionality can be beneficial, it has to be carefully placed into the context of the general Internet communication, and it needs to be clearly identified where and how those benefits apply.
ネットワーク内のコンピューティング（COIN）には、スイッチやネットワークインターフェイスカードなどのネットワークデバイスに処理機能を展開する見込みがあります。そのような機能は有益ですが、一般的なインターネット通信のコンテキストに慎重に配置する必要があり、それらの利点がどこでどのように適用されるかを明確に特定する必要があります。
This document presents some use cases to demonstrate how a number of salient COIN-related applications can benefit from COIN. Furthermore, to guide research on COIN, it identifies essential research questions and outlines desirable capabilities that COIN systems addressing these use cases may need to support. Finally, the document provides a preliminary categorization of the described research questions to source future work in this domain. This document is a product of the Computing in the Network Research Group (COINRG). It is not an IETF product and it is not a standard.
このドキュメントでは、いくつかのユースケースを提示して、多くの顕著なコイン関連アプリケーションがコインからどのように恩恵を受けることができるかを示します。さらに、コインに関する研究を導くために、これらのユースケースに対処するコインシステムがサポートする必要がある可能性のある望ましい能力を特定し、概説します。最後に、このドキュメントは、このドメインでの将来の作業を調達するために、説明されている研究質問の予備分類を提供します。このドキュメントは、ネットワーク研究グループ（CoINRG）のコンピューティングの製品です。IETF製品ではなく、標準ではありません。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Computing in the Network (COIN) Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネット研究タスクフォース（IRTF）の製品です。IRTFは、インターネット関連の研究開発活動の結果を公開しています。これらの結果は、展開に適していない場合があります。このRFCは、インターネット研究タスクフォース（IRTF）のネットワーク（COIN）研究グループのコンピューティングのコンセンサスを表しています。IRSGによって公開されたことが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9817.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9817で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Terminology
3. Providing New COIN Experiences
3.1. Mobile Application Offloading
3.2. Extended Reality and Immersive Media
3.3. Personalized and Interactive Performing Arts
4. Supporting New COIN Systems
4.1. In-Network Control / Time-Sensitive Applications
4.2. Large-Volume Applications
4.3. Industrial Safety
5. Improving Existing COIN Capabilities
5.1. Content Delivery Networks
5.2. Compute-Fabric-as-a-Service (CFaaS)
5.3. Virtual Networks Programming
6. Enabling New COIN Capabilities
6.1. Distributed AI Training
7. Preliminary Categorization of the Research Questions
8. Security Considerations
9. IANA Considerations
10. Conclusion
11. Informative References
Acknowledgements
Authors' Addresses
The Internet was designed as a best-effort packet network, forwarding packets from source to destination with limited guarantees regarding their timely and successful reception. Data manipulation, computation, and more complex protocol functionalities are generally provided by the end hosts, while network nodes are commonly kept simple and only offer a "store and forward" packet facility. This simplicity of purpose of the network has shown to be suitable for a wide variety of applications and has facilitated the rapid growth of the Internet. However, introducing middleboxes with specialized functionality for enhancing performance has often led to problems due to their inflexibility.
インターネットは、ベストエフェクトパケットネットワークとして設計されており、ソースから目的地にパケットを転送し、タイムリーで成功したレセプションに関する保証が限られています。データ操作、計算、およびより複雑なプロトコル機能は一般にエンドホストによって提供されますが、ネットワークノードは一般にシンプルに保たれ、「ストアとフォワード」パケット機能を提供します。ネットワークのこの単純さは、さまざまなアプリケーションに適していることが示されており、インターネットの急速な成長を促進しています。ただし、パフォーマンスを向上させるための特殊な機能を備えたミドルボックスを導入することで、柔軟性があるため問題が発生しました。
However, with the rise of new services, some of which are described in this document, there is a growing number of application domains that require more than best-effort forwarding, including strict performance guarantees or closed-loop integration to manage data flows. In this context, allowing for a tighter integration of computing and networking resources for enabling a more flexible distribution of computation tasks across the network (e.g., beyond "just" endpoints and without requiring specialized middleboxes) may help to achieve the desired guarantees and behaviors, increase overall performance, and improve resilience to failures.
ただし、このドキュメントに記載されている新しいサービスの増加により、データフローを管理するための厳格なパフォーマンス保証や閉ループ統合など、最良のエフォルトの転送を必要とするアプリケーションドメインが増えています。これに関連して、ネットワーク全体の計算タスクのより柔軟な分布を可能にするためのコンピューティングとネットワーキングリソースの統合をより厳しくすることができます（たとえば、「ちょうど」エンドポイントを超えて、特殊なミドルボックスを必要とせずに）、望ましい保証と行動を達成し、全体的なパフォーマンスを向上させ、回復力を改善するのに役立ちます。
The vision of "in-network computing" and the provisioning of such capabilities that capitalize on joint computation and communication resource usage throughout the network is part of the move from a telephone network analogy of the Internet into a more distributed computer board architecture. We refer to those capabilities as "COIN capabilities" in the remainder of the document.
ネットワーク全体での共同計算と通信リソースの使用を活用する「ネットワークコンピューティング」のビジョンと、インターネットの電話ネットワークの類似性から、より分散したコンピューターボードアーキテクチャへの移行の一部です。これらの機能は、文書の残りの部分で「コイン機能」と呼びます。
We believe that this vision of in-network computing can be best outlined along four dimensions of use cases, namely those that:
ネットワーク内のコンピューティングのこのビジョンは、ユースケースの4つの次元、すなわちそれが次のような概要に沿って最もよく概説できると考えています。
i. provide new user experiences through the utilization of COIN capabilities (referred to as "COIN experiences"),
i. コイン機能（「コインエクスペリエンス」と呼ばれる）を使用して、新しいユーザーエクスペリエンスを提供し、
ii. enable new COIN systems (e.g., through new interactions between communication and compute providers),
ii。新しいコインシステムを有効にします（たとえば、通信プロバイダーと計算プロバイダーの間の新しい相互作用を通じて）、
iii. improve on already existing COIN capabilities, and
iii。すでに既存のコイン機能を改善します
iv. enable new COIN capabilities.
IV。新しいコイン機能を有効にします。
Sections 3 through 6 capture those categories of use cases and provide the main structure of this document. The goal is to present how computing resources inside the network impact existing services and applications or allow for innovation in emerging application domains.
セクション3〜6は、これらのカテゴリのユースケースをキャプチャし、このドキュメントの主要な構造を提供します。目標は、ネットワーク内のコンピューティングリソースを既存のサービスとアプリケーションにどのように影響するか、または新興アプリケーションドメインのイノベーションを可能にする方法を提示することです。
By delving into some individual examples within each of the above categories, we outline opportunities and propose possible research questions for consideration by the wider community when pushing forward in-network computing architectures. Furthermore, identifying desirable capabilities for an evolving solution space of COIN systems is another objective of the use case descriptions. To achieve this, the following taxonomy is proposed to describe each of the use cases:
上記の各カテゴリ内の個々の例を掘り下げることにより、機会の概要を説明し、ネットワーク内のコンピューティングアーキテクチャを前進させる際に、より広いコミュニティが考慮するための可能な研究質問を提案します。さらに、コインシステムの進化するソリューション空間の望ましい機能を特定することは、ユースケースの説明のもう1つの目的です。これを達成するために、次の分類法が提案されています。各ユースケースを説明します。
Description:
説明：
A high-level presentation of the purpose of the use case and a short explanation of the use case behavior.
ユースケースの目的の高レベルのプレゼンテーションと、ユースケースの動作の短い説明。
Characterization:
特性評価：
An explanation of the services that are being utilized and realized as well as the semantics of interactions in the use case.
使用され、実現されているサービスの説明と、ユースケースでの相互作用のセマンティクス。
Existing solutions:
既存のソリューション：
A description of current methods that may realize the use case (if they exist), though not claiming to exhaustively review the landscape of solutions.
ソリューションの風景を徹底的に確認すると主張していないが、ユースケースを実現する可能性のある現在の方法の説明（存在する場合）。
Opportunities:
機会：
An outline of how COIN capabilities may support or improve on the use case in terms of performance and other metrics.
パフォーマンスやその他のメトリックの観点から、コイン機能がユースケースをサポートまたは改善する方法の概要。
Research questions:
研究の質問：
Essential questions that are suitable for guiding research to achieve the identified opportunities. The research questions also capture immediate capabilities for any COIN solution addressing the particular use case whose development may immediately follow when working toward answers to the research questions.
特定された機会を達成するために研究を導くのに適した重要な質問。また、研究の質問は、研究の質問への回答に向けて取り組むときに開発がすぐに続く可能性のある特定のユースケースに対処するコインソリューションの即時能力をキャプチャします。
Additional desirable capabilities:
追加の望ましい機能：
A description of additional capabilities that might not require research but may be desirable for any COIN solution addressing the particular use case; we limit these capabilities to those directly affecting COIN, recognizing that any use case will realistically require many additional capabilities for its realization. We omit this dedicated section if relevant capabilities are already sufficiently covered by the corresponding research questions.
研究を必要としないかもしれないが、特定のユースケースに対処するコインソリューションには望ましい可能性のある追加の機能の説明。これらの機能は、コインに直接影響を与える人々に制限し、あらゆるユースケースがその実現のために多くの追加機能を現実的に必要とすることを認識します。関連する機能が対応する研究の質問ですでに十分にカバーされている場合、この専用セクションを省略します。
This document discusses these six aspects along a number of individual use cases to demonstrate the diversity of COIN applications. It is intended as a basis for further analyses and discussions within the wider research community. This document has received review comments at different stages of its development, by experts within and out of COINRG, as detailed in the Acknowledgements section. This document represents the consensus of COINRG.
このドキュメントでは、多くの個々のユースケースに沿ったこれらの6つの側面について説明し、コインアプリケーションの多様性を実証します。これは、より広い研究コミュニティ内でのさらなる分析と議論の基礎として意図されています。このドキュメントは、Coinrg内外の専門家によって、謝辞セクションで詳述されているように、開発のさまざまな段階でレビューコメントを受け取りました。このドキュメントは、Coinrgのコンセンサスを表しています。
This document uses the terminology defined below.
このドキュメントでは、以下に定義されている用語を使用します。
Programmable Network Devices (PNDs):
プログラム可能なネットワークデバイス（PND）：
network devices, such as network interface cards and switches, which are programmable (e.g., using P4 [P4] or other languages).
プログラム可能なネットワークインターフェイスカードやスイッチなどのネットワークデバイス（たとえば、P4 [P4]またはその他の言語を使用するなど）。
COIN execution environment:
コインの実行環境：
a class of target environments for function execution, for example, an execution environment based on the Java Virtual Machine (JVM) that can run functions represented in JVM byte code.
機能実行のためのターゲット環境のクラス、たとえば、JVMバイトコードで表される関数を実行できるJava仮想マシン（JVM）に基づく実行環境。
COIN system:
コインシステム：
the PNDs (and end systems) and their execution environments, together with the communication resources interconnecting them, operated by a single provider or through interactions between multiple providers that jointly offer COIN capabilities.
PND（およびエンドシステム）とその実行環境は、それらを相互接続する通信リソースとともに、単一のプロバイダーによって運営されているか、コイン機能を共同で提供する複数のプロバイダー間のやり取りを通じて運用されます。
COIN capability:
コイン機能：
a feature enabled through the joint processing of computation and communication resources in the network.
ネットワーク内の計算および通信リソースの共同処理を通じて有効になっている機能。
COIN program:
コインプログラム：
a monolithic functionality that is provided according to the specification for said program and which may be requested by a user. A composite service can be built by orchestrating a combination of monolithic COIN programs.
上記のプログラムの仕様に従って提供され、ユーザーが要求する可能性のあるモノリシック機能。複合サービスは、モノリシックコインプログラムの組み合わせを調整することで構築できます。
COIN program instance:
コインプログラムインスタンス：
one running instance of a program.
プログラムの1つの実行インスタンス。
COIN experience:
コインエクスペリエンス：
a new user experience brought about through the utilization of COIN capabilities.
コイン能力の利用を通じてもたらされた新しいユーザーエクスペリエンス。
This scenario can be exemplified in an immersive gaming application, where a single user plays a game using a Virtual Reality (VR) headset. The headset hosts several COIN programs. For instance, the display COIN program renders frames to the user, while other programs are realized for VR content processing and to incorporate input data received from sensors (e.g., in bodily worn devices including the VR headset).
このシナリオは、没入型ゲームアプリケーションで例示される可能性があります。このアプリケーションでは、1人のユーザーが仮想現実（VR）ヘッドセットを使用してゲームをプレイします。ヘッドセットには、いくつかのコインプログラムがホストされています。たとえば、ディスプレイコインプログラムはユーザーにフレームをレンダリングしますが、他のプログラムはVRコンテンツ処理やセンサーから受信した入力データを組み込んで実現します（たとえば、VRヘッドセットを含む身体摩耗デバイス）。
Once this application is partitioned into its constituent COIN programs and deployed throughout a COIN system utilizing a COIN execution environment, only the display COIN program may be left in the headset. Meanwhile, the CPU-intensive real-time VR content processing COIN program can be offloaded to a nearby resource rich home PC or a Programmable Network Device (PND) in the operator's access network for a better execution (i.e., faster and possibly higher resolution generation).
このアプリケーションが構成要素コインプログラムに分割され、コイン実行環境を使用してコインシステム全体に展開されると、ディスプレイコインプログラムのみがヘッドセットに残されます。一方、CPU集約型のリアルタイムVRコンテンツ処理コインプログラムは、オペレーターのアクセスネットワークで近くのリソースリッチホームPCまたはプログラム可能なネットワークデバイス（PND）にオフロードでき、より良い実行（つまり、より速く、おそらく高解像度の生成）があります。
Partitioning a mobile application into several constituent COIN programs allows for denoting the application as a collection of COIN programs for a flexible composition and a distributed execution. In our example above, most capabilities of a mobile application can be categorized into any of three groups: receiving, processing, and displaying.
モバイルアプリケーションをいくつかの構成要素コインプログラムに分割すると、柔軟な構成と分散実行のためのコインプログラムのコレクションとしてアプリケーションを示すことができます。上記の例では、モバイルアプリケーションのほとんどの機能を、受信、処理、表示の3つのグループのいずれかに分類できます。
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 commonly see with applications running on mobile devices.
任意のデバイスは、モバイルアプリケーションの1つ以上のコインプログラムを実現し、それらをコインシステムとその構成コイン実行環境にさらします。コインプログラムシーケンスが単一のデバイスで実行される場合、結果はモバイルデバイスで実行されているアプリケーションで一般的に表示されるものです。
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, in that it offers the possible reduction of power consumption (e.g., offloading CPU-intensive process functions to a remote server) or an 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.
ただし、コインプログラムの実行は、PNDを含む他の（例えば、より適切な）デバイスに移動する場合があります。その結果、モバイル機能のオフロードに相当します。これは、消費電力の削減（例：CPU集約型プロセス機能をリモートサーバーにロードする）または改善されたエンドユーザーエクスペリエンス（例えば、ディスプレイ機能を近くのスマートテレビに移動する）を選択することで、より適切に配置されたCoinプログラムインスタンスを選択することにより、Coinシステム全体に適しています。
We can already see a trend toward supporting such functionality that relies on dedicated cloud hardware (e.g., gaming platforms rendering content externally). We envision, however, that such functionality is becoming more pervasive through specific facilities, such as entertainment parks or even hotels, in order to deploy needed edge computing capabilities to enable localized gaming as well as non-gaming scenarios.
専用のクラウドハードウェア（たとえば、コンテンツを外部からレンダリングするゲームプラットフォームなど）に依存するこのような機能をサポートする傾向をすでに確認できます。ただし、必要なエッジコンピューティング機能を展開してローカライズされたゲームや非ゲーミングシナリオを有効にするために、エンターテインメントパークやホテルなどの特定の施設を通じて、このような機能がより広くなっていることを想定しています。
Figure 1 shows one realization of the above scenario, where a "DPR app" is running on a mobile device (containing the partitioned COIN programs Display (D), Process (P) and Receive (R)) over a programmable switching network, e.g., a Software-Defined Network (SDN) here. 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 (here, a "processing server").
図1は、上記のシナリオの1つの実現を示しています。「DPRアプリ」がモバイルデバイスで実行されています（プログラム可能なスイッチングネットワーク、たとえばソフトウェア定義ネットワーク（SDN）を介して、モバイルデバイス（パーティション化されたコインプログラムディスプレイ（D）、プロセス（P）、および受信（R）を含む）を示しています。パッケージ化されたアプリケーションは、ローカライズされた「Playstoreサーバー」を介して利用可能になります。モバイルアプリケーションのインストールは、ローカルアプリのインストールと、最も適切なエンドシステムまたはPNDS（ここでは「処理サーバー」）の1つ以上のコインプログラムの分散展開（およびオーケストレーション）を組み合わせたサービス展開プロセスとして実現されます。
+----------+ 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 +---------+
Figure 1: Application Function Offloading Example
図1：アプリケーション機能オフロードの例
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.
このようなローカライズされた展開は、たとえば、ホテルやテーマパークなどの訪問サイトによって提供される可能性があります。処理コインプログラムがモバイルデバイスで終了すると、ネットワークルート（サービス）の「サービスルーティング（SR）」要素は、代わりに既存のSDNネットワークを介して処理サーバーで実行されている（以前に展開された）処理コインプログラムにリクエストします。ここでは、適切なコインプログラムを選択するための機能とその他の制約は、複数のコインプログラムを展開した場合に、コインプログラムの広告とサービスリクエスト自体の両方で提供される場合があります。
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- and many-viewing scenarios). Here, an offloaded processing program may collate input from several users in the (virtual) environment to generate a possibly three-dimensional render that is then distributed via a service-level multicast capability towards more than one display COIN program.
上記のシナリオの拡張として、1つの処理コインプログラムのコンテンツが複数のディスプレイコインプログラムに配布されることを想定することもできます（たとえば、マルチビューおよび多くの視聴シナリオなど）。ここで、オフロードされた処理プログラムは、（仮想）環境の複数のユーザーからの入力を照合して、おそらく3次元レンダリングを生成し、その後、サービスレベルのマルチキャスト機能を介して複数のディスプレイコインプログラムに分布します。
The ETSI Multi-access 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.
ETSI Multi-Access Edge Computing（MEC）[ETSI]スイートのテクノロジーは、モバイルアプリケーションがモバイルデバイスの代わりに機能を実行するエッジデバイスのリソースを選択できるようにすることにより、モバイル機能オフロードのソリューションを提供します。このために、ETSI MECは、いわゆるMECアプリケーションサーバーに接続する適切なエッジリソースを選択するために、一連のインターフェイスを使用し、アプリケーションサーバーに関数実行のデータを送信することもできます。
However, the technologies do not utilize microservices [Microservices]; they mainly rely on virtualization approaches such as containers or virtual machines, thus requiring a heavier processing and memory footprint in a COIN execution environment and the executing intermediaries. Also, the ETSI work does not allow for the dynamic selection and redirection of COIN program calls to varying edge resources; it does allow for them to a single MEC application server.
ただし、テクノロジーはマイクロサービス[マイクロサービス]を使用していません。それらは主にコンテナや仮想マシンなどの仮想化アプローチに依存しているため、コインの実行環境と実行中の仲介者に重い処理とメモリフットプリントが必要です。また、ETSI作業では、さまざまなエッジリソースへのコインプログラムコールの動的な選択とリダイレクトを許可していません。単一のMECアプリケーションサーバーに許可します。
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 a few milliseconds for aligning with the frame rate of the display microservice.
また、Edgeリソース（APPサーバー）の選択は比較的静的であり、DNSベースのエンドポイント選択に依存しています。これは、別のデバイスにリダイレクトするための遅延がディスプレイマイクロセルサービスのフレームレートに署名するために数ミリ秒以内にある上記の例の要件に対応していません。
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 microservices in end-user devices.
最後に、MECアプリケーションサーバーは通常、MECインフラストラクチャを通じてネットワークオペレーターが提供するリソースと見なされますが、ここでのユースケースは、エンドユーザーデバイスでのマイクロサービスの配置と実行も予見しています。
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.
また、独自のプラットフォームを通じて提供されるモバイルオフロードプラットフォームの多数のモバイルオフロードプラットフォームも存在します。これらはすべて、選択されたエッジアプリケーションサーバーが機能的な説明と実行のためのデータを送信するために使用されているという点で、ETSI MECと同様のアプローチに従います。
[APPCENTRES] outlines a number of enabling technologies for the use case, some of which have been realized in an Android-based realization of the microservices as a single application, which is capable of dynamically redirecting traffic to other microservice 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).
[Appcentres]は、ユースケースの多くの有効化テクノロジーの概要を説明します。その一部は、ネットワーク内の他のマイクロサービスインスタンスへのトラフィックを動的にリダイレクトすることができる単一のアプリケーションとしてのAndroidベースのMicroservicesの実現で実現されています。この機能は、基礎となるパスベースの転送機能（SDNを使用）とともに、公に実証されました（例：Mobile World Congress 2018および2019で）。
* 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.
* 特定のエンドシステムとPNDの同様にコインプログラムインスタンスを展開するためのオーケストレーションは、ホテルや会場の所有者などのローカライズされたインフラオーナーが訪問者にコンピューティング機能を提供して、サイト固有の体験のために訪問者にコンピューティング機能を提供する可能性を開く可能性があります。
* 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 that may reside better located in relation to other COIN programs and thus improve performance, such as latency.
* （現在のモバイル）アプリレベルのコインプログラムの実行は、他のコインプログラムに関連してよりよく存在し、潜伏などのパフォーマンスを改善する可能性のあるPNDを含む、より適切なデバイスに実行を再配置することにより、上記のコインプログラムの実行をスピードアップする可能性があります。
* The support for service-level routing of requests (such as 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). Here, PNDs may support service routing solutions by acting as routing overlay nodes to implement the necessary additional lookup functionality and also possibly support the handling of affinity relations (i.e., the forwarding of one packet to the destination of a previous one due to a higher level service relation as discussed and described in [SarNet2021]).
* リクエストのサービスレベルのルーティングのサポート（[Appcentres]のサービスルーティングなど）は、あるCoinプログラムインスタンスから別のインスタンスに切り替える際の柔軟性を高めることができます（たとえば、新しいCoinプログラムインスタンスを選択するための制約の変更により）。ここでは、PNDは、必要な追加ルックアップ機能を実装するためにルーティングオーバーレイノードとして機能することにより、サービスルーティングソリューションをサポートし、おそらくアフィニティ関係の処理をサポートします（つまり、[SARNET2021]で説明および説明されているレベルのサービス関係により、以前のパケットの宛先への転送をサポートします。
* The ability to identify service-level COIN elements will allow for routing service requests to those COIN elements, including PNDs, therefore possibly allowing for a new COIN functionality to be included in the mobile application.
* サービスレベルのコイン要素を識別する機能により、PNDを含むコイン要素へのサービスリクエストをルーティングできるため、新しいコイン機能をモバイルアプリケーションに含める可能性があります。
* The support for constraint-based selection of a specific COIN program instance over others (e.g., constraint-based routing in [APPCENTRES], showcased for PNDs in [SarNet2021]) 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.
* 他のコインプログラムインスタンスの制約ベースの選択のサポート（[sarnet2021]のPNDについて紹介された[appcentres]の制約ベースのルーティングなど）は、コインプログラムインスタンスのより柔軟でアプリ固有の選択を可能にする可能性があり、アプリ固有およびエンドユーザーの要件をより適切に満たすことができます。
* RQ 3.1.1: How to combine service-level orchestration frameworks, such as TOSCA orchestration templates [TOSCA], with app-level (e.g., mobile application) packaging methods, ultimately providing the means for packaging microservices for deployments in distributed networked computing environments?
* RQ 3.1.1：TOSCAオーケストレーションテンプレート[TOSCA]などのサービスレベルのオーケストレーションフレームワークを組み合わせて、アプリレベル（モバイルアプリケーション）パッケージメソッドを組み合わせて、最終的には分布ネットワークコンピューティング環境での展開のためのマイクロサービスの手段を提供しますか？
* RQ 3.1.2: How to reduce latencies involved in COIN program interactions where COIN program instance locations may change quickly? Can service-level requests be routed directly through in-band signaling methods instead of relying on out-of-band discovery, such as through the DNS?
* RQ 3.1.2：コインプログラムインスタンスの場所が急速に変化する可能性のあるコインプログラムの相互作用に伴うレイテンシーを減らす方法は？DNSを介して帯域外の発見に依存する代わりに、サービスレベルのリクエストを帯域内のシグナルメソッドを通じて直接ルーティングできますか？
* RQ 3.1.3: How to signal constraints used for routing requests towards COIN program instances in a scalable manner (i.e., for dynamically choosing the best possible service sequence of one or more COIN programs for a given application experience through chaining COIN program executions)?
* RQ 3.1.3：コインプログラムインスタンスへのルーティングリクエストに使用される制約をスケーラブルな方法で信号する方法（つまり、コインプログラムの実行を介して特定のアプリケーションエクスペリエンスのために1つ以上のコインプログラムの最良のサービスシーケンスを動的に選択するため）？
* RQ 3.1.4: How to identify COIN programs and program instances so as to allow routing (service) requests to specific instances of a given service?
* RQ 3.1.4：特定のサービスの特定のインスタンスへのルーティング（サービス）要求を許可するように、コインプログラムとプログラムインスタンスを識別する方法は？
* RQ 3.1.5: How to identify a specific choice of a COIN program instance over others, thus allowing pinning the execution of a service of a specific COIN program to a specific resource (i.e., a COIN program instance in the distributed environment)?
* RQ 3.1.5：他の人よりもコインプログラムインスタンスの特定の選択を識別する方法を特定する方法で、特定のリソース（つまり、分散環境のコインプログラムインスタンス）に特定のコインプログラムのサービスの実行をピン留めすることができますか？
* 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.6：Coinプログラムインスタンスに向けてサービス要求の親和性を提供する方法（つまり、特定のCoinプログラムインスタンスで確立されたはかない状態との長期トランザクション）？
* RQ 3.1.7: How to provide constraint-based routing decisions that can be realized at packet forwarding speed (e.g., using techniques explored in [SarNet2021] at the forwarding plane or using approaches like [Multi2020] for extended routing protocols)?
* RQ 3.1.7：パケット転送速度で実現できる制約ベースのルーティング決定を提供する方法（たとえば、転送面で[SARNET2021]で調査された手法を使用するか、拡張ルーティングプロトコルの[Multi2020]などのアプローチを使用する）？
* RQ 3.1.8: What COIN capabilities may support the execution of COIN programs and their instances?
* RQ 3.1.8：コインプログラムとそのインスタンスの実行をサポートするコイン機能は何ですか？
* RQ 3.1.9: How to ensure real-time synchronization and consistency of distributed application states among COIN program instances, in particular, when frequently changing the choice for a particular COIN program in terms of executing a service instance?
* RQ 3.1.9：特に、サービスインスタンスの実行に関して特定のコインプログラムの選択を頻繁に変更する場合、コインプログラムインスタンス間の分散アプリケーション状態のリアルタイムの同期と一貫性を確保する方法は？
Extended Reality (XR) encompasses VR, Augmented Reality (AR) and Mixed Reality (MR). It provides the basis for the metaverse and is the driver of a number of advances in interactive technologies. While initially associated with gaming and immersive entertainment, 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 multiparty interactions under strict delay requirements. As such, XR can benefit from a functional distribution that includes fog computing for local information processing, the edge for aggregation, and the cloud for image processing.
拡張現実（XR）には、VR、拡張現実（AR）、および複合現実（MR）が含まれます。それはメタバースの基礎を提供し、インタラクティブなテクノロジーの多くの進歩の推進力です。最初はゲームや没入型のエンターテイメントに関連していますが、アプリケーションには、リモート診断、メンテナンス、遠隔医療、製造とアセンブリ、インテリジェントな農業、スマートシティ、没入型の教室が含まれています。XRは、厳格な遅延要件の下でのインタラクティブなマルチパーティインタラクションのビデオと触覚を組み合わせたマルチソーセマルチステーションの問題の一例です。そのため、XRは、ローカル情報処理のFOGコンピューティング、集約のエッジ、画像処理のクラウドを含む機能的な分布の恩恵を受けることができます。
XR stands to benefit significantly from computing capabilities in the network. For example, XR applications can offload intensive processing tasks to edge servers, considerably reducing latency when compared to cloud-based applications and enhancing the overall user experience. More importantly, COIN can enable collaborative XR experiences, where multiple users interact in the same virtual space in real time, regardless of their physical locations, by allowing resource discovery and re-routing of XR streams. While not a feature of most XR implementations, this capability opens up new possibilities for remote collaboration, training, and entertainment. Furthermore, COIN can support dynamic content delivery, allowing XR applications to seamlessly adapt to changing environments and user interactions. Hence, the integration of computing capabilities into the network architecture enhances the scalability, flexibility, and performance of XR applications by supplying telemetry and advanced stream management, paving the way for more immersive and interactive experiences.
XRは、ネットワーク内のコンピューティング機能から大幅に利益を得ることができます。たとえば、XRアプリケーションは、集中的な処理タスクをエッジサーバーにオフロードし、クラウドベースのアプリケーションと比較してレイテンシを大幅に削減し、ユーザーエクスペリエンス全体を強化することができます。さらに重要なことに、コインは、リソースの発見とXRストリームの再ルーティングを可能にすることにより、物理的な場所に関係なく、複数のユーザーが同じ仮想空間でリアルタイムで相互作用する共同XRエクスペリエンスを可能にすることができます。ほとんどのXR実装の機能ではありませんが、この機能はリモートコラボレーション、トレーニング、エンターテイメントの新しい可能性を開きます。さらに、Coinは動的なコンテンツ配信をサポートでき、XRアプリケーションが変化する環境やユーザーインタラクションにシームレスに適応することができます。したがって、コンピューティング機能をネットワークアーキテクチャに統合すると、テレメトリと高度なストリーム管理に供給することにより、XRアプリケーションのスケーラビリティ、柔軟性、パフォーマンスが向上し、より没入型のインタラクティブな体験への道を開きます。
Indeed, XR applications require real-time interactivity for immersive and increasingly mobile applications with tactile and time-sensitive data. Because high bandwidth is needed for high resolution images and local rendering for 3D images and holograms, strictly relying on cloud-based architectures, even with headset processing, limits some of its potential benefits in the collaborative space. As a consequence, innovation is needed to unlock the full potential of XR.
実際、XRアプリケーションでは、触覚的で時間に敏感なデータを使用した没入型およびますますモバイルアプリケーションのために、リアルタイムのインタラクティブ性が必要です。高解像度の画像と3D画像とホログラムのローカルレンダリングには高い帯域幅が必要であるため、ヘッドセット処理であっても、クラウドベースのアーキテクチャに厳密に依存しているため、共同空間における潜在的な利点の一部が制限されます。結果として、XRの可能性を最大限に引き出すためには、イノベーションが必要です。
As mentioned above, XR experiences, especially those involving collaboration, are difficult to deliver with a client-server cloud-based solution. This is because they require a combination of multistream aggregation, 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. Hence, implementing such XR solutions necessitates substantial computational power and minimal latency, which, for now, has spurred the development of better headsets, rather than spurring networked or distributed solutions, as factors like distance from cloud servers and limited bandwidth can still significantly lower application responsiveness. Furthermore, when XR deals with sensitive information, XR applications must also provide a secure environment and ensure user privacy, which represent additional burdens for delay-sensitive applications. Additionally, the sheer amount of data needed for and generated by 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, in order to find the optimal caching and processing solution and ideally reduce the size of the data that needs transiting through the network. Other mechanisms, such as data filtering and reduction, and functional distribution and partitioning, are also needed to accommodate the low delay needs for the same applications.
上記のように、XRの経験、特にコラボレーションを含む経験は、クライアントサーバークラウドベースのソリューションで提供するのが困難です。これは、マルチストリーム集約、低遅延と遅延の変動、損失から回復する手段、ネットワークエッジのユーザーに可能な限り最適化されたキャッシュとレンダリングの組み合わせが必要なためです。したがって、このようなXRソリューションを実装するには、かなりの計算能力と最小限のレイテンシが必要です。これは、クラウドサーバーや限られた帯域幅からの距離などの要因が適用の応答性を大幅に低下させる可能性があるため、ネットワーク化または分布のソリューションに拍車をかけるのではなく、より良いヘッドセットの開発に拍車をかけています。さらに、XRが機密情報を扱う場合、XRアプリケーションは安全な環境を提供し、遅延に敏感なアプリケーションの追加の負担を表すユーザープライバシーを確保する必要があります。さらに、ビデオホログラフィなどのXRアプリケーションによって必要なデータの量と生成されたデータは、最適なキャッシュと処理ソリューションを見つけるために、最近のトレンド分析とメカニズム、および機械学習を使用できるデータ駆動型アプリケーションの領域にまったく配置し、ネットワークを介して通過する必要があるデータのサイズを理想的に削減します。データフィルタリングと削減、機能的な分布とパーティション化などの他のメカニズムも、同じアプリケーションの低い遅延ニーズに対応するために必要です。
With functional decomposition as the goal of a better XR experience, the elements involved in a COIN XR implementation include:
より良いXRエクスペリエンスの目標として機能的な分解があるため、コインXRの実装に関与する要素には次のものがあります。
* the XR application residing in the headset,
* ヘッドセットに存在するXRアプリケーション、
* edge federation services that allow local devices to communicate with one another directly,
* ローカルデバイスが互いに直接通信できるようにするエッジフェデレーションサービス、
* edge application servers that enable local processing but also intelligent stream aggregation to reduce bandwidth requirements,
* ローカル処理を可能にするエッジアプリケーションサーバーだけでなく、帯域幅要件を削減するインテリジェントなストリーム集約も可能です。
* edge data networks that allow precaching of information based on locality and usage,
* 局所性と使用に基づいて情報の浸しを可能にするエッジデータネットワーク、
* cloud-based services for image processing and application training, and
* 画像処理とアプリケーショントレーニングのためのクラウドベースのサービス、および
* intelligent 5G/6G core networks for managing advanced access services and providing performance data for XR stream management.
* 高度なアクセスサービスを管理し、XRストリーム管理のパフォーマンスデータを提供するためのインテリジェントな5G/6Gコアネットワーク。
These characteristics of XR paired with the capabilities of COIN make it likely that COIN can help to realize XR over networks for collaborative applications. In particular, COIN functions can enable the distribution of the service components across different nodes in the network. For example, data filtering, image rendering, and video processing leverage different hardware capabilities with combinations of CPUs and Graphics Processing Units (GPUs) at the network edge and in the fog, where the content is consumed. These 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, multivariate and heterogeneous resource allocation and goal optimization problems need to be solved, likely requiring advanced analysis and artificial 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.
XRのこれらの特性は、コインの機能と組み合わせて、コインが共同アプリケーションのネットワーク上のXRを実現するのに役立つ可能性があります。特に、コイン関数は、ネットワーク内の異なるノードにわたってサービスコンポーネントの分布を可能にすることができます。たとえば、データのフィルタリング、画像レンダリング、およびビデオ処理は、コンテンツが消費されるネットワークエッジと霧でのCPUとグラフィックプロセシングユニット（GPU）の組み合わせと、さまざまなハードウェア機能を活用します。これらは、XRの帯域幅の高い需要に対する可能な救済策を表しています。ネットワークノード全体の機械学習は、より適切なパスに分散することにより、データフローをより適切に管理できます。適切な品質の経験を提供するには、多変量および不均一なリソースの割り当てと目標の最適化の問題を解決する必要があり、おそらく高度な分析と人工知能が必要です。このドキュメントの目的のために、XRにコインを使用することは特定のプロトコルを意味するのではなく、サービスの展開を可能にするアーキテクチャをターゲットにすることに注意することが重要です。これに関連して、セクション3.1の場合と同様の考慮事項が適用されます。
The XR field has profited from extensive research in the past years in gaming, machine learning, network telemetry, high resolution imaging, smart cities, and the Internet of Things (IoT). Information-Centric Networking (ICN) (and related) approaches that combine publish-subscribe and distributed storage are also very suited for the multisource-multidestination applications of XR. New AR and VR headsets and glasses have continued to evolve towards autonomy with local computation capabilities, increasingly performing much of the processing that is needed to render and augment the local images. Mechanisms aimed at enhancing the computational and storage capacities of mobile devices could also improve XR capabilities, as they include discovering available servers within the environment and using them opportunistically to enhance the performance of interactive applications and distributed file systems.
XR分野は、過去数年間のゲーム、機械学習、ネットワークテレメトリ、高解像度イメージング、スマートシティ、モノのインターネット（IoT）の広範な研究から利益を得ています。パブリッシュサブスクライブと分散ストレージを組み合わせた情報中心のネットワーキング（ICN）（および関連する）アプローチは、XRのマルチスーラチェマルチステーションアプリケーションにも非常に適しています。新しいARおよびVRヘッドセットとメガネは、ローカル計算能力を使用して自律性に向かって進化し続けており、ローカル画像をレンダリングおよび増強するために必要な処理の多くをますます実行しています。モバイルデバイスの計算およびストレージ容量を強化することを目的としたメカニズムは、環境内で利用可能なサーバーを発見し、日和見的に使用してインタラクティブなアプリケーションと分散ファイルシステムのパフォーマンスを強化するため、XR機能を改善することもできます。
While there is still no specific COIN research in AR and VR, the need for network support is important to offload some of the computations related to movement, multiuser interactions, and networked applications, notably in gaming but also in health [NetworkedVR]. This new approach to networked AR and VR is exemplified in [eCAR] by using synchronized messaging at the edge to share the information that all users need to interact. In [CompNet2021] and [WirelessNet2024], the offloading uses Artificial Intelligence (AI) to assign the 5G resources necessary for the real-time interactions, and one could think that implementing this scheme on a PND is essentially a natural next step. Hence, as AR, VR, and XR are increasingly becoming more interactive, the efficiency needed to implement novel applications will require some form or another of edge-core implementation and COIN support.
ARおよびVRにはまだ特定のコインの研究はありませんが、ネットワークサポートの必要性は、運動、マルチユーザーの相互作用、ネットワーク化されたアプリケーションに関連する計算の一部をオフロードするために重要です。ネットワーク化されたARとVRに対するこの新しいアプローチは、すべてのユーザーが対話する必要がある情報を共有するために、エッジで同期されたメッセージングを使用することにより、[ECAR]で例証されます。[compnet2021]および[wirelessnet2024]では、オフロードは人工知能（AI）を使用してリアルタイムの相互作用に必要な5Gリソースを割り当て、PNDにこのスキームを実装することは本質的に自然な次のステップであると考えることができます。したがって、AR、VR、およびXRはますますインタラクティブになりつつあるように、新しいアプリケーションを実装するために必要な効率には、何らかの形または別のエッジコアの実装とコインサポートが必要になります。
In summary, some XR solutions exist, and headsets continue to evolve to what is now claimed to be spatial computing. Additionally, with recent work 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 do not take advantage of network capabilities. The information is rendered and displayed based on the local processing but does not readily discover the other elements in the vicinity or in the network that could improve its performance either locally, at the edge, or in the cloud. Yet, there are still very few interactive and immersive media applications over networks that allow for the federation of systems capabilities.
要約すると、いくつかのXRソリューションが存在し、ヘッドセットは現在空間コンピューティングであると主張されているものに進化し続けています。さらに、最近のメタバースに関する作業により、XRに関連する出版物の数が急増しました。ただし、このドキュメントの焦点であるネットワーキングの観点から、現在の展開はネットワーク機能を活用していません。情報はローカル処理に基づいてレンダリングおよび表示されますが、近くまたはネットワーク内の他の要素を容易に発見することはありません。しかし、ネットワークを介したインタラクティブで没入型のメディアアプリケーションは、システム能力の連合を可能にしています。
While delay is inherently related to information transmission, 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:
遅延は本質的に情報送信に関連していますが、コンピューターボードの類似性を継続して、計算とストレージだけでなくリソースの割り当ての点でコイン機能の一部を強調した場合、XRが利用できる機会がいくつかあります。
* Round trip time: 20 ms is usually cited as an upper limit for XR applications. Storage and preprocessing of scenes in local elements (including in the mobile network) could extend the reach of XR applications at least over the extended edge.
* 往復時間：20ミリ秒は通常、XRアプリケーションの上限として引用されます。ローカル要素（モバイルネットワークを含む）のシーンの保存と前処理は、少なくとも拡張エッジを超えてXRアプリケーションのリーチを拡張する可能性があります。
* Video transmission: The use of better transcoding, advanced context-based compression algorithms, prefetching and precaching, 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 related to caching and fetching but also context-based flow direction and aggregation.
* ビデオの送信：より良いトランスコーディング、高度なコンテキストベースの圧縮アルゴリズム、プリフェッチと前処理、およびムーブメント予測の使用はすべて、帯域幅の消費を削減するのに役立ちます。現在、これはローカル処理に限定されていますが、特にキャッシュとフェッチの一部であるため、コンテキストベースのフロー方向と集約に関連するように、これらの機能のいくつかをネットワークに押し上げるのはコインの領域の外側ではありません。
* Monitoring: Since bandwidth and data are fundamental to XR deployment, COIN functionality could help to better monitor and distribute the XR services over collaborating network elements to optimize end-to-end performance.
* 監視：帯域幅とデータはXR展開の基本であるため、コイン機能は、コラボレーションネットワーク要素よりもXRサービスをよりよく監視および配布して、エンドツーエンドのパフォーマンスを最適化するのに役立ちます。
* 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 AI in network management to learn about flows and adapt resources based on both data plane and control plane programmability can help the overall deployment of XR services.
* インテリジェントなネットワーク管理と構成：ネットワーク管理におけるAIへの移動フローについて学び、データプレーンとコントロールプレーンのプログラマ性の両方に基づいてリソースを適応させることで、XRサービスの全体的な展開に役立ちます。
* 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.1：現在のPNDは、複雑で動的なシーンレンダリングのメタデータ分析を含む、複雑なフィルタリング操作の実行に必要な速度を提供できますか？
* RQ 3.2.2: Where should PNDs equipped with these operations be located for optimal performance gains?
* RQ 3.2.2：これらの操作を装備したPNDは、最適なパフォーマンスの向上のためにどこに配置する必要がありますか？
* RQ 3.2.3: Can the use of distributed AI algorithms across both data center and edge computers be leveraged for creating optimal function allocation? Can the creation of semi-permanent datasets and analytics for usage trending and flow management result in better localization of XR functions?
* RQ 3.2.3：データセンターとエッジコンピューターの両方にわたって分散型AIアルゴリズムの使用を活用して、最適な関数割り当てを作成できますか？使用するトレンドおよびフロー管理のための半多数のデータセットと分析の作成により、XR関数のローカリゼーションが向上できますか？
* RQ 3.2.4: Can COIN improve the dynamic distribution of control, forwarding, and storage resources and related usage models in XR, such as to integrate local and fog caching with cloud-based pre-rendering? Could this jointly optimize COIN and higher layer protocols to reduce latency and, more generally, manage the quality of XR sessions (e.g., through reduced in-network congestion and improved flow delivery by determining how to prioritize XR data)?
* RQ 3.2.4：Coinは、ローカルおよびフォグのキャッシュをクラウドベースのプレレンダリングと統合するなど、XRの制御、転送、ストレージリソース、および関連する使用モデルの動的分布を改善できますか？これにより、これはコインと高層プロトコルを共同で最適化してレイテンシを減らし、より一般的にはXRセッションの品質を管理できますか（たとえば、XRデータの優先順位付け方法を決定することでネットワークの混雑を減らし、フロー配信を改善することで）。
* RQ 3.2.5: Can COIN provide the necessary infrastructure for the use of interactive XR everywhere? Particularly, how can a COIN system enable the joint collaboration across all segments of the network (fog, edge, core, and cloud) to support functional decompositions, including using edge resources without the need for a (remote) cloud connection?
* RQ 3.2.5：Coinは、どこでもインタラクティブなXRを使用するために必要なインフラストラクチャを提供できますか？特に、コインシステムは、ネットワークのすべてのセグメント（Fog、Edge、Core、およびCloud）の共同コラボレーションをどのようにして、（リモート）クラウド接続を必要としないエッジリソースを使用するなど、機能的な分解をサポートできるようにすることができますか？
* RQ 3.2.6: How can COIN systems provide multistream efficient transmission and stream combining at the edge, including the ability to dynamically include extra streams, such as audio and extra video tracks?
* RQ 3.2.6：コインシステムは、オーディオや追加のビデオトラックなどの余分なストリームを動的に含める機能を含め、エッジでのマルチストリーム効率的なトランスミッションとストリームをどのように提供できますか？
In addition to the capabilities driven by the research questions above, there are a number of other features that solutions in this space might benefit from. In particular, the provided XR experience should be optimized both in the amount of transmitted data, while equally optimizing loss protection. Furthermore, the means for trend analysis and telemetry to measure performance may foster uptake of the XR services, while the interaction of the XR system with indoor and outdoor positioning systems may improve on service experience and user perception.
上記の研究の質問によって駆動される機能に加えて、この分野の解決策が恩恵を受ける可能性のある他の多くの機能があります。特に、提供されたXRエクスペリエンスは、送信されたデータの量の両方で最適化する必要がありますが、損失保護を等しく最適化する必要があります。さらに、パフォーマンスを測定するトレンド分析とテレメトリの手段はXRサービスの取り込みを促進する可能性があり、XRシステムと屋内および屋外のポジショニングシステムとの相互作用により、サービスエクスペリエンスとユーザー認識が向上する可能性があります。
This use case is a deeper dive into a specific scenario of the immersive and extended reality class of use cases discussed in Section 3.2. It focuses on live productions of the performing arts where the performers and audience members are geographically distributed. The performance is conveyed through multiple networked streams, which are tailored to the requirements of the remote performers, the director, the sound and lighting technicians, and the individual audience members. Performers need to observe, interact, and synchronize with other performers in remote locations, and the performers receive live feedback from the audience, which may also be conveyed to other audience members.
このユースケースは、セクション3.2で説明されているユースケースの没入型および拡張された現実のクラスクラスの特定のシナリオに深く掘り下げられています。パフォーマーと聴衆が地理的に配布されている舞台芸術のライブプロダクションに焦点を当てています。このパフォーマンスは、リモートパフォーマー、ディレクター、サウンドおよび照明技術者、および個々の聴衆の要件に合わせて調整された複数のネットワーク化されたストリームを通じて伝えられます。パフォーマーは、遠隔地の他のパフォーマーと観察、対話、同期する必要があり、パフォーマーは聴衆からライブフィードバックを受け取ります。これは、他の聴衆にも伝えることができます。
There are two main aspects:
主に2つの側面があります。
i. to emulate as closely as possible the experience of live performances where the performers, audience, director, and technicians are co-located in the same physical space, such as a theater; and
i. パフォーマー、聴衆、監督、および技術者が劇場などの同じ物理的な空間で共同住宅されているライブパフォーマンスの経験を、できるだけ密接にエミュレートするため。そして
ii. to enhance conventional physical performances with features such as personalization of the experience according to the preferences or needs of the performers, directors, and audience members.
ii。パフォーマー、ディレクター、聴衆の好みやニーズに応じたエクスペリエンスのパーソナライズなどの機能を備えた従来の物理的パフォーマンスを強化するため。
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 conventional seating (i.e., amongst, above, or behind the performers, but within some limits that 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 and product placement, and other enhancements and filters to make the performance accessible to audience members who are disabled (e.g., the removal of flashing images for audience members who have epilepsy or alternative color schemes for those who have color blindness).
* 字幕、オーディオの説明、俳優のタグ付け、言語翻訳、広告、製品の配置、その他の拡張機能とフィルターによるパフォーマンスの増強は、障害のある視聴者がパフォーマンスにアクセスできるようにします（たとえば、色覚異常のある人のためのてんかんまたは代替の配色を持っている視聴者のための点滅画像の削除）。
There are several chained functional entities that 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, remote performer, or member of the production team
- 既存のストリームを視聴者、リモートパフォーマー、または制作チームのメンバーに転送するかを選択するには
- 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 an audience member's chosen perspective)
- 既存のストリームを処理した後に新しいストリームを作成するには（たとえば、カメラアングル間を補間して新しい視点を作成したり、視聴者の選択した視点からポイントクラウドをレンダリングするため）
- to undertake remote rendering according to viewer position (e.g., the 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 due to limited network bandwidth to receive all of the individual streams to be processed.
- この処理が視聴者の最終システムからコイン機能にオフロードされた場合、またはエンドシステムの処理能力が限られているため、またはプロセスの個々のストリームをすべて受信するためにこの処理がコイン機能にオフロードされた場合、視聴者の位置（たとえば、視聴者ヘッドの位置に応じてVRヘッドセットディスプレイストリームの作成）に従ってリモートレンダリングを引き受けるため。
* 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:
これらは、いくつかの理由で、エンドシステム（パフォーマーのサイト、聴衆の施設、または中央クラウドの場所）にあるのではなく、PNDのコインプログラムとしての展開候補です。
* Personalization of the performance according to viewer preferences and requirements makes it infeasible 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 personalized streams.
* 視聴者の好みと要件に応じたパフォーマンスのパーソナライズにより、パフォーマーの施設で集中化された方法で行うことは実行不可能です。計算リソースとネットワーク帯域幅は、パーソナライズされたストリームの数でスケーリングする必要があります。
* Rendering of VR headset content to follow viewer head movements has an upper bound on lag to maintain viewer Quality of Experience (QoE), which requires the processing to be undertaken sufficiently close to the viewer to avoid large network latencies.
* VRヘッドセットコンテンツのレンダリングビューアーヘッドの動きには、視聴者のエクスペリエンス（QOE）を維持するためのLAGの上限があります。
* Viewer devices may not have the processing power to perform the personalization tasks, 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 between performers and audience members to be minimized, which reduces the opportunity to route streams via large-scale processing capabilities at centralized data centers.
* パフォーマーとオーディエンスメンバーの間の直接ネットワークパスからの逸脱を最小限に抑える必要があるライブおよびインタラクティブな側面には、厳格な潜在的要件があり、集中データセンターで大規模な処理機能を介してストリームをルーティングする機会を減らします。
Note: Existing solutions for some aspects of this use case are covered in Section 3.1, Section 3.2, and Section 5.1.
注：このユースケースのいくつかの側面の既存のソリューションについては、セクション3.1、セクション3.2、およびセクション5.1で説明しています。
* 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).
* PNDのコインプログラムとして、メディア処理とパーソナライズ機能を実行すると、パスでパスで機能することで、中央サーバーへの迂回/ストレッチを避けることができ、潜伏率と帯域幅の消費が削減されます。たとえば、パフォーマンスキャプチャ、集約、分布、パーソナライズ、消費、視聴者の応答のキャプチャ、フィードバック処理、集約、およびレンダリングの全体的な遅延は、潜時の上限内で達成する必要があります（許容できる量は定義されますが、MSの順序で、演劇や他の感情的な応答など、視聴者のフィードバックを模倣するパフォーマンスを模倣します）。
* 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, multiflow coordination, synchronization, and resilience).
* メディアストリームの処理により、コインプログラム、PND、およびより広いコインシステム/環境が、フローとその要件をコンテキスト的に認識できます。これは、フローのネットワーク処理（パス選択、優先順位付け、マルチフロー調整、同期、および復元）を決定するために使用できます。
* 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 viewers?
* RQ 3.3.1：集約、エンコーディング、およびパーソナライズ機能のためのプログラムをどのPNDに導入する必要がありますか？パフォーマーの近く、または視聴者の近くに？
* RQ 3.3.2: How far from the direct network path from performer to viewer 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.2：パスストレッチの遅延への影響とPNDでの処理能力の可用性を考慮して、パフォーマーから視聴者への直接ネットワークパスから視聴者への距離を配置する必要がありますか？ユーザーは寛容をどのように定義する必要がありますか？
* 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 a COIN system? In case of the latter, how can users specify requirements on network and processing metrics (such as latency and throughput bounds)?
* RQ 3.3.3：ユーザーは、フローのコインプログラムを実行するためにどのPNDを使用するかを決定すべきか、またはコインシステムのオーケストレーター/マネージャーによる決定を直接決定する要件と制約を表明する必要がありますか？後者の場合、ユーザーはネットワークおよび処理メトリック（レイテンシやスループットの境界など）に要件をどのように指定できますか？
* 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:
* RQ 3.3.4：マージ、オーディオビデオ補間、および出力の整合性のために時間同期を必要とする他のクロスストリーム処理機能を可能にするために、複数のストリーム間で同期を実現する方法は？次のフロー間で同期が必要になる可能性があることを考慮して、これを達成するにはどうすればよいですか。
i. on the same data pathway through a PND/router,
i. PND/ルーターを通る同じデータ経路で、
ii. arriving/leaving through different ingress/egress interfaces of the same PND/router, or
ii。同じPND/ルーターの異なる入り込み/出口界面を介して到着/出発、または
iii. routed through disjoint paths through different PNDs/ routers?
iii。さまざまなPND/ルーターを介して隔離されたパスを介してルーティングされましたか？
This RQ raises issues associated with synchronization across multiple media streams and substreams [RFC7272] as well as time synchronization between PNDs/routers on multiple paths [RFC8039].
これにより、複数のメディアストリームとサブストリーム[RFC7272]の同期に関連する問題、および複数のパス上のPND/ルーター間の時間同期[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.5：コインプログラムはどこで実行されますか？PNDのデータプレーンでは、PND内の他のルーター上の計算機能、または隣接する計算ノード？
* 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.6：ビデオステッチやメディア認識や注釈などの計算集中的なタスク（セクション3.2を参照）は、適切な候補コインプログラムと見なされますか、それとも最終システムに実装されるべきですか？
* 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 end systems?
* RQ 3.3.7：Coinプログラムの実行がPNDS（GPUによる処理など）外側の計算ノードにオフロードされている場合、これはまだコインと見なされるべきですか？コイン能力とエンドシステムへのフローの明示的なルーティングとの境界はどこにありますか？
In addition to the capabilities driven by the research questions above, there are a number of other features that solutions in this space might benefit from. In particular, if users are indeed empowered to specify requirements on network and processing metrics, one important capability of COIN systems will be to respect these user-specified requirements and constraints when routing flows and selecting PNDs for executing COIN programs. Similarly, solutions should be able to synchronize flow treatment and processing across multiple related flows, which may be on disjoint paths, to provide similar performance to different entities.
上記の研究の質問によって駆動される機能に加えて、この分野の解決策が恩恵を受ける可能性のある他の多くの機能があります。特に、ユーザーが実際にネットワークおよび処理メトリックに要件を指定する権限を与えられている場合、コインシステムの重要な機能の1つは、フローをルーティングし、コインプログラムを実行するためのPNDを選択する際に、これらのユーザー指定の要件と制約を尊重することです。同様に、ソリューションは、異なるエンティティに同様のパフォーマンスを提供するために、分離パス上にある可能性のある複数の関連するフロー全体でフロー処理と処理を同期できるはずです。
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. Commonly, 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 a few controlled components.
工業生産ラインの物理的プロセスとコンポーネントの制御は、生産の自動化の成長に不可欠であり、理想的には一貫した品質レベルを可能にします。一般的に、制御されたプロセスまたはコンポーネントのすぐ隣にあるプログラム可能なロジックコントローラー（PLC）で実行されている制御ソフトウェアによって制御が行使されています。このアプローチは、単一またはいくつかの制御されたコンポーネントに焦点を当てた単純なモデルを備えた設定に最適です。
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 preprocessed or aggregated with other information before it can be used. As a result, computations are increasingly spatially decoupled and moved away from the controlled objects, thus inducing additional latency. Instead, 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.
最新の生産ラインとショップフロアは、関与するデバイスとセンサーの数が増えていること、異なるコンポーネント間の依存レベルの増加、およびより複雑な制御モデルによって特徴付けられます。中央のコントロールは、利用可能な大量の利用可能な情報を管理するために望ましいです。これは、使用する前に他の情報を前処理または集約する必要があることがよくあります。その結果、計算はますます空間的に分離され、制御されたオブジェクトから離れて移動するため、追加のレイテンシが誘導されます。代わりに、コンピューティング機能をネットワーク内のコイン実行環境に移動すると、これらの課題に新しいソリューションスペースが提供され、はるかに小さなレイテンシを備えた新しいコンピューティングロケーションが提供されます。
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.
制御プロセスは、図2に示す2つの主要なコンポーネントで構成されています。制御下のシステムとコントローラー。フィードバック制御では、システムの現在の状態が監視され（センサーを使用するなど）、コントローラーは、電流と参照状態の違いに基づいてシステムに影響し、この参照状態に近づきます。
reference
state ------------ -------- Output
----------> | Controller | ---> | System | ---------->
^ ------------ -------- |
| |
| observed state |
| --------- |
-------------------| Sensors | <-----
---------
Figure 2: Simple Feedback Control Model
図2：単純なフィードバック制御モデル
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. Even shorter feedback requirements may exist in other use cases, such as interferometry or high-energy physics, but these use cases are out of scope for this document. 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, for example, off-premise cloud platforms are included.
制御モデルとは別に、コントロールの品質は、主にセンサーフィードバックのタイムリーな受信に依存します。センサーフィードバックは、多くの場合、1桁のミリ秒範囲で緊密なレイテンシの制約を受ける可能性があります。干渉法や高エネルギー物理学など、他のユースケースにはより短いフィードバック要件が存在する可能性がありますが、これらのユースケースはこのドキュメントの範囲外です。低レイテンシは不可欠ですが、コントローラーが一般的に設計されている場合は異なるレベルのレベルに対処できるため、安定した決定論的レベルのレイテンシーがさらに必要になりますが、動的に変化するまたは不安定なレイテンシによって大幅に課題があります。インターネットの予測不可能なレイテンシは、たとえばオフプレミスクラウドプラットフォームが含まれている場合、この問題を例示しています。
Control functionality is commonly 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.
制御機能は、一般に機械に近いPLCで実行されます。これらのPLCは通常、ベンダー固有の実装を必要とし、多くの場合、アップグレードと更新が困難であるため、そのような制御プロセスの柔軟性があり、管理が困難になります。したがって、計算をより自由にプログラム可能なデバイスに移動すると、柔軟性が大幅に向上する可能性があります。これに関連して、コントロール機能を（中央）クラウド環境に直接移動することは一般的に可能ですが、レイテンシの制約が寛容である場合にのみ実現可能です。
Early approaches such as [RÜTH] and [VESTIN] have already shown the general applicability of leveraging COIN for in-network control.
[Rüth]や[Vestin]などの初期のアプローチでは、ネットワーク内制御のためにコインを活用する一般的な適用性がすでに示されています。
* 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.
* PNDおよび/またはコインの実行環境で簡単な制御ロジックを実行すると、制御されたシステムとコントローラーがより密接になり、おそらく厳しい遅延要件が満たされる可能性があります。
* Creating a coupled control that is exercised via
* 介して行使される結合コントロールを作成します
i. simplified approximations of more complex control algorithms deployed in COIN execution environments, and
i. コイン実行環境に展開された、より複雑な制御アルゴリズムの簡略近似、および
ii. more complex overall control schemes deployed in the cloud
ii。クラウドに展開されたより複雑な全体的な制御スキーム
can allow for quicker, yet more inaccurate responses from within the network while still providing for sufficient control accuracy at higher latencies from afar.
ネットワーク内からのより迅速で不正確な応答を可能にしながら、遠くからより高いレイテンシで十分な制御精度を提供します。
* RQ 4.1.1: How to derive simplified versions of the global (control) function?
* RQ 4.1.1：グローバル（コントロール）関数の単純化されたバージョンを導き出す方法は？
* RQ 4.1.2: How to account for the limited computational precision of PNDs that typically only allow for integer precision computation for enabling high processing rates, while floating-point precision is needed by most control algorithms (cf. [KUNZE-APPLICABILITY])?
* RQ 4.1.2：通常、高処理速度を有効にするために整数精度計算を可能にするPNDの限られた計算精度を説明する方法は、ほとんどのコントロールアルゴリズムで必要です（[Kunze-Applicability]）？
* RQ 4.1.3: How to find suitable tradeoffs regarding simplicity of the control function ("accuracy of the control") and implementation complexity ("implementability")?
* RQ 4.1.3：制御関数の単純さ（「コントロールの精度」）と実装の複雑さ（「実装可能性」）に関する適切なトレードオフを見つける方法は？
* RQ 4.1.4: How to (dynamically) distribute simplified versions of the global (control) function among COIN execution environments?
* RQ 4.1.4：コイン実行環境の中でグローバル（コントロール）関数の単純化されたバージョンを（動的に）どのように配布するか？
* RQ 4.1.5: How to (dynamically) compose or recompose the distributed control functions?
* RQ 4.1.5：分散制御機能を（動的に）構成または再構成する方法
* RQ 4.1.6: Can there be different control levels? For example, "quite inaccurate & very low latency" for PNDs deep in the network; "more accurate & higher latency" for more powerful COIN execution environments that are farther away; and "very accurate & very high latency" for cloud environments that are far away.
* RQ 4.1.6：異なる制御レベルはありますか？たとえば、ネットワークの深いPNDの「非常に不正確で非常に低いレイテンシ」。遠く離れたより強力なコイン実行環境のための「より正確で高いレイテンシ」。そして、遠くにあるクラウド環境の「非常に正確で非常に高いレイテンシ」。
* RQ 4.1.7: Who decides which control instance is executed and which information can be used for this decision?
* RQ 4.1.7：この決定にどの制御インスタンスが実行され、どの情報を使用できるかを誰が決定しますか？
* RQ 4.1.8: How do the different control instances interact and how can we define their hierarchy?
* RQ 4.1.8：さまざまな制御インスタンスはどのように相互作用し、どのように階層を定義できますか？
In addition to the capabilities driven by the research questions above, there are a number of other features that approaches deploying control functionality in COIN execution environments could benefit from. For example, having an explicit interaction between the COIN execution environments and the global controller would ensure that it is always clear which entity is emitting which signals. In this context, it is also important that actions of COIN execution environments are overridable by the global controller such that the global controller has the final say in the process behavior. Finally, by accommodating the general characteristics of control approaches, functions in COIN execution environments should ideally expose reliable information on the predicted delay and must expose reliable information on the predicted accuracy to the global control such that these aspects can be accommodated in the overall control.
上記の研究の質問によって駆動される機能に加えて、コインの実行環境に制御機能を展開することに近づく他の多くの機能が恩恵を受ける可能性があります。たとえば、コインの実行環境とグローバルコントローラーの間に明示的な相互作用を持つことで、どのエンティティがどの信号を発しているかが常に明確になることが保証されます。これに関連して、グローバルコントローラーがプロセスの動作に最終決定権を持つように、コイン実行環境のアクションがグローバルコントローラーによって過剰に配置されることも重要です。最後に、制御アプローチの一般的な特性に対応することにより、コイン実行環境の関数は、予測される遅延に関する信頼できる情報を理想的に公開する必要があり、これらの側面が全体的なコントロールに対応できるように、予測された精度に関する信頼できる情報をグローバル制御に公開する必要があります。
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 such that frequently upgrading is not always feasible or possible. Hence, a major challenge is to devise a methodology that is able to handle such amounts of data efficiently and flexibly without relying on recurring infrastructure upgrades.
展開されたセンサーと観測されたシステムの複雑さに応じて、結果として得られる全体的なデータボリュームは、いくつかのGBIT/s [Glebke]の範囲に簡単になります。これらのボリュームは、ローカル環境ですでに処理するのがすでに難しいことが多く、データの管理にオフプレミスクラウドを使用するとさらに困難になります。大規模なネットワーキング企業は、インフラストラクチャをアップグレードして発生するデータ量に対応することができますが、ほとんどの産業企業は、頻繁にアップグレードが常に実行可能または可能であるとは限らないように、タイトなインフラストラクチャ予算で運営されています。したがって、主要な課題は、インフラストラクチャの繰り返しのアップグレードに依存することなく、このような量のデータを効率的かつ柔軟に処理できる方法論を考案することです。
Data filtering and preprocessing, 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 preprocessing 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 an additional auspicious field for research.
セクション3.2の考慮事項と同様に、データフィルタリングと前処理は、このスペースの新しいソリューションの構成要素の構成要素になります。ただし、このようなソリューションは、会社の敷地を離れて管理するビジネスデータの追加の課題に対処する必要がある場合もあります。このデータには機密情報や貴重なビジネスの秘密が含まれる可能性があるため、追加のセキュリティ対策を講じる必要があります。しかし、データを暗号化するなどの典型的なセキュリティ対策により、通常は暗号化されていないデータで動作するため、フィルタリングまたは前処理アプローチはほとんど適用できません。その結果、暗号化されたデータを処理するための機能を追加するか、一般的なセキュリティ対策を考案することにより、これらのアプローチにセキュリティを組み込むことは、研究のための追加の縁起の良い分野です。
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, parts 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 standard statistical sampling, packet-based sub-sampling (i.e., only forwarding every n-th packet), 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] and [TIRPITZ-REDUCIO]). While the former variants are 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.
センサーはしばしば冗長にセットアップされるため、収集されたデータの一部も冗長性がある場合があります。さらに、センサーは多くの場合、構成が困難であるか、まったく構成できないため、解像度またはサンプリング頻度が必要よりも大きいことがよくあります。したがって、必要または望ましいよりも多くのデータが送信され、フィルタリング技術の展開が促される可能性があります。たとえば、オンプレミスネットワークに展開されているコインプログラムは、単純なトラフィックフィルターを使用して前提を離れる前に冗長または望ましくないデータを除外する可能性があり、必要な（アップロード）帯域幅を削減します。使用可能なセンサーデータは、標準の統計サンプリング、パケットベースのサブサンプリング（つまり、すべてのn-thパケットのみを転送する）を使用して、またはセンサー値がより高い解像度の範囲が興味深いものになると、より高い解像度で転送されない限り、フィルタリングを使用してスケーリングできます（CF. [Kunze-signal]および[Tirpitz-Reducio]）。前者のバリアントはセンサーデータのセマンティクスを忘れていますが、後者のバリアントは現在のセンサーレベルを理解する必要があります。いずれにせよ、最終ホストにフィルタリングについて通知されることが重要です。そうすれば、データの損失と意図的にフィルタリングされたデータを区別できるようにします。
In practice, the collected data is further processed using various forms of computation. Some of them are very complex or need the complete sensor data during the computation, but there are also simpler operations that 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.
実際には、収集されたデータは、さまざまな形式の計算を使用してさらに処理されます。それらのいくつかは非常に複雑であるか、計算中に完全なセンサーデータを必要としますが、すべてのデータが利用可能になり次第、データセット全体のサブセットまたは通信パスで既に行うことができる簡単な操作もあります。1つの例は、すべてのセンサー値の最大値を見つけることです。これは、各中間ホップで、またはすべてのデータが利用可能な最初のホップで繰り返し実行できます。したがって、正確な計算ステップとセンサーデータのコンクリート送信パスに関する専門知識を使用して、オンプレミスネットワークに簡単な計算手順を展開し、データ全体を減らすことができます。
Current approaches for handling such large amounts of information typically build upon stream processing frameworks such as Apache Flink. These solutions allow for handling large-volume applications and map the compute functionality to performant server machines or distributed compute platforms. Augmenting the existing capabilities, COIN offers a new dimension of platforms for such processing frameworks.
このような大量の情報を処理するための現在のアプローチは、通常、Apache Flinkなどのストリーム処理フレームワークに基づいて構築されます。これらのソリューションにより、大量のアプリケーションを処理し、コンピューティング機能をパフォーマンスのあるサーバーマシンまたは分散コンピューティングプラットフォームにマッピングできます。既存の機能を拡張して、Coinは、このような処理フレームワークのためのプラットフォームの新しい次元を提供します。
* (Stream) processing frameworks can become more flexible by introducing COIN execution environments as additional deployment targets.
* （ストリーム）処理フレームワークは、追加の展開目標としてコインの実行環境を導入することにより、より柔軟になります。
* (Semantic) packet filtering based on packet header and payload, as well as multipacket information can (drastically) reduce the data volume, possibly even without losing any important information.
* （セマンティック）パケットヘッダーとペイロードに基づくパケットフィルタリング、およびマルチパケット情報は、重要な情報を失うことなく、データボリュームを（劇的に）減らすことができます。
* (Semantic) data preprocessing and 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.
* （セマンティック）データの前処理と処理（たとえば、複数のパケット間の計算の形式で、パケットペイロードを潜在的に活用する可能性がある）も、重要な情報を失うことなくデータのボリュームを減らすことができます。
Some of the following research questions are also relevant in the context of general stream processing systems.
以下の研究質問のいくつかは、一般的なストリーム処理システムのコンテキストでも関連しています。
* 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.1：データ処理パイプライン全体を個々の処理手順にどのように分割し、コイン機能として展開できますか？
* RQ 4.2.2: How to design COIN programs for (semantic) packet filtering and which filtering criteria make sense?
* RQ 4.2.2：（セマンティック）パケットフィルタリングのコインプログラムを設計する方法と、どのフィルタリング基準が理にかなっていますか？
* RQ 4.2.3: Which kinds of COIN programs can be leveraged for preprocessing and processing steps and what complexity can they have?
* RQ 4.2.3：どのような種類のコインプログラムを前処理と処理の手順に活用でき、どのような複雑さがありますか？
* RQ 4.2.4: How to distribute and coordinate COIN programs?
* RQ 4.2.4：コインプログラムを配布および調整する方法は？
* RQ 4.2.5: How to dynamically reconfigure and recompose COIN programs?
* RQ 4.2.5：コインプログラムを動的に再構成および再構成する方法は？
* RQ 4.2.6: How to incorporate the preprocessing, processing, and filtering steps into the overall system?
* RQ 4.2.6：システム全体に前処理、処理、およびフィルタリングを組み込む方法は？
* RQ 4.2.7: How can changes to the data by COIN programs be signaled to the end hosts?
* RQ 4.2.7：コインプログラムによるデータの変更を最終ホストにどのように通知できますか？
In addition to the capabilities driven by the research questions above, there are a number of other features that such large-volume applications could benefit from. In particular, conforming to standard application-level syntax and semantics likely simplifies embedding filters and preprocessors into the overall system. If these filters and preprocessors also leverage packet header and payload information for their operation, this could further improve the performance of any approach developed based on the above research questions.
上記の研究の質問によって駆動される機能に加えて、このような大量のアプリケーションが恩恵を受けることができる他の多くの機能があります。特に、標準のアプリケーションレベルの構文とセマンティクスに準拠することで、フィルターと前処理を埋め込むことで、システム全体に埋め込むことができます。これらのフィルターと前処理者がパケットヘッダーとペイロード情報を活用のために活用する場合、これにより、上記の研究質問に基づいて開発されたあらゆるアプローチのパフォーマンスがさらに向上する可能性があります。
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 conventional 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 directly assist humans, perform tasks autonomously, or even freely move around on the shop floor. Hence, 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.
現代の工場は、人間とロボットの間の新しい相互作用シナリオを備えたますます動的で複雑な環境によって特徴付けられています。ロボットは、人間を直接支援したり、タスクを自律的に実行したり、現場で自由に動き回ったりすることさえできます。したがって、人間の労働領域とロボットの間の交差は成長し、人間の労働者が完全な環境を完全に観察することは困難です。事故を防ぎ、環境を観察する人間を支援するためには、追加の安全対策が不可欠です。
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. For example, markings on the factory floor can show the areas where robots move or indicate their maximum physical reach.
産業安全対策は、通常、ハードウェアソリューションです。これは、認定され、展開準備が整う前に厳格なテストに合格する必要があるためです。標準的な測定には、安全スイッチと軽い障壁が含まれます。さらに、作業エリアは、「接触」と「安全な」エリアに明示的に分割でき、労働者が機械との相互作用に気をつけなければならないことを示します。たとえば、工場の床にあるマーキングは、ロボットが移動したり、最大の物理リーチを示したりするエリアを表示できます。
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 or where all entities are freely moving around. 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. Finally, the increasing softwarization of industrial processes can also lead to new problems, e.g., if software bugs cause unintended movements of robots. Here, COIN systems could independently double check issued commands to void unsafe commands.
これらの手段は静的なソリューションであり、特殊なハードウェアに依存する可能性があり、工場構成をオンデマンドで変更できる最新の工場のダイナミクスの増加や、すべてのエンティティが自由に動き回っていることに挑戦されています。ソフトウェアソリューションは、センサーシステムによって収集された新しい情報を動的に尊重できるため、より高い柔軟性を提供しますが、ほとんどの場合、保証された安全性を与えることはできません。コインシステムは、センサーデータの可用性の向上と工場の詳細な監視を活用して、応答時間が短く、保証が高いための追加の安全対策を可能にすることができます。制作ホール内のさまざまな安全指標をネットワーク内に組み合わせることができ、潜在的な安全侵害が検出された場合にPNDが早期に応答できるようにすることができます。たとえば、人間の労働者とロボットの位置を追跡することができ、ロボットが非労働エリアで人間に近づきすぎたり、人間が定義された安全ゾーンに入ったりすると停止することができます。より高度な概念には、画像データが含まれたり、任意のセンサーデータを組み合わせることもできます。最後に、産業プロセスのソフトウェア化の増加は、たとえば、ソフトウェアのバグがロボットの意図しない動きを引き起こす場合、新しい問題にもつながる可能性があります。ここでは、コインシステムは、無効なコマンドに発行されたコマンドを独立して再確認できます。
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.
安全性の重要性があるため、セキュリティの強化を目的としたソフトウェアベースのアプローチが幅広くあります。1つの例は、タグベースのシステム（RFIDを使用するなど）です。ここでは、タグを運ぶ歩行者の労働者が近くにいる場合、フォークリフトのドライバーが警告できます。ただし、このようなソリューションでは、追加のシステムを設定する必要があり、既存のセンサーデータを活用しません。
* Executing safety-critical COIN functions on PNDs could allow for early emergency reactions based on diverse sensor feedback with low latencies.
* PNDで安全性が批判的なコイン機能を実行すると、低レイテンシの多様なセンサーフィードバックに基づいて早期の緊急反応が可能になります。
* COIN software could provide independent on-path surveillance of control software-initiated actions to block unsafe commands.
* Coinソフトウェアは、安全でないコマンドをブロックするために、制御ソフトウェアによって開始されたアクションの独立したオンパス監視を提供できます。
* RQ 4.3.1: Which additional safety measures can be provided and do they actually improve safety?
* RQ 4.3.1：どの追加の安全対策を提供できるか、実際に安全性を向上させることができますか？
* RQ 4.3.2: Which sensor information can be combined and how?
* RQ 4.3.2：どのセンサー情報を組み合わせることができますか？
* RQ 4.3.3: How can COIN-based safety measures be integrated with existing safety measures without degrading safety?
* RQ 4.3.3：安全性を低下させることなく、コインベースの安全対策を既存の安全対策とどのように統合できますか？
* RQ 4.3.4: How can COIN software validate control software-initiated commands to prevent unsafe operations?
* RQ 4.3.4：Coinソフトウェアは、安全でない操作を防ぐために、コントロールソフトウェアが開始するコマンドをどのように検証できますか？
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 as well as to reduce load on origin servers. For this, they often utilize DNS-based indirection to serve the request on behalf of the origin server. Both of these objectives are within scope to be addressed by COIN methods and solutions.
エンドユーザーへのコンテンツの配信は、多くの場合、コンテンツ配信ネットワーク（CDN）に依存しています。CDNSストアによると、レイテンシを削減した配信のためにエンドユーザーに近いコンテンツと、オリジンサーバーの負荷を削減しました。このために、彼らはしばしばDNSベースの間接を利用して、Origin Serverに代わってリクエストを提供します。これらの目的は両方とも、コインの方法とソリューションによって対処される範囲内です。
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.
このドラフトの観点から見ると、CDNはコインプログラムの（ネットワークサービスレベル）セットとして解釈できます。これらのプログラムは、最初にOrigin ServerからCDN Ingressにコンテンツを最初に分散するための分散ロジックを実装し、次にCDN複製ポイントにさらに導入し、最終的にユーザー向けコンテンツリクエストを提供します。
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, which will eventually serve the user's request. The replication architecture and mechanisms themselves differ from one (CDN) provider to another, and often utilize private peering or network arrangements in order to distribute the content internationally and regionally.
CDNテクノロジーは、既存のインターネットによく説明され、展開されています。グローバルサーバーロードバランシング（GSLB）[GSLB]やAnycast Serverソリューションなどのコアテクノロジーは、最も適切なローカルCDNサーバーへのコンテンツ要求（通常はHTTPリクエストの形式）の間接を扱うために使用されます。コンテンツは、コンテンツ所有者/プロデューサーからコンテンツの注入ポイントとして機能するシードサーバーから、最終的にユーザーの要求に応える実際のCDNサーバーに複製されます。複製アーキテクチャとメカニズム自体は、（CDN）プロバイダーから別のプロバイダーとは異なり、コンテンツを国際的および地域的に配布するために、プライベートピアリングまたはネットワークの取り決めを使用します。
Studies such as those in [FCDN] have shown that content distribution at the level of named content, utilizing efficient (e.g., Layer 2 (L2)) 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. Works such as those in [SILKROAD] utilize Application-Specific Integrated Circuits (ASICs) to replace server-based load balancing with significant cost reductions, thus showcasing the potential for in-network operations.
[FCDN]のような研究では、エッジCDNノードに向けた複製のために効率的な（レイヤー2（L2））マルチキャストを使用して、名前付きコンテンツのレベルでのコンテンツ分布がネットワーク全体とサーバーの効率を大幅に向上させることが示されています。また、需要の変化に対してより迅速にエッジコンテンツを更新するためのネットワーク効率の向上から恩恵を受けることにより、コンテンツの検索と必要なエッジストレージ容量の間接レイテンシを減らします。[Silkroad]のような作品は、アプリケーション固有の統合回路（ASIC）を利用して、サーバーベースの負荷バランスを大幅なコスト削減に置き換えるため、ネットワーク内操作の可能性を示しています。
* Supporting service-level routing of requests (such as service routing in [APPCENTRES]) to specific COIN program instances may improve on end-user experience in retrieving faster (and possibly better quality) content.
* 特定のコインプログラムインスタンスへのリクエストのサービスレベルのルーティング（[appcentres]のサービスルーティングなど）をサポートすることで、より速い（そしておそらくより良い品質の）コンテンツを取得するエンドユーザーエクスペリエンスが向上する可能性があります。
* COIN instances may also be utilized to integrate service-related telemetry information to support the selection of the final service instance destination from a pool of possible choices.
* コインインスタンスを利用して、サービス関連のテレメトリ情報を統合して、可能な選択肢のプールから最終サービスインスタンスの宛先の選択をサポートすることもできます。
* Supporting the selection of a service destination from a set of possible choices (virtualized and distributed) in COIN program instances (e.g., through constraint-based routing decisions as seen in [APPCENTRES]) to improve the overall end-user experience by selecting a "more suitable" service destination over another (e.g., avoiding/reducing overload situations in specific service destinations).
* コインプログラムインスタンス（例えば、[Appcentres]に見られる制約ベースのルーティング決定を通じて）の可能な選択肢（仮想化および分散）からのサービス宛先の選択をサポートして、別の「より適切な」サービスの目的地を選択することにより、全体的なエンドユーザーエクスペリエンスを改善します（例えば、特定のサービスの運命の過剰な状況を回避/削減する）。
* Supporting L2 capabilities for multicast (compute interconnection and collective communication as seen in [APPCENTRES]) may reduce the network utilization and therefore increase the overall system efficiency. For example, this support may be through in-network, switch-based replication decisions (and their optimizations) based on dynamic group membership information.
* マルチキャストのL2機能をサポートする（[AppCentres]で見られるように、コンピューテインターコネクションと集合通信）がネットワークの利用を削減し、したがってシステム全体の効率を高める可能性があります。たとえば、このサポートは、動的なグループメンバーシップ情報に基づいて、ネットワーク内のスイッチベースの複製決定（およびその最適化）を介して行われる場合があります。
In addition to the research questions in Section 3.1.5:
セクション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, such as through on-path optimizations for fanouts?
* RQ 5.1.1：L2マルチキャストを利用してCDNデザインを改善する方法は？ファンアウト用のパス最適化など、これらのデザインでコイン機能を利用する方法は？
* RQ 5.1.2: What forwarding methods may support the required multicast capabilities (see [FCDN]) and how could programmable COIN forwarding elements support those methods (e.g., extending current SDN capabilities)?
* RQ 5.1.2：必要なマルチキャスト機能（[FCDN]を参照）をサポートする転送方法は、プログラム可能なコイン転送要素をどのようにしてそれらの方法をサポートできますか（例：現在のSDN機能を拡張）。
* RQ 5.1.3: What are the constraints, reflecting both compute and network capabilities, that may support joint optimization of routing and computing? How could intermediary COIN program instances support, for example, the aggregation of those constraints to reduce overall telemetry network traffic?
* RQ 5.1.3：ルーティングとコンピューティングの共同最適化をサポートする可能性のある計算機能とネットワーク機能の両方を反映した制約は何ですか？中間コインプログラムインスタンスは、たとえば、これらの制約が全体的なテレメトリーネットワークトラフィックを削減するための制約の集約をどのようにサポートできますか？
* RQ 5.1.4: Could traffic steering be performed on the data path and per service request (e.g., through COIN program instances that perform novel routing request lookup methods)? If so, what would be performance improvements?
* RQ 5.1.4：データパスおよびサービス要求ごとにトラフィックステアリングを実行できますか（たとえば、新しいルーティングリクエストの検索方法を実行するコインプログラムインスタンスを介して）？もしそうなら、パフォーマンスの改善とはどうなりますか？
* RQ 5.1.5: How could storage be traded off against frequent, multicast-based replication (see [FCDN])? Could intermediary/in-network COIN elements support the storage beyond current endpoint-based methods?
* RQ 5.1.5：頻繁なマルチキャストベースのレプリケーション（[FCDN]を参照）に対してストレージをどのようにトレードオフできますか？中間/ネットワークのコイン要素は、現在のエンドポイントベースのメソッドを超えてストレージをサポートできますか？
* RQ 5.1.6: What scalability limits exist for L2 multicast capabilities? How to overcome them, e.g., through COIN program instances serving as stateful subtree aggregators to reduce the needed identifier space (e.g., for bit-based forwarding)?
* RQ 5.1.6：L2マルチキャスト機能にはどのようなスケーラビリティ制限がありますか？たとえば、それらを克服する方法、たとえば、コインプログラムインスタンスは、必要な識別子スペースを削減するために、ステートフルなサブツリーアグリゲーターとして機能します（たとえば、ビットベースの転送など）？
We interpret connected compute resources as operating at a suitable layer, such as Ethernet, InfiniBand, but also at Layer 3 (L3), to allow for the exchange of suitable invocation methods, such as those exposed through verb-based or socket-based APIs. The specific invocations here are subject to the applications running over a selected pool of such connected compute resources.
接続されたコンピューテリソースは、イーサネット、インフィニバンドなどの適切な層で動作していると解釈し、レイヤー3（L3）でも、動詞ベースまたはソケットベースのAPIを介して暴露されたものなど、適切な呼び出し方法の交換を可能にします。ここでの特定の呼び出しは、このような接続されたコンピューティングリソースの選択したプールを介して実行されるアプリケーションの対象となります。
Providing such a pool of connected compute resources (e.g., in regional or edge data centers, base stations, and even end-user devices) opens up the opportunity for infrastructure providers to offer CFaaS-like offerings to application providers, leaving the choice of the appropriate invocation method to the app and service provider. Through this, 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.
このような接続されたコンピューティングリソースのプール（例：地域またはエッジデータセンター、ベースステーション、さらにはエンドユーザーデバイス）を提供すると、インフラストラクチャプロバイダーがアプリケーションプロバイダーにCFAASのような製品を提供する機会が開かれ、アプリとサービスプロバイダーに適切な呼び出し方法を選択します。これにより、コンピューティングリソースを利用して、アプリケーションが構成されている目的のコインプログラムを実行することができますが、それらのコンピューティングリソース間の相互接続を利用して、分散方法で行うことができます。
We foresee those CFaaS offerings to be tenant-specific, with a tenant here defined as the provider of at least one application. For this, we foresee an interaction between the 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, for example, 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.
ここでは、少なくとも1つのアプリケーションのプロバイダーとして定義されているテナントを使用して、これらのCFAAS製品をテナント固有のものにすると予測しています。このために、CFAASプロバイダーとテナントとの相互作用を予測して、ファブリックの需要側を定義する適切なリソースを動的に選択します。逆に、ファブリックの供給側は非常に動的であると予測し、たとえば、ユーザーが提供するリソース（供給が高度にコンテキスト固有の供給ポリシーに依存する可能性がある）または、車両のシナリオでの道路側のインフラストラクチャを通じて提供される断続的な入手可能性のインフラストラクチャリソースを介して生地に提供されます。
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.
結果として生じる動的な需要サプライマッチングは、コンピューティングファブリックの動的な性質を確立し、リソースプロバイダーとCFAASプロバイダーの間に動的に構築するために信頼関係を必要とする必要があります。これには、すべてのリソースをCFAASとして露出した（テナント固有の）ファブリックに適切に相互接続するために、通信リソースを動的に調整する必要があります。
There exist a number of technologies to build non-local (wide area) L2 as well as L3 networks, which in turn allows for connecting compute resources for a distributed computational task. For instance, 5G-LAN [SA2-5GLAN] specifies a cellular L2 bearer for interconnecting L2 resources within a single cellular operator. The work in [ICN-5GLAN] 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. This is done in order to achieve computational interconnections, including scenarios such as those outlined in Section 3.1. L2 network virtualization (see [L2Virt]) is one of the methods used for realizing so-called "cloud-based" applications for applications developed with "physical" networks in mind, thus forming an interconnected compute and storage fabric.
非ローカル（広い領域）L2とL3ネットワークを構築するための多くのテクノロジーが存在します。これにより、分散計算タスクの計算リソースを接続できます。たとえば、5G-LAN [SA2-5GLAN]は、単一の細胞演算子内でL2リソースを相互接続するためのセルラーL2ベアラーを指定します。[ICN-5GLAN]の作業は、5G-LANを介したパスベースの転送ソリューション、およびSDNベースのLAN接続とIPおよびHTTPレベルのリソースのICNベースの命名を使用して概説しています。これは、セクション3.1で概説されているシナリオなど、計算の相互接続を実現するために行われます。L2ネットワーク仮想化（[L2VIRT]を参照）は、「物理的な」ネットワークを念頭に置いて開発されたアプリケーションのいわゆる「クラウドベースの」アプリケーションを実現するために使用される方法の1つであり、相互接続されたコンピューティングとストレージファブリックを形成します。
* Supporting service-level routing of compute resource requests (such as 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.
* コンピューティングリソース要求のサービスレベルのルーティングをサポートすること（[AppCentres]のサービスルーティングなど）は、分散アプリケーションの実行のためにCFAASファブリック全体の豊富なコンピューティングリソースを利用できる場合があります。これらのアプリケーションの分散構成要素は、コインプログラムとして実現され、コインプログラムのインスタンスとしてコインシステム内で実行されます。
* Supporting the constraint-based selection of a specific COIN program instance over others (such as constraint-based routing in [APPCENTRES]) will allow for optimizing both the CFaaS provider constraints as well as tenant-specific constraints.
* 他のコインプログラムインスタンスの制約ベースの選択をサポートすること（[AppCentres]の制約ベースのルーティングなど）を使用すると、CFAASプロバイダーの制約とテナント固有の制約の両方を最適化できます。
* Supporting L2 and L3 capabilities for multicast (such as compute interconnection and collective communication in [APPCENTRES]) will allow for decreasing 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.
* マルチキャストのL2およびL3機能をサポートする（[Appcentres]でのコンピューティング間接続や集合通信など）の両方のネットワーク利用を減らすことができるだけでなく、CFAASサービスの所有権の総コストを削減するために、両方のネットワーク使用率を減らすことができます（これらのコンピューティングエンドポイントでのユニキャスト複製を回避します）。
* Supporting intermediary COIN program instances to allow for the enforcement of trust relationships and isolation policies (e.g., enforcing specific traffic shares or strict isolation of traffic through differentiated queueing).
* 信頼関係と隔離ポリシーの実施を可能にするための仲介コインプログラムインスタンスをサポートします（例えば、特定の交通シェアの実施または差別化されたキューイングを介したトラフィックの厳格な隔離）。
In addition to the research questions in Section 3.1.5:
セクション3.1.5の研究質問に加えて：
* RQ 5.2.1: How to convey tenant-specific requirements for the creation of the CFaaS fabric?
* RQ 5.2.1：CFAASファブリックの作成にテナント固有の要件を伝える方法は？
* RQ 5.2.2: How to dynamically integrate resources into the compute fabric being utilized for the app execution (those resources include, but are not limited to, end-user provided resources), particularly when driven by tenant-level requirements and changing service-specific constraints? How can those resources be exposed through possible COIN execution environments?
* RQ 5.2.2：特にテナントレベルの要件とサービス固有の制約の変更によって駆動される場合、リソースをアプリの実行に使用するコンピューティングファブリックに動的に統合する方法（エンドユーザーが提供するリソースが含まれますが、これらに限定されないリソースが含まれますが、これらに限定されません）？これらのリソースは、可能なコイン実行環境を通じてどのように公開できますか？
* 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?
* RQ 5.2.3：リソースの可用性と説明責任を支援するためにコイン機能を利用する方法、つまり、CFAAS環境のコインプログラムは何であるかを順番にコインシステムの分散実行能力を利用しますか？
* RQ 5.2.4: How to utilize COIN capabilities to enforce traffic and isolation policies for establishing trust between tenant and CFaaS provider in an assured operation?
* RQ 5.2.4：保証された運用でテナントとCFAASプロバイダーの間で信頼を確立するためのトラフィックと隔離ポリシーを実施するためにコイン機能を利用する方法は？
* RQ 5.2.5: How to optimize the interconnection of compute resources, including those dynamically added and removed during the provisioning of the tenant-specific compute fabric?
* RQ 5.2.5：テナント固有のコンピューティングファブリックのプロビジョニング中に動的に追加および削除されたリソースを含む、コンピューテリソースの相互接続を最適化する方法は？
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 be, for example, P4 programs, OpenFlow rules, or higher layer programs. This feature can enable other use cases described in this draft to be deployed using virtual network services, over underlying networks such as data centers, mobile networks, or other fixed or wireless networks.
「仮想ネットワークプログラミング」という用語は、テナントが仮想ネットワークでコインプログラムを展開および操作するメカニズムを記述するために提案されています。このようなコインプログラムは、たとえば、P4プログラム、OpenFlowルール、または高層プログラムなどです。この機能により、このドラフトで説明されている他のユースケースは、データセンター、モバイルネットワーク、またはその他の固定またはワイヤレスネットワークなどの基礎となるネットワークを使用して、仮想ネットワークサービスを使用して展開できます。
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 metrics 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.
* このプロトコルのルーターのP4実装を使用して、新しいルーティングプロトコル（ICNなど）を試します。
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. As an assumption in this use case, some mobile network equipment (e.g., User Plane Functions (UPFs)) and devices (e.g., mobile phones or residential gateways) include a network switch functionality that is used as a PND.
仮想コインプログラミングの具体的な例を提供するために、5G基礎ネットワーク、5Glan仮想化テクノロジー、およびP4プログラミング言語と環境を使用したユースケースを検討します。このユースケースの仮定として、一部のモバイルネットワーク機器（ユーザープレーン機能（UPFS）など）とデバイス（携帯電話や住宅用ゲートウェイなど）には、PNDとして使用されるネットワークスイッチ機能が含まれています。
Section 5.1 of [ICN-5GC] 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.
[ICN-5GC]のセクション5.1は、5GLANに関連する5Gネットワーク関数とインターフェイスの説明を提供します。これは、[TS23.501]および[TS23.502]で指定されています。5Glanサービスの顧客/テナントの観点から、5Gネットワークはスイッチとして動作します。
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 a 5G non-public network, for example. 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.
図3に示すユースケースでは、テナントは5グランネットワークセグメント（単一の論理スイッチと見なされる）、固定セグメントを含むネットワークを操作します。モバイルデバイス（またはユーザー機器ノード）UE1、UE2、UE3、およびUE4は、同じ5GlanとDevice1とDevice2（UE4を介して）にあります。このシナリオは、たとえば5G非パブリックネットワークを使用して、プラントまたはエンタープライズネットワークで行うことができます。テナントはP4プログラムを使用して、固定スイッチと5Glanスイッチの両方の動作を決定します。テナントは、5Glan P4プログラムをモバイルネットワークに提供し、コントローラーを操作することもできます。
..... 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)
+---------+ +------------+
Figure 3: 5G Virtual Network Programming Overview
図3：5G仮想ネットワークプログラミングの概要
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 data center networks.
たとえば、[Stoyanov]によって、個々の仮想スイッチのP4ネットワークプログラミングを可能にする研究が行われています。私たちの知る限り、モバイルまたはデータセンターネットワーク上に仮想コインプログラムを展開するための完全なソリューションは開発されていません。
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 controllers, code, and expertise.
* データセンター、5Gネットワーク、その他の固定およびワイヤレスネットワーク間のコインプログラムの移植を促進し、コントローラー、コード、および専門知識を共有できる統一プログラミングモデル。
* Increasing the level of customization available to customers/ tenants of mobile networks or data centers 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.
* 典型的な構成機能と比較して、モバイルネットワークまたはデータセンターの顧客/テナントが利用できるカスタマイズのレベルを上げる。たとえば、5Gネットワークの進化は、P4と同様のプログラミングモデルを使用してテナントが処理できるプライベートモバイルネットワークの分析が増え続ける専門化とカスタマイズを指摘しています。
* Using network programs to influence underlying network services (e.g., requesting specific QoS for some flows in 5G or data centers) to increase the level of in-depth customization available to tenants.
* ネットワークプログラムを使用して、基礎となるネットワークサービス（たとえば、5Gまたはデータセンターの一部のフローの特定のQOを要求する）を使用して、テナントが利用できる詳細なカスタマイズのレベルを上げます。
* RQ 5.3.1: Underlying network awareness
* RQ 5.3.1：基礎となるネットワーク認識
A virtual COIN program can both influence, and be influenced by, the underling network. Research challenges include defining methods to distribute COIN programs, including in a mobile network context, based on network awareness, since some information and actions may be available on some nodes but not on others.
仮想コインプログラムは、アンダーリングネットワークに影響を与え、影響を受けることができます。研究の課題には、ネットワークの認識に基づいたモバイルネットワークのコンテキストを含むコインプログラムを配布する方法の定義が含まれます。これは、一部のノードではないが他のノードでは情報とアクションが利用可能である可能性があるためです。
* RQ 5.3.2: Splitting/distribution
* RQ 5.3.2：分割/配布
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 (or at least once for idempotent operations), while allowing an 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 [P4-SPLIT] and [Sultana] (based on capability 5.3.2).
仮想コインプログラムは、複数のコンピューティングノードに展開する必要がある場合があり、インスタンスの配置と分布に関する調査の質問につながる場合があります。たとえば、プログラムロジックは、パケットごとに1回または少なくとも1回（または少なくとも1回はidempotent操作に1回）適用する必要がありますが、基礎となるネットワークによる最適な転送パスを許可します。研究の課題には、手動（プログラマーによる）の定義または低いまたは最小限のリソースを使用するコインプログラムを配布する自動方法が含まれます。分散P4プログラムは、[P4-Split]および[Sultana]で研究されています（機能5.3.2に基づいて）。
* RQ 5.3.3: Multi-tenancy support
* RQ 5.3.3：マルチテナンシーサポート
A COIN system supporting virtualization should enable tenants to deploy COIN programs onto their virtual networks, in such a way that 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 (based on capability 5.3.3).
仮想化をサポートするコインシステムは、複数の仮想コインプログラムインスタンスが同じ計算ノードで実行できるように、テナントがコインプログラムを仮想ネットワークに展開できるようにする必要があります。スイッチ[Stoyanov]でのP4マルチテナンシーのメカニズムが提案されましたが、テナントとリソースの公正な再構成（能力5.3.3に基づく）の間の隔離に関する研究の質問は残っています。
* RQ 5.3.4: Security
* RQ 5.3.4：セキュリティ
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
* RQ 5.3.5：高層処理
Can a virtual network model facilitate the deployment of COIN programs acting on application-layer data? This is an open question, since this section focuses on packet/flow processing.
仮想ネットワークモデルは、アプリケーション層データに作用するコインプログラムの展開を容易にすることができますか？このセクションではパケット/フローの処理に焦点を当てているため、これは未解決の質問です。
There is a growing range of use cases demanding the realization of AI training capabilities among distributed endpoints. One such use case is to distribute large-scale model training across more than one data center (e.g., when facing energy issues at a single site or when simply reaching the scale of training capabilities at one site, thus wanting to complement training with the capabilities of another or possibly many sites). From a COIN perspective, those capabilities may be realized as COIN programs and executed throughout a COIN system, including in PNDs.
分散エンドポイントの間でAIトレーニング機能の実現を要求するユースケースの範囲が増えています。そのようなユースケースの1つは、複数のデータセンターに大規模なモデルトレーニングを配布することです（たとえば、単一のサイトでエネルギーの問題に直面している場合、または単に1つのサイトでトレーニング機能の規模に到達する場合、別のサイトまたは場合によっては多くのサイトの機能でトレーニングを補完したい場合）。コインの観点からは、これらの機能はコインプログラムとして実現され、PNDを含むコインシステム全体で実行される場合があります。
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).
一部のソリューションには、推論ロジックのローカリゼーションが必要になる場合があります（たとえば、使用された生の入力データのプライバシーをよりよく維持する属性を導き出すため）。PNDを含む近くのコンピューティングリソースでコインプログラムインスタンスを迅速に確立することは、そのようなローカリゼーションの要求をその場で満たすことさえできます（たとえば、特定の使用が実現されている場合、特定の時間の後に終了します）。
Individual training "sites" may not be a data center, but may instead consist of powerful, yet stand-along devices that federate computing power towards training a model, captured as "federated training" and provided through platforms such as [FLOWER]. Use cases here may be that of distributed training on (user) image data, the training over federated social media sites [MASTODON], or others.
個々のトレーニング「サイト」はデータセンターではないかもしれませんが、代わりに、モデルのトレーニングに向けてコンピューティングパワーを統合し、「フェデレーショントレーニング」としてキャプチャされ、[Flower]などのプラットフォームを介して提供される強力でありながら独立したデバイスで構成されている場合があります。ここでのユースケースは、（ユーザー）画像データに関する分散トレーニング、フェデレーションソーシャルメディアサイト[Mastodon]などのトレーニングなどです。
Apart from the distribution of compute power, the distribution of data may be a driver for distributed AI training use cases, such as in the Mastodon federated social media sites [MASTODON] or training over locally governed patient data or others.
計算電力の分布とは別に、データの分布は、Mastodonフェデレーションソーシャルメディアサイト[Mastodon]などの分散AIトレーニングユースケースのドライバーであるか、地元で統治されている患者データなどを介したトレーニングのドライバーである可能性があります。
Reasoning frameworks, such as TensorFlow, may be utilized for the realization of the (distributed) AI training logic, building on remote service invocation through protocols such as gRPC [GRPC] or the Message Passing Interface (MPI) [MPI] with the intention of providing an on-chip Neural Processor Unit (NPU) like abstraction to the AI framework.
Tensorflowなどの推論フレームワークは、（分散）AIトレーニングロジックの実現に使用される場合があります。AIトレーニングロジックは、GRPC [GRPC]などのプロトコル（MPI）[MPI]を介したリモートサービスの呼び出しに基づいて、AIフレームの抽象化のようなオンチップニューラルプロセッサユニット（NPU）を提供することを目的として使用できます。
A number of activities on distributed AI training exist in the area of developing the 5th and 6th generation mobile network, with various activities in the 3GPP Standards Development Organization (SDO) as well as use cases developed for the ETSI MEC initiative mentioned in previous use cases.
第5世代および第6世代のモバイルネットワークの開発分野には、分散型AIトレーニングに関する多くのアクティビティが存在し、3GPP標準開発組織（SDO）でさまざまなアクティビティと、以前のユースケースで言及されたETSI MECイニシアチブ向けに開発されたユースケースがあります。
* Supporting service-level routing of training requests (such as service routing in [APPCENTRES]) with AI services being exposed to the network, and where COIN program instances may support the selection of the most suitable service instance based on control plane information (e.g., on AI worker compute capabilities being distributed across COIN program instances).
* AIサービスがネットワークに公開され、コインプログラムインスタンスがコントロールプレーン情報に基づいて最も適切なサービスインスタンスの選択をサポートする場合、トレーニングリクエストのサービスレベルのルーティング（[Appcentresの[Appcentres]のサービスルーティングなど）をサポートすることができます（コインプログラムインスタンスに分配されているAIワーカーコンピューティング機能）。
* Supporting the collective communication primitives, such as all-to-all and scatter-gather, utilized by the (distributed) AI workers may increase the overall network efficiency (e.g., through avoiding endpoint-based replication or even directly performing collective primitive operations in COIN program instances placed in topologically advantageous places).
* （分散型の）AIワーカーによって利用されるすべての散乱採掘などの集合的なコミュニケーションプリミティブをサポートすることで（たとえば、エンドポイントベースの複製を避けるため、またはトポロジカルに有利な場所に配置されたコインプログラムインスタンスで集合的なプリミティブ操作を直接実行することで）。
* 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.
* AIサービスの複数のインスタンス間の集合通信（つまり、コインプログラムインスタンス）をサポートすることは、ネットワークにプラスの影響を与える可能性がありますが、ユニキャストレプリケーションからネットワーク支援マルチキャスト操作に移行することにより、使用率を計算することもできます。
In addition to the research questions in Section 3.1.5:
セクション3.1.5の研究質問に加えて：
* RQ 6.1.1: What are the communication patterns that may be supported by collective communication solutions, where those solutions directly utilize COIN program instance capabilities within the network (e.g., perform Reduce options in a central COIN program instance)?
* RQ 6.1.1：これらのソリューションがネットワーク内でコインプログラムインスタンス機能を直接利用するコレクティブコミュニケーションソリューションによってサポートされるコミュニケーションパターンは何ですか（たとえば、中央コインプログラムインスタンスで削減オプションを実行します）。
* RQ 6.1.2: How to achieve scalable collective communication primitives with rapidly changing receiver sets (e.g., where training workers may be dynamically selected based on energy efficiency constraints [GREENAI])?
* RQ 6.1.2：急速に変化するレシーバーセットを備えたスケーラブルな集合コミュニケーションプリミティブを実現する方法（たとえば、エネルギー効率の制約[Greenai]に基づいてトレーニングワーカーが動的に選択される場合があります）？
* RQ 6.1.3: What COIN capabilities may support the collective communication patterns found in distributed AI problems?
* RQ 6.1.3：分散されたAIの問題に見られる集合的なコミュニケーションパターンをサポートするコイン機能は何ですか？
* RQ 6.1.4: How to support AI-specific invocation protocols, such as MPI or Remote Direct Memory Access (RDMA)?
* RQ 6.1.4：MPIやリモートダイレクトメモリアクセス（RDMA）などのAI固有の呼び出しプロトコルをサポートする方法は？
* RQ 6.1.5: What are 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, and how to signal and act upon them?
* RQ 6.1.5：PNDを含む特定の論理実行ポイント（および関連する物理的位置）にコインプログラムの形で（AI）実行ロジックを配置するための制約は何ですか？
This section describes a preliminary categorization of the research questions illustrated in Figure 4. A more comprehensive analysis has been initiated by members of the COINRG community in [USE-CASE-AN] but has not been completed at the time of writing this memo.
このセクションでは、図4に示す研究質問の予備分類について説明します。より包括的な分析は、[ユースケースAN]のCoINRGコミュニティのメンバーによって開始されましたが、このメモを書く時点では完成していません。
+--------------------------------------------------------------+
+ Applicability Areas +
+ .............................................................+
+ Transport | App | Data | Routing & | (Industrial) +
+ | Design | Processing | Forwarding | Control +
+--------------------------------------------------------------+
+--------------------------------------------------------------+
+ Distributed Computing Frameworks and Languages to COIN +
+--------------------------------------------------------------+
+--------------------------------------------------------------+
+ Enabling Technologies for COIN +
+--------------------------------------------------------------+
+--------------------------------------------------------------+
+ Vision(s) for COIN +
+--------------------------------------------------------------+
Figure 4: Research Questions Categories
図4：研究の質問カテゴリ
The "Vision(s) for COIN" category is about defining and shaping the exact scope of COIN. In contrast to the "Enabling Technologies" category, these research questions look at the problem from a more philosophical perspective. In particular, the questions center around where to perform computations, which tasks are suitable for COIN, for which tasks COIN is suitable, and which forms of deploying COIN might be desirable. This category includes the research questions 3.1.8, 3.2.1, 3.3.5, 3.3.6, 3.3.7, 5.3.3, 6.1.1, and 6.1.3.
「コインのビジョン」カテゴリは、コインの正確な範囲を定義および形成することです。「有効化テクノロジー」カテゴリとは対照的に、これらの研究の質問は、より哲学的な観点から問題を調べています。特に、質問は、コインに適しているタスクがコインに適しており、コインの展開形式が望ましい場合があるコインに適した計算を実行する場所に集中しています。このカテゴリには、研究質問3.1.8、3.2.1、3.3.5、3.3.6、3.3.7、5.3.3、6.1.1、および6.1.3が含まれます。
The "Enabling Technologies for COIN" category digs into what technologies are needed to enable COIN, which of the existing technologies can be reused for COIN, and what might be needed to make the "Vision(s) for COIN" a reality. In contrast to the "Vision(s) for COIN", these research questions look at the problem from a practical perspective (e.g., by considering how COIN can be incorporated in existing systems or how the interoperability of COIN execution environments can be enhanced). This category includes the research questions 3.1.7, 3.1.8, 3.2.3, 4.2.7, 5.1.1, 5.1.2, 5.1.6, 5.3.1, 6.1.2, and 6.1.3.
「コインのためのテクノロジーを有効にする」カテゴリは、コインを有効にするために必要な技術、既存のテクノロジーをコインに再利用できるもの、および「コインのビジョン」を現実にするために必要なものを掘り下げます。「コインのビジョン」とは対照的に、これらの研究の質問は、実用的な観点から問題を検討します（たとえば、コインを既存のシステムにどのように組み込むことができるか、またはコインの実行環境の相互運用性をどのように強化できるかを検討することにより）。このカテゴリには、研究質問3.1.7、3.1.8、3.2.3、4.2.7、5.1.1、5.1.2、5.1.6、5.3.1、6.1.2、および6.1.3が含まれます。
The "Distributed Computing Frameworks and Languages to COIN" category focuses on how COIN programs can be deployed and orchestrated. Central questions arise regarding the composition of COIN programs, the placement of COIN functions, the (dynamic) operation and integration of COIN systems as well as additional COIN system properties. Notably, COIN diversifies general distributed computing platforms such that many COIN-related research questions could also apply to general distributed computing frameworks. This category includes the research questions 3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 4.1.1, 4.1.4, 4.1.5, 4.1.8, 4.2.1, 4.2.4, 4.2.5, 4.2.6, 4.3.3, 5.2.1, 5.2.2, 5.2.3, 5.2.5, 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, and 6.1.5.
「分散コンピューティングフレームワークとコインへの言語」カテゴリは、コインプログラムの展開と調整の方法に焦点を当てています。コインプログラムの構成、コイン機能の配置、コインシステムの（動的）操作と統合、および追加のコインシステムプロパティに関して、中心的な疑問が生じます。特に、Coinは一般的な分散コンピューティングプラットフォームを多様化し、多くのコイン関連の研究質問が一般的な分散コンピューティングフレームワークにも適用できるようになります。This category includes the research questions 3.1.1, 3.2.4, 3.3.1, 3.3.2, 3.3.3, 3.3.5, 4.1.1, 4.1.4, 4.1.5, 4.1.8, 4.2.1, 4.2.4, 4.2.5, 4.2.6, 4.3.3, 5.2.1, 5.2.2, 5.2.3, 5.2.5, 5.3.1, 5.3.2, 5.3.3, 5.3.4, 5.3.5, and6.1.5。
In addition to these core categories, there are use case specific research questions that are heavily influenced by the specific constraints and objectives of the respective use cases. This "Applicability Areas" category can be further refined into the following subgroups:
これらのコアカテゴリに加えて、それぞれのユースケースの特定の制約と目的に大きく影響されるユースケース固有の研究質問があります。この「適用領域」カテゴリは、次のサブグループにさらに洗練できます。
* The "Transport" subgroup addresses the need to adapt transport protocols to handle dynamic deployment locations effectively. This subgroup includes the research question 3.1.2.
* 「Transport」サブグループは、動的展開の場所を効果的に処理するために輸送プロトコルを適応させる必要性に対処します。このサブグループには、研究質問3.1.2が含まれています。
* The "App Design" subgroup relates to the design principles and considerations when developing COIN applications. This subgroup includes the research questions 4.1.2, 4.1.3, 4.1.7, 4.2.6, 5.1.1, 5.1.3, and 5.1.5.
* 「アプリデザイン」サブグループは、コインアプリケーションを開発する際の設計原則と考慮事項に関連しています。このサブグループには、研究質問4.1.2、4.1.3、4.1.7、4.2.6、5.1.1、5.1.3、および5.1.5が含まれます。
* The "Data Processing" subgroup relates to the handling, storage, analysis, and processing of data in COIN environments. This subgroup includes the research questions 3.2.4, 3.2.6, 4.2.2, 4.2.3, and 4.3.2.
* 「データ処理」サブグループは、コイン環境でのデータの取り扱い、ストレージ、分析、および処理に関連しています。このサブグループには、研究質問3.2.4、3.2.6、4.2.2、4.2.3、および4.3.2が含まれます。
* The "Routing & Forwarding" subgroup explores efficient routing and forwarding mechanisms in COIN, considering factors such as network topology, congestion control, and quality of service. This subgroup includes the research questions 3.1.2, 3.1.3, 3.1.4, 3.1.5, 3.1.6, 3.2.6, 5.1.2, 5.1.3, 5.1.4, and 6.1.4.
* 「ルーティングと転送」のサブグループは、ネットワークトポロジ、渋滞制御、サービス品質などの要因を考慮して、コインの効率的なルーティングと転送メカニズムを調査します。このサブグループには、研究質問3.1.2、3.1.3、3.1.4、3.1.5、3.1.6、3.2.6、5.1.2、5.1.3、5.1.4、および6.1.4が含まれます。
* The "(Industrial) Control" subgroup relates to industrial control systems, addressing issues like real-time control, automation, and fault tolerance. This subgroup includes the research questions 3.1.9, 3.2.5, 3.3.1, 3.3.4, 4.1.1, 4.1.6, 4.1.8, 4.2.3, 4.3.1, and 4.3.4.
* 「（産業）制御」サブグループは、産業制御システムに関連しており、リアルタイムの制御、自動化、断層トレランスなどの問題に対処しています。このサブグループには、研究質問3.1.9、3.2.5、3.3.1、3.3.4、4.1.1、4.1.6、4.1.8、4.2.3、4.3.1、および4.3.4が含まれます。
COIN systems, like any other system using "middleboxes", can have different security and privacy implications that strongly depend on the used platforms, the provided functionality, and the deployment domain, with most if not all considerations for general middleboxes also applying to COIN systems.
コインシステムは、「ミドルボックス」を使用している他のシステムと同様に、使用済みのプラットフォーム、提供された機能、および展開ドメインに強く依存するセキュリティとプライバシーの意味を持つことができます。
One critical aspect for early COIN systems is the use of early generation PNDs, many of which do not have cryptography support and only have limited computational capabilities. Hence, PND-based COIN systems typically work on unencrypted data and often customize packet payload, while concepts such as homomorphic encryption could serve as workarounds, allowing PNDs to perform simple operations on the encrypted data without having access to it. All these approaches introduce the same or very similar security implications as any middlebox operating on unencrypted traffic or having access to encryption: a middlebox can itself have malicious intentions (e.g., because it got compromised or the deployment of functionality offers new attack vectors to outsiders).
初期のコインシステムの重要な側面の1つは、初期の世代PNDの使用であり、その多くは暗号化サポートがなく、計算機能が限られているだけです。したがって、PNDベースのコインシステムは通常、暗号化されていないデータで動作し、多くの場合パケットペイロードをカスタマイズしますが、同種暗号化などの概念は回避策として機能し、PNDが暗号化されたデータにアクセスできない簡単な操作を実行できます。これらのアプローチはすべて、暗号化されていないトラフィックや暗号化にアクセスできるミドルボックスと同じまたは非常に類似したセキュリティへの影響をもたらします。ミドルボックス自体は悪意のある意図を持つことができます（たとえば、侵害された、または機能の展開が部外者に新しい攻撃ベクターを提供するため）。
However, similar to middlebox deployments, risks for privacy and the risk of data exposure have to be carefully considered in the context of the concrete deployment. For example, exposing data to an external operator for mobile application offloading leads to a significant privacy loss of the user in any case. In contrast, such privacy considerations are not as relevant for COIN systems where all involved entities are under the same control, such as in an industrial context. Here, exposed data and functionality can instead lead to stolen business secrets or the enabling of DoS attacks, for example. Hence, even in fully controlled scenarios, COIN intermediaries, and middleboxes in general, are ideally operated in a least-privilege mode, where they have exactly those permissions to read and alter payload that are necessary to fulfill their purpose.
ただし、Middleboxの展開と同様に、プライバシーのリスクとデータ露出のリスクは、具体的な展開のコンテキストで慎重に考慮する必要があります。たとえば、モバイルアプリケーションのオフロードのためにデータを外部演算子に公開すると、いずれにせよユーザーのプライバシーが大幅に失われます。対照的に、このようなプライバシーの考慮事項は、産業の文脈など、関係するすべてのエンティティが同じ管理下にあるコインシステムに関連するものではありません。ここでは、露出したデータと機能性は、代わりに盗まれたビジネスの秘密や、たとえばDOS攻撃の有効化につながる可能性があります。したがって、完全に制御されたシナリオであっても、コインの仲介者、および一般的に中間ボックスは、目的を達成するために必要なペイロードを読み取り、変更する許可を正確に持っている最小限モードで理想的に動作します。
Research on granting middleboxes access to secured traffic is only in its infancy, and a variety of different approaches are proposed and analyzed [TLSSURVEY]. In a SplitTLS [SPLITTLS] deployment, for example, middleboxes have different incoming and outgoing TLS channels, such that they have full read and write access to all intercepted traffic. More restrictive approaches for deploying middleboxes rely on searchable encryption or zero-knowledge proofs to expose less data to intermediaries, but those only offer limited functionality. MADTLS [MADTLS] is tailored to the industrial domain and offers bit-level read and write access to intermediaries with low latency and bandwidth overhead, at the cost of more complex key management. Overall, different proposals offer different advantages and disadvantages that must be carefully considered in the context of concrete deployments. Further research could pave the way for a more unified and configurable solution that is easier to maintain and deploy.
セキュリティで保護されたトラフィックへのアクセスを許可することに関する研究は初期段階でのみ、さまざまなアプローチが提案および分析されています[Tlssurvey]。たとえば、Splittls [splittls]の展開では、ミドルボックスには、すべてのインターセプトされたトラフィックへの完全な読み取りおよび書き込みアクセスがあるように、入力および発信TLSチャネルが異なります。ミドルボックスを展開するためのより制限的なアプローチは、検索可能な暗号化またはゼロ知識証明に依存して、より少ないデータを仲介者に公開することに依存していますが、それらは限られた機能のみを提供します。MADTLS [MADTLS]は産業ドメインに合わせて調整されており、より複雑なキー管理を犠牲にして、低レイテンシと帯域幅のオーバーヘッドを持つ仲介者へのビットレベルの読み取りおよび書き込みアクセスを提供します。全体として、さまざまな提案は、具体的な展開のコンテキストで慎重に検討する必要があるさまざまな利点と欠点を提供します。さらなる研究は、維持と展開が簡単な、より統一された構成可能なソリューションへの道を開く可能性があります。
Finally, COIN systems and other middlebox deployments can also lead to security risks even if the attack stems from an outsider without direct access to any devices. As such, metadata about the entailed processing (processing times or changes in incoming and outgoing data) can allow an attacker to extract valuable information about the process. Moreover, such deployments can become central entities that, if paralyzed (e.g., through extensive requests), can be responsible for large-scale outages. In particular, some deployments could be used to amplify DoS attacks. Similar to other middlebox deployments, these potential risks must be considered when deploying COIN functionality and may influence the selection of suitable security protocols.
最後に、コインシステムやその他のミドルボックスの展開は、攻撃がデバイスに直接アクセスすることなく部外者に起因する場合でも、セキュリティリスクにつながる可能性があります。そのため、包括的な処理（受信データと発信データの処理時間または変更）に関するメタデータにより、攻撃者はプロセスに関する貴重な情報を抽出することができます。さらに、このような展開は、麻痺した場合（例えば、広範なリクエストを通じて）、大規模な停止の責任を負う可能性のある中央エンティティになる可能性があります。特に、一部の展開を使用して、DOS攻撃を増幅することができます。他のミドルボックスの展開と同様に、これらの潜在的なリスクをコイン機能を展開するときに考慮し、適切なセキュリティプロトコルの選択に影響を与える可能性があります。
Additional system-level security considerations may arise from regulatory requirements imposed on COIN systems overall, stemming from regulation regarding lawful interception, data localization, or AI use, for example. These requirements may impact, for example, the manner in which COIN programs may be placed or executed in the overall system, who can invoke certain COIN programs in what PND or COIN device, and what type of COIN program can be run. These considerations will impact the design of the possible implementing protocols but also the policies that govern the execution of COIN programs.
たとえば、合法的な傍受、データのローカリゼーション、またはAI使用に関する規制に起因する、コインシステム全体に課される規制要件から、追加のシステムレベルのセキュリティに関する考慮事項が生じる場合があります。これらの要件は、たとえば、コインプログラムをシステム全体に配置または実行する方法、PNDまたはCoinデバイスの特定のコインプログラムを呼び出すことができる方法、およびどのタイプのコインプログラムを実行できるかに影響を与える可能性があります。これらの考慮事項は、可能な実装プロトコルの設計に影響を与えますが、コインプログラムの実行を管理するポリシーにも影響します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This document presents use cases gathered from several application domains that can and could profit from capabilities that are provided by in-network and, more generally, distributed compute platforms. We distinguish between use cases in which COIN may enable new experiences (Section 3), expose new features (Section 6), or improve on existing system capabilities (Section 5), and other use cases where COIN capabilities enable totally new applications, for example, in industrial networking (Section 4).
このドキュメントでは、ネットワーク内およびより一般的には分散型コンピューティングプラットフォームによって提供される機能から利益を得ることができるいくつかのアプリケーションドメインから収集されたユースケースを提示します。コインが新しいエクスペリエンスを可能にする（セクション3）、新機能（セクション6）、または既存のシステム機能（セクション5）の改善（セクション5）の改善、およびコイン機能が産業ネットワーキング（セクション4）でまったく新しいアプリケーションを可能にする他のユースケースを区別します。
Beyond the mere description and characterization of those use cases, we identify opportunities arising from utilizing COIN capabilities and formulate corresponding research questions that may need to be addressed before being able to reap those opportunities.
これらのユースケースの単なる説明と特性評価を超えて、コイン能力を活用することから生じる機会を特定し、それらの機会を刈り取る前に対処する必要があるかもしれない対応する研究質問を策定します。
We acknowledge that this work offers no comprehensive overview of possible use cases and is thus only a snapshot of what may be possible if COIN capabilities existed. In fact, the decomposition of many current client-server applications into node-by-node transit could identify other opportunities for adding computing to forwarding, notably in the supply chain, health care, intelligent cities and transportation, and even financial services (among others). The presented use cases are selected based on the expertise of the contributing community members at the time of writing and are intended to cover a diverse range, from immersive and interactive media, industrial networks, to AI with varying characteristics, thus, providing the basis for a thorough subsequent analysis.
この作業は、可能なユースケースの包括的な概要を提供していないため、コイン機能が存在した場合に可能なことのスナップショットにすぎないことを認めます。実際、多くの現在のクライアントサーバーアプリケーションをノードバイノードトランジットに分解すると、特にサプライチェーン、ヘルスケア、インテリジェントな都市、輸送、さらには金融サービス（とりわけ）にコンピューティングを追加する他の機会を特定できます。提示されたユースケースは、執筆時点で貢献するコミュニティメンバーの専門知識に基づいて選択され、没入型およびインタラクティブなメディア、産業ネットワークからさまざまな特性を持つAIまで、多様な範囲をカバーすることを目的としており、したがって、徹底的なその後の分析の基礎を提供します。
[APPCENTRES]
Trossen, D., Sarathchandra, C., and M. Boniface, "In-
Network Computing for App-Centric Micro-Services", Work in
Progress, Internet-Draft, draft-sarathchandra-coin-
appcentres-04, 26 January 2021,
<https://datatracker.ietf.org/doc/html/draft-
sarathchandra-coin-appcentres-04>.
[CompNet2021]
Chen, M., Liu, W., Wang, T., Liu, A., and Z. Zeng, "Edge
intelligence computing for mobile augmented reality with
deep reinforcement learning approach", Computer Networks,
vol. 195, p. 108186, DOI 10.1016/j.comnet.2021.108186,
August 2021,
<https://doi.org/10.1016/j.comnet.2021.108186>.
[eCAR] Jeon, J. and W. Woo, "eCAR: edge-assisted Collaborative
Augmented Reality Framework", arXiv:2405.06872,
DOI 10.48550/ARXIV.2405.06872, 2024,
<https://doi.org/10.48550/ARXIV.2405.06872>.
[ETSI] ETSI, "Multi-access Edge Computing (MEC)",
<https://www.etsi.org/technologies/multi-access-edge-
computing>.
[FCDN] Al-Naday, M., Reed, M. J., Riihijarvi, J., Trossen, D.,
Thomos, N., and M. Al-Khalidi, "fCDN: A Flexible and
Efficient CDN Infrastructure without DNS Redirection of
Content Reflection", arXiv:1803.00876v2,
<https://arxiv.org/pdf/1803.00876.pdf>.
[FLOWER] Flower Labs GmbH, "A Friendly Federated AI Framework",
<https://flower.ai/>.
[GLEBKE] Glebke, R., Henze, M., Wehrle, K., Niemietz, P., Trauth,
D., Mattfeld, P., and T. Bergs, "A Case for Integrated
Data Processing in Large-Scale Cyber-Physical Systems",
Proceedings of the Annual Hawaii International Conference
on System Sciences, DOI 10.24251/hicss.2019.871, 2019,
<https://doi.org/10.24251/hicss.2019.871>.
[GREENAI] Magoula, L., Koursioumpas, N., Thanopoulos, A., Panagea,
T., Petropouleas, N., Gutierrez-Estevez, M., and R.
Khalili, "A Safe Genetic Algorithm Approach for Energy
Efficient Federated Learning in Wireless Communication
Networks", 2023 IEEE 34th Annual International Symposium
on Personal, Indoor and Mobile Radio Communications
(PIMRC), pp. 1-6, DOI 10.1109/pimrc56721.2023.10293863,
September 2023,
<https://doi.org/10.1109/pimrc56721.2023.10293863>.
[GRPC] "High performance, open source universal RPC framework",
<https://grpc.io/>.
[GSLB] Cloudflare, "What is global server load balancing
(GSLB)?",
<https://www.cloudflare.com/learning/cdn/glossary/global-
server-load-balancing-gslb/>.
[ICN-5GC] Ravindran, R., Suthar, P., Trossen, D., Wang, C., and G.
White, "Enabling ICN in 3GPP's 5G NextGen Core
Architecture", Work in Progress, Internet-Draft, draft-
ravi-icnrg-5gc-icn-04, 31 May 2019,
<https://datatracker.ietf.org/doc/html/draft-ravi-icnrg-
5gc-icn-04>.
[ICN-5GLAN]
Trossen, D., Robitzsch, S., Essex, U., AL-Naday, M., and
J. Riihijarvi, "Internet Services over ICN in 5G LAN
Environments", Work in Progress, Internet-Draft, draft-
trossen-icnrg-internet-icn-5glan-04, 1 October 2020,
<https://datatracker.ietf.org/doc/html/draft-trossen-
icnrg-internet-icn-5glan-04>.
[KUNZE-APPLICABILITY]
Kunze, I., Glebke, R., Scheiper, J., Bodenbenner, M.,
Schmitt, R., and K. Wehrle, "Investigating the
Applicability of In-Network Computing to Industrial
Scenarios", 2021 4th IEEE International Conference on
Industrial Cyber-Physical Systems (ICPS), pp. 334-340,
DOI 10.1109/icps49255.2021.9468247, May 2021,
<https://doi.org/10.1109/icps49255.2021.9468247>.
[KUNZE-SIGNAL]
Kunze, I., Niemietz, P., Tirpitz, L., Glebke, R., Trauth,
D., Bergs, T., and K. Wehrle, "Detecting Out-Of-Control
Sensor Signals in Sheet Metal Forming using In-Network
Computing", 2021 IEEE 30th International Symposium on
Industrial Electronics (ISIE), pp. 1-6,
DOI 10.1109/isie45552.2021.9576221, June 2021,
<https://doi.org/10.1109/isie45552.2021.9576221>.
[L2Virt] Kreger-Stickles, L., "First principles: L2 network
virtualization for lift and shift", Oracle Cloud
Infrastructure Blog, 9 February 2021,
<https://blogs.oracle.com/cloud-infrastructure/post/first-
principles-l2-network-virtualization-for-lift-and-shift>.
[MADTLS] Wagner, E., Heye, D., Serror, M., Kunze, I., Wehrle, K.,
and M. Henze, "Madtls: Fine-grained Middlebox-aware End-
to-end Security for Industrial Communication",
arXiv:2312.09650, DOI 10.48550/ARXIV.2312.09650, 2023,
<https://doi.org/10.48550/ARXIV.2312.09650>.
[MASTODON] Raman, A., Joglekar, S., Cristofaro, E., Sastry, N., and
G. Tyson, "Challenges in the Decentralised Web: The
Mastodon Case", Proceedings of the Internet Measurement
Conference, pp. 217-229, DOI 10.1145/3355369.3355572,
October 2019, <https://doi.org/10.1145/3355369.3355572>.
[Microservices]
Richardson, C., "What are microservices?",
<https://microservices.io/>.
[MPI] Vishnu, A., Siegel, C., and J. Daily, "Scaling Distributed
Machine Learning with In-Network Aggregation",
arXiv:1603.02339v2, August 2017,
<https://arxiv.org/pdf/1603.02339.pdf>.
[Multi2020]
Sobrinho, J. and M. Ferreira, "Routing on Multiple
Optimality Criteria", Proceedings of the Annual conference
of the ACM Special Interest Group on Data Communication on
the applications, technologies, architectures, and
protocols for computer communication, pp. 211-225,
DOI 10.1145/3387514.3405864, July 2020,
<https://doi.org/10.1145/3387514.3405864>.
[NetworkedVR]
Ruan, J. and D. Xie, "Networked VR: State of the Art,
Solutions, and Challenges", Electronics, vol. 10, no. 2,
p. 166, DOI 10.3390/electronics10020166, January 2021,
<https://doi.org/10.3390/electronics10020166>.
[P4] Bosshart, P., Daly, D., Gibb, G., Izzard, M., McKeown, N.,
Rexford, J., Schlesinger, C., Talayco, D., Vahdat, A.,
Varghese, G., and D. Walker, "P4: programming protocol-
independent packet processors", ACM SIGCOMM Computer
Communication Review, vol. 44, no. 3, pp. 87-95,
DOI 10.1145/2656877.2656890, July 2014,
<https://doi.org/10.1145/2656877.2656890>.
[P4-SPLIT] Singh, H. and M. Montpetit, "Requirements for P4 Program
Splitting for Heterogeneous Network Nodes", Work in
Progress, Internet-Draft, draft-hsingh-coinrg-reqs-p4comp-
03, 18 February 2021,
<https://datatracker.ietf.org/doc/html/draft-hsingh-
coinrg-reqs-p4comp-03>.
[RFC7272] van Brandenburg, R., Stokking, H., van Deventer, O.,
Boronat, F., Montagud, M., and K. Gross, "Inter-
Destination Media Synchronization (IDMS) Using the RTP
Control Protocol (RTCP)", RFC 7272, DOI 10.17487/RFC7272,
June 2014, <https://www.rfc-editor.org/info/rfc7272>.
[RFC8039] Shpiner, A., Tse, R., Schelp, C., and T. Mizrahi,
"Multipath Time Synchronization", RFC 8039,
DOI 10.17487/RFC8039, December 2016,
<https://www.rfc-editor.org/info/rfc8039>.
[RÜTH] Rüth, J., Glebke, R., Wehrle, K., Causevic, V., and S.
Hirche, "Towards In-Network Industrial Feedback Control",
Proceedings of the 2018 Morning Workshop on In-Network
Computing, pp. 14-19, DOI 10.1145/3229591.3229592, August
2018, <https://doi.org/10.1145/3229591.3229592>.
[SA2-5GLAN]
3GPP-5glan, "SP-181129, Work Item Description,
Vertical_LAN(SA2), 5GS Enhanced Support of Vertical and
LAN Services", 3GPP , 2021,
<https://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_82/Docs/SP-
181120.zip>.
[SarNet2021]
Glebke, R., Trossen, D., Kunze, I., Lou, D., Ruth, J.,
Stoffers, M., and K. Wehrle, "Service-based Forwarding via
Programmable Dataplanes", 2021 IEEE 22nd International
Conference on High Performance Switching and Routing
(HPSR), pp. 1-8, DOI 10.1109/hpsr52026.2021.9481814, June
2021, <https://doi.org/10.1109/hpsr52026.2021.9481814>.
[SILKROAD] Miao, R., Zeng, H., Kim, C., Lee, J., and M. Yu,
"SilkRoad: Making Stateful Layer-4 Load Balancing Fast and
Cheap Using Switching ASICs", Proceedings of the
Conference of the ACM Special Interest Group on Data
Communication, pp. 15-28, DOI 10.1145/3098822.3098824,
August 2017, <https://doi.org/10.1145/3098822.3098824>.
[SPLITTLS] Naylor, D., Schomp, K., Varvello, M., Leontiadis, I.,
Blackburn, J., Lopez, D., Papagiannaki, K., Rodriguez
Rodriguez, P., and P. Steenkiste, "Multi-Context TLS
(mcTLS): Enabling Secure In-Network Functionality in TLS",
ACM SIGCOMM Computer Communication Review, vol. 45, no. 4,
pp. 199-212, DOI 10.1145/2829988.2787482, August 2015,
<https://doi.org/10.1145/2829988.2787482>.
[Stoyanov] Stoyanov, R. and N. Zilberman, "MTPSA: Multi-Tenant
Programmable Switches", Proceedings of the 3rd P4 Workshop
in Europe, pp. 43-48, DOI 10.1145/3426744.3431329,
December 2020,
<https://dl.acm.org/doi/10.1145/3426744.3431329>.
[Sultana] Sultana, N., Sonchack, J., Giesen, H., Pedisich, I., Han,
Z., Shyamkumar, N., Burad, S., DeHon, A., and B. T. Loo,
"Flightplan: Dataplane Disaggregation and Placement for P4
Programs",
<https://flightplan.cis.upenn.edu/flightplan.pdf>.
[TIRPITZ-REDUCIO]
Tirpitz, L., Kunze, I., Niemietz, P., Gerhardus, A. K.,
Bergs, T., Wehrle, K., and S. Geisler, "Reducio: Data
Aggregation and Stability Detection for Industrial
Processes Using In-Network Computing", DEBS '25:
Proceedings of the 19th ACM International Conference on
Distributed and Event-based Systems, pp. 98-109,
DOI 10.1145/3701717.3730547, June 2025,
<https://doi.org/10.1145/3701717.3730547>.
[TLSSURVEY]
de Carné de Carnavalet, X. and P. van Oorschot, "A Survey
and Analysis of TLS Interception Mechanisms and
Motivations: Exploring how end-to-end TLS is made 'end-to-
me' for web traffic", ACM Computing Surveys, vol. 55, no.
13s, pp. 1-40, DOI 10.1145/3580522, July 2023,
<https://doi.org/10.1145/3580522>.
[TOSCA] Rutkowski, M., Ed., Lauwers, C., Ed., Noshpitz, C., Ed.,
and C. Curescu, Ed., "TOSCA Simple Profile in YAML Version
1.3", OASIS Standard, February 2020, <https://docs.oasis-
open.org/tosca/TOSCA-Simple-Profile-YAML/v1.3/os/TOSCA-
Simple-Profile-YAML-v1.3-os.pdf>.
[TS23.501] 3GPP, "System Architecture for the 5G System; Stage 2
(Rel.17)", 3GPP TS 23.501, 2021,
<https://www.3gpp.org/DynaReport/23501.htm>.
[TS23.502] 3GPP, "Procedures for the 5G System; Stage 2 (Rel.17)",
3GPP TS 23.502, 2021,
<https://www.3gpp.org/DynaReport/23502.htm>.
[USE-CASE-AN]
Kunze, I., Hong, J., Wehrle, K., Trossen, D., Montpetit,
M., de Foy, X., Griffin, D., and M. Rio, "Use Case
Analysis for Computing in the Network", Work in Progress,
Internet-Draft, draft-irtf-coinrg-use-case-analysis-02, 4
December 2024, <https://datatracker.ietf.org/doc/html/
draft-irtf-coinrg-use-case-analysis-02>.
[VESTIN] Vestin, J., Kassler, A., and J. Akerberg, "FastReact: In-
Network Control and Caching for Industrial Control
Networks using Programmable Data Planes", 2018 IEEE 23rd
International Conference on Emerging Technologies and
Factory Automation (ETFA), pp. 219-226,
DOI 10.1109/etfa.2018.8502456, September 2018,
<https://doi.org/10.1109/etfa.2018.8502456>.
[WirelessNet2024]
Jia, J., Yang, L., Chen, J., Ma, L., and X. Wang, "Online
delay optimization for MEC and RIS-assisted wireless VR
networks", Wireless Networks, vol. 30, no. 4, pp.
2939-2959, DOI 10.1007/s11276-024-03706-4, March 2024,
<https://doi.org/10.1007/s11276-024-03706-4>.
The authors would like to thank Eric Wagner for providing text on the security considerations and Jungha Hong for her efforts in continuing the work on the use case analysis document that has largely sourced the preliminary categorization section of this document.
著者は、セキュリティに関する考慮事項に関するテキストを提供してくれたEric Wagnerと、この文書の予備分類セクションを主に調達したユースケース分析文書の作業を継続する努力について、Jungha Hongに感謝したいと思います。
The authors would further like to thank Chathura Sarathchandra, David Oran, Phil Eardley, Stuart Card, Jeffrey He, Toerless Eckert, and Jon Crowcroft for reviewing earlier versions of the document, Colin Perkins for his IRTF chair review, and Jerome Francois for his thorough IRSG review.
著者はさらに、Chathura Sarathchandra、David Oran、Phil Aehdley、Stuart Card、Jeffrey He、Toerless Eckert、およびJon Crowcroftに、ドキュメントの以前のバージョンをレビューしてくれたことに感謝します。
Ike Kunze
RWTH Aachen University
Ahornstr. 55
D-52074 Aachen
Germany
Email: kunze@comsys.rwth-aachen.de
Klaus Wehrle
RWTH Aachen University
Ahornstr. 55
D-52074 Aachen
Germany
Email: wehrle@comsys.rwth-aachen.de
Dirk Trossen
DaPaDOT Tech UG (haftungsbeschränkt)
Palestrinastr. 7A
D-80639 Munich
Germany
Email: dirk@dapadot-tech.eu
Marie-Jose Montpetit
SLICES-RI
Paris
France
Email: marie-jose.montpetit@slices-ri.eu
Xavier de Foy
InterDigital Communications, LLC
1000 Sherbrooke West
Montreal H3A 3G4
Canada
Email: xavier.defoy@interdigital.com
David Griffin
University College London
Gower St
London
WC1E 6BT
United Kingdom
Email: d.griffin@ucl.ac.uk
Miguel Rio
University College London
Gower St
London
WC1E 6BT
United Kingdom
Email: miguel.rio@ucl.ac.uk