<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      docName="draft-zhao-detnet-enhanced-use-cases-05"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">

 <!-- ***** FRONT MATTER ***** -->

 <front>

   <title abbrev="Enhanced Use Cases for Scaling Deterministic Networks">Enhanced Use Cases for Scaling Deterministic Networks</title>
    <seriesInfo name="Internet-Draft" value="draft-zhao-detnet-enhanced-use-cases-05"/>

    <author fullname="Junfeng Zhao" initials="J" surname="Zhao">
      <organization>CAICT</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>zhaojunfeng@caict.ac.cn</email>
      </address>
    </author>	
   
   <author fullname="Quan Xiong" initials="Q" surname="Xiong">
      <organization>ZTE Corporation</organization>
      <address>
        <postal>
          <street/>
         <city></city>
          <region/>
          <code/>
          <country>China</country>
        </postal>
        <phone></phone>
        <email>xiong.quan@zte.com.cn</email>
     </address>
    </author>
	
 <author fullname="Zongpeng Du" initials="Z" surname="Du">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country>China</country>
        </postal>

        <phone></phone>

        <email>duzongpeng@chinamobile.com</email>
      </address>
    </author>
	
 <author fullname="Muhammad Awais Jadoon" initials="M" surname="Jadoon">
      <organization>InterDigital</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>Muhammad.AwaisJadoon@InterDigital.com</email>
      </address>
    </author>
	
 <author fullname="Luis M. Contreras" initials="L.M." surname="Contreras">
      <organization>Telefonica</organization>

      <address>
        <postal>
          <street></street>
          
          <city></city>
          
          <region></region>
  
          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>luismiguel.contrerasmurillo@telefonica.com</email>
      </address>
    </author>	
	

   <area>Routing</area>
    <workgroup>DETNET</workgroup>
   <keyword></keyword>
   
   <abstract>

    <t>This document describes use cases and network requirements for 
	scaling deterministic networks which is not covered in RFC8578,
	such as industrial internet, high experience video, intelligent 
	computing, and ISAC-enabled smart factory and outlines the common
	properties implied by these use cases.</t>
	  
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default"> <name>Introduction</name>
	
    <t>According to <xref target="RFC8655" pageno="false" format="default"/>, Deterministic Networking (DetNet) operates 
	at the IP layer and delivers service which provides extremely low data
    loss rates and bounded latency within a network domain. The bounded 
	latency indicates the minimum and maximum end-to-end latency from source 
	to destination and bounded jitter (packet delay variation). 
	<xref target="RFC8578" format="default"/> has presented use cases for 
	diverse industries and these use cases differ in their network 
	topologies and requirements. It should provide specific desired 
	behaviors in DetNet. </t>
	
	<t><xref target="I-D.ietf-detnet-scaling-requirements"></xref> focus
	on the scaling deterministic networks and describes the enhanced 
	requirements for DetNet enhanced data plane including the 
	deterministic latency guarantees and it also mentioned the 
	enhanced DetNet should support different levels of application
	requirements which is important for the DetNet deployment.
	There are a variety of use cases in scaling deterministic 
	networks which is not covered in <xref target="RFC8578" format="default"/>. 
	It is required to provide the typical use cases for scaling
	deterministic networks and analyze the SLAs requirements and
	desired behaviors in enhanced DetNet.</t>
	
	<t>The industries covered by the use cases in this document are:</t>
	
   <ul spacing="normal">
   <li>Industrial Internet (section 3.1)</li>
   <li>High Experience Video (section 3.2)</li>
   <li>Intelligent Computing (section 3.3)</li>
   <li>ISAC-Enabled Smart Factory(section 3.4)</li>
   </ul>
	
	 
	<t>This document describes use cases and network requirements for 
	scaling deterministic networks including industrial internet, 
	high experience video and intelligent computing and outlines
	the common properties implied by these use cases.</t>
	    
      <section numbered="true" toc="default"><name>Requirements Language</name>
	  
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in <xref target="RFC2119" format="default">RFC 2119</xref>.</t>
	   
      </section>
    </section>
	
    <section anchor="Terminology" numbered="true" toc="default"> <name>Terminology</name>
	<t>The terminology is defined as <xref target="RFC8655" pageno="false" format="default"/> and
	<xref target="RFC8578" pageno="false" format="default"/>.</t>
     
    </section>
	
    <section numbered="true" toc="default"><name>Enhanced Use Cases and Network Requirements</name>

	 
    <section numbered="true" toc="default"> <name>Industrial Internet</name>
	
    <section numbered="true" toc="default"> <name>Use Case Description</name>
	
	<t>In the industrial internet, the entire industrial process can be 
	roughly divided into research and development design, production
	manufacturing, operation and maintenance services. The typical 
	application prospects of deterministic networks mainly include 
	ultra-high definition video, cloud-based robots, remote control, 
	machine vision, and cloud-based AGV. The scenarios such  as machine
	vision, AGV intelligent control, remote control, and AR assisted
	robotic arm control demand deterministic requirements.</t>
	
    <section numbered="true" toc="default"> <name>Machine Vision</name>	

    <t>The machine vision system needs to achieve real-time remote
	monitoring function, which requires high-speed and large 
	connectivity characteristics. It can monitor the production 
	process execution management system (MES) of manufacturing 
	enterprises through mobile and portable terminals without 
	entering the workshop, and obtain the operating status of 
	the visual inspection system, such as normal operating time, 
	effective operating time, fault cause etc. It is bandwidth 
	sensitive and demand cloud-based deployment and wide area  
	networks requirements.</t>
	
	<t>The following table shows the main network requirements 
	of machine vision.(These metrics are based on 3GPP Standard
	3GPP TS 22.104, 3GPP TR 22.261, and 3GPP TR 22.829.)</t>
 
 
  <figure title="Requirements of Machine Vision" align="center" suppress-title="false" alt="" width="" height="">
   <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">	
   
   +---------------------------------+---------------------------------+
   |    Machine Vision Requirement   |            Attribute            |
   +---------------------------------+---------------------------------+
   |      Bandwidth                  |   Real time upload of image     |
   |                                 |   information:>50M              |
   |                                 |                                 |
   |     One-way maximum delay       |              10 ms              |
   |                                 |                                 |
   |           Availability          |             99.99%              |
   +---------------------------------+---------------------------------+
   
   	   </artwork>
 </figure>
 
</section>	
 

    <section numbered="true" toc="default"> <name>Remote Control</name> 
	
	<t>Remote control can ensure personnel safety, improve production
	efficiency, and achieve assistance from multiple production units. 
	In order to achieve the effect of remote control, the controller 
	needs to send status information to the controller through a 
	communication network based on remote perception. The controller
	analyzes and makes decisions based on the received status information, 
	and then sends corresponding action instructions to the controller 
	through the communication network. The controller executes the 
	corresponding actions based on the received action instructions, 
	completing the remote control process. In order to guarantee control 
	effectiveness, communication network latency, jitter, and reliability
	are even more important. The typical application is cloud-based PLC 
	(Programmable Logic Controller). It is jitter sensitive and  
    cloud-based PLC demand wide area networks requirements.</t>
	
	<t>The following table describes requirements of Cloud-based PLC.
	(These metrics are based on 3GPP Standard 3GPP TS 22.104, 3GPP TR 
	22.261, and 3GPP TR 22.829.)</t>

	 <figure title="Requirements of Cloud-based PLC" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">	
		 
   +-------------------------------+-----------------------------------+
   |  Cloud-based PLC Requirement  |            Attribute              |
   +-------------------------------+-----------------------------------+
   |     Bandwidth                 | Image/video stream upload,        |      
   |                               |  upstream>50Mbps;                 |      
   |                               | PLC control command issued,       |      
   |                               |  downstream>50kbps;               |      
   |                               |                                   |      
   |      One-way maximum delay    |Within workshop level equipment:1ms| 
   |                               |Workshop level equipment room:10ms | 
   |                               |Remote operation in the park/city/ |
   |                               |wide area: image upstream:20ms;    |
   |                               |Command issuance:10ms;             |
   |                               |                                   |
   |          Maximum jitter       |      Less than 100 us             |
   |                               |                                   |
   |           Availability        |             99.999%               |
   +-------------------------------+-----------------------------------+
 
   	   </artwork>
    </figure>
	
	</section>
	
	<section numbered="true" toc="default"> <name>AGV Intelligent Control</name> 
	
	<t>Automated Guided Vehicle (AGV) is an intelligent device widely 
	used in highly automated places such as factory workshops, airports, 
	ports, freight warehouses, etc. It generally consists of three parts: 
	walking, navigation, and control systems. The automated AGV is equipped
	with a camera to capture the scene in front of the vehicle and upload 
	it to the MEC and navigation system in real-time through a 5G module 
	for image analysis and route planning, achieving fully automated logistics
	transportation. AGV has a certain driving speed and is often used in 
	cluster operation scenarios. Therefore, a network connection with 
	high deterministic delay and jitter is required to transmit control 
	signals. </t>
	
	<t>The following table describes requirements of AGV intelligent
	control.(These metrics are based on 3GPP Standard 3GPP TS 22.104, 
	3GPP TR 22.261, and 3GPP TR 22.829.)</t>
 
 	 <figure title="Requirements of AGV Intelligent Control" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">

   +-----------------------------+--------------------------------------+
   | AGV Intelligent Control     |                                      |
   |              Requirement    |            Attribute                 |
   +-----------------------------+--------------------------------------+
   |     Bandwidth               |Schedule communication:>1Mbps,        |
   |                             |Real time communication:1Mbps~200Mbps |      
   |                             |Visual: 10Mbps~1Gbps                  |          
   |                             |                                      |      
   |    One-way maximum delay    |Schedule communication:100ms          | 
   |                             |Dispatching communication:100ms       | 
   |                             |Real time communication:20ms~40ms     |
   |                             |Visual: 10ms~100ms                    |
   |     Availability            |             99.9999%                 |
   +-----------------------------+--------------------------------------+		 
   
   	   </artwork>
     </figure>
 
	 
    </section>

	
    <section numbered="true" toc="default"> <name>AR Assistance</name>
   <t>With the intelligent and networked transformation and upgrading 
   of industrial manufacturing equipment, more and more AR assisted 
   intelligent robots will be used in advanced manufacturing. At the 
   same time, there are scenarios where multiple robot systems work 
   together, such as welding, stamping, etc. The robotic arm is the 
   most widely used automated mechanical device in the field of robotics
   technology, in areas such as industrial manufacturing, medical 
   treatment, entertainment services, military, semiconductor manufacturing, 
   and space exploration. The more axis joints of the AR assisted 
   robotic arm, the higher the degree of freedom, and the larger the 
   angle of the operating range. </t>
   
   <t>The following table describes requirements of AR Assistance.
   (These metrics are based on 3GPP Standard 3GPP TS 22.104, 
	3GPP TR 22.261, and 3GPP TR 22.829.)</t>
   
     <figure title="Requirements of AR Assistance" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">

   +---------------------------+----------------------------+
   |  AR Assistance Requirement|            Attribute       |
   +---------------------------+----------------------------+
   |     Bandwidth             | Maintenance guidance:      |      
   |                           |  downstream>50Mbps         |      
   |                           |  upstream > 20Mbps         |      
   |                           |  downstream>50kbps         |      
   |                           | Auxiliary assembly: >50Mbps|
   |                           |  downstream: 1Mbps~30Mbps  | 
   |                           |                            |   
   |  One-way maximum delay    |Maintenance guidance:20ms   | 
   |                           |Auxiliary assembly:10ms     | 
   |                           |                            |
   |    Maximum jitter         |      Less than 500 us      |
   |                           |                            |
   |    Availability           |        99.999%             |
   +---------------------------+----------------------------+		 

   	   </artwork>
     </figure>
   
   </section>
	
	</section>
	
	<section numbered="true" toc="default"> <name>Requests to the IETF</name>
	
   <ul spacing="normal">
   
   <li>Real-time remote monitoring, which requires high-speed connectivity </li>
   <li>Cloud-based deployment, which requires transmission through multiple heterogeneous networks </li>
   <li>Cloud-based centralized management</li> 
   <li>Remote control is jitter sensitive, e.g. less than 100us</li> 
   <li>Industrial camera images with high definition, with little or
   no compression, which requires high bandwidth</li>
   <li>Low end-to-end delay requirements differ from applications
   and services, such as 10ms and 20ms</li>
   </ul>
	</section>
	
	</section>
	
	<section numbered="true" toc="default"> <name>High Experience Video</name>
	
	<section numbered="true" toc="default"> <name>Use Case Description</name>
	
	<t>High Experience Video refers to video content that delivers an 
	exceptional viewing experience through advanced technologies and 
	production techniques. It demands high-quality transmission to 
	ensure that the content is delivered without compromising its 
	integrity and impact. High Experience Video relies on deterministic
	networks to deliver the best possible viewing experience, which
	requires a combination of low latency, low jitter, high bandwidth,
	and high reliability. The typical scenarios of High Experience Video 
	involve applications that have high requirements for video quality, 
	transmission speed, and user experience such as cloud VR and AR,
	cloud games and cloud live streaming.</t>
	
    <section numbered="true" toc="default"> <name>Cloud VR and AR</name>
	
	<t>Augmented Reality (AR) or Virtual Reality (VR) media applications, 
	collectively called eXtended Reality (XR) applications place extremely
	high demands on network transmission including high throughput, low 
	latency, and high reliability. The key feature of cloud VR/AR
	is that content and rendering is on the cloud. By utilizing the cloud 
	capabilities, VR/AR user experience is improved and terminal costs
	are reduced. Cloud AR/VR services are latency sensitivity, and 
	different levels of experience require differentiated latency. 
	Cloud VR/AR rendering and streaming latency are divided into three
	parts: cloud processing, network transmission, and terminal processing.
	Cloud VR/AR operation latency is divided into cloud rendering latency 
	and terminal secondary rendering and refresh rendering processes.</t>
	
	<t>Moreover, AR/VR applications typically involve a large amount of 
	data transmission, such as high-definition video streams, real-time 
	rendering data. For some cases, a single packet loss during transmission
	will it affect the integrity of the entire application. So AR/VR 
	applications require ultra-low packet loss such as no more then 0.001% 
	and for particular packets, it demands zero packet loss.</t> 

	
	<t>The following table describes requirements of Cloud VR/AR. (These 
	metrics are based on 3GPP TR 22.261).</t>
	
	<figure title="The Requirements of Cloud VR/AR" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
+----------------------+-----------+---------------------+----------------+
|    Requirement       | Bandwidth |One-way maximum delay|Packet loss rate|
+----------------------+-----------+---------------------+----------------+
| Cloud VR/AR Video    |downstream |  50ms               |no more than    |
|  comfortable         | >75Mbps   |                     |0.001%          |
|  experience          |           |                     |                |
+----------------------+-----------+---------------------+----------------+
| Cloud VR/AR Video    |downstream |  50ms               |no more than    |
|comfortable experience|>140Mbps   |                     |0.001%          |
|full perspective      |           |                     |                |
+----------------------+-----------+---------------------+----------------+ 
| Cloud VR/AR strong   |downstream |  15ms               |no more than    |
|interaction           |>260Mbps   |                     |0.001%          |
|comfortable experience|           |                     |                |
|I frame and P frame   |           |                     |                |
+----------------------+-----------+---------------------+----------------+ 
| Cloud VR/AR strong   |downstream |  8ms                |no more than    |  
|interaction           |1Gbps      |                     |0.0001%         |   
|8K ideal experience   |           |                     |                |
|I frame and P frame   |           |                     |                |
+----------------------+-----------+---------------------+----------------+  
   	   </artwork>
    </figure> 
	
	
	</section>
	
	<section numbered="true" toc="default"> <name>Cloud Games</name>
	
	<t>Cloud Game is an online gaming technology based on cloud computing
	technology. Cloud gaming technology enables lightweight devices with 
	relatively limited graphics processing and data computing capabilities
	to run high-quality games. In cloud game scenarios, game related computing
	is not run on the user terminal, but on a cloud server, which renders the
	game scene as a video and audio stream and transmits it to the user 
	terminal through the network. The user's cloud gaming experience relies
	on a high-quality, low latency network environment. </t>
	
	<t>The following table describes requirements of Cloud Games:</t>
	
	<figure title="Requirements of Cloud Games" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
+----------------------+-----------+---------------------+----------------+
|    Requirement       | Bandwidth |One-way maximum delay|Video resolution|
+----------------------+-----------+---------------------+----------------+
| Junior level         | >8Mbps    |  150ms              |720P            |
+----------------------+-----------+---------------------+----------------+
| 3A professional level| >12Mbps   |  60ms               |1080P           |
+----------------------+-----------+---------------------+----------------+ 
| Level of esports     | >40Mbps   |  60ms               |4K              | 
+----------------------+-----------+---------------------+----------------+   
   	   </artwork>
    </figure> 
	
	</section>
	
    <section numbered="true" toc="default"> <name>Cloud Live Streaming</name>
	
	<t>For scenarios such as concerts, press conferences, sports events, 
	and live events, cloud live streaming uses 5G uplink high bandwidth 
	to transmit 8K/VR videos. Combined with various applications such as
	video analysis based on live streaming services, character and scene
	recognition, real-time presentation of athlete and event data, and VR
	live streaming interaction, it provides a brand new and rich event 
	viewing experience. </t>
	
	<t>The following table describes requirements of Cloud live streaming:</t>
	
	<figure title="Requirements of Cloud Live Streaming" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">	
   +------------------------+---------------------+
   | 8K live streaming      |  Attribute          |
   | 8K video feedback      |                     |    
   +------------------------+---------------------+
   |     Bandwidth          |  upstream>100Mbps   |       
   |                        |                     |   
   |  One-way maximum delay |  200ms              | 
   |                        |                     |
   |    Availability        |  99.9%              |
   |                        |                     |
   |   Frame rate           |  60                 |
   +------------------------+---------------------+	
   	   </artwork>
    </figure> 
	
	</section>

     </section>
	<section numbered="true" toc="default"> <name>Requests to the IETF</name>
	
	 <ul spacing="normal">
	 
   <li>High requirements for video quality and transmission speed</li>
   <li>Cloud processing with real-time interaction </li>
   <li>Cloud-based deployment, which requires transmission through multiple heterogeneous networks </li>
   <li>No jitter requirements</li>
   <li>Packet loss is less than 0.001% or zero</li>
   <li>End-to-end delay requirements differ from applications
   and services, such as 8ms, 15ms, 50ms, 150ms, 200ms and so on</li>
   </ul>
	</section>
	
   </section>

    <section numbered="true" toc="default"> <name>Intelligent Computing</name>
	
    <section numbered="true" toc="default"> <name>Use Case Description</name>
	<t>Intelligent computing refers to the integration of artificial 
	intelligence (AI) techniques with computational methods to enhance
	the performance, efficiency, and capabilities of computing systems. 
	It involves the use of algorithms, machine learning models, and 
	other AI approaches to solve complex problems, analyze large datasets,
	and improve decision-making processes. Intelligent Computing has 
	specific requirements for deterministic networks to ensure reliable 
	and predictable performance such as predictable latency, low packet 
	loss rate, high throughput and reliability. The typical scenarios 
	involve applications such as AI-based scientific research and
	autonomous vehicles and so on.</t>
	
    <section numbered="true" toc="default"> <name>Scientific Research</name>

	<t>Intelligent computing is used to provide computing and data 
	analysis capabilities, which are crucial for handling large-scale
	scientific simulations and datasets such as astronomy, climate 
	science, and bioinformatics. In scientific research, a large amount 
	of computing power resources such as CPU, GPU, memory, and other
	P-level or higher are usually required. The network needs to 
	provide services for data volume of 10G to 100G or above, which
	requires high bandwidth, high reliability and high throughput with
	ultra-low packet loss. Many applications in scientific research, such 
	as remote observations, real-time data analysis, and distributed 
	computing, require networks to provide stable low latency and
	high reliability. It must provide millisecond or even microsecond
	level latency and jitter guarantees. For example, in nuclear 
	fusion experiments, the carrier network is required to have
	99.999% availability.</t>
	
	<t>Furthermore, scientific research may require massive data
	transmission between HPCs. The scenario of thousands of kilometers
	of big data migration mainly refers to the high-throughput transmission
	of massive data between scientific research institutions. At present,
	research institutions in some countries, such as the US ESnet6 and 
	the EU EuroHPC program, are deploying wide area RDMA networks to 
	support the construction and operation of high-performance 
	computing and data interconnection infrastructure. In this scenario,
	data transmission is usually carried out regularly or in demand, 
	with each transmission ranging from a few terabytes to several 
	hundred terabytes, data transmission costs and security are both required. </t>
	</section>
	
   <section numbered="true" toc="default"> <name>Autonomous Vehicles</name>
   <t>Intelligent computing is used in the development of self-driving 
   cars, which rely on AI algorithms for perception, decision-making, 
   and control. Autonomous vehicles refers to the technology of vehicles
   that are capable of navigating without the need for human input such 
   as identifying other vehicles, pedestrians, and traffic signals. 
   It relies heavily on deterministic forwarding to ensure safe, efficient,
   and reliable operation. It is also challenging for big data management
   of autonomous driving. Vehicles record data from 4K HD cameras, laser
   scanners, and radars on the road. Each vehicle can generate 80TB of 
   data per day, which requires data-intensive transmission.  </t>
   
   <t>V2X (Vehicle-to-Everything) is a fundamental component of the 
   autonomous driving ecosystem, providing the necessary communication
   backbone that enables vehicles to interact with their environment 
   in a safe and efficient manner. V2X provides the communication 
   infrastructure that enables vehicles to exchange information with 
   each other (V2V), with roadside infrastructure (V2I), with 
   pedestrians (V2P), and with the network (V2N). This exchange of 
   information is crucial for autonomous vehicles to make informed 
   decisions, improve navigation accuracy, and enhance overall road safety.
   The following table describes requirements of 5G V2X which is divided 
   into four scenarios. (These metrics are based on 3GPP TR 22.886)</t>
	
	<figure title="The Requirements of Autonomous Vehicles" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
+----------------------+---------------------+--------------+
|    Requirement       | Communication Delay | Availability |
+----------------------+---------------------+--------------+
| Vehicles Platooning  |    10~25ms          | 99%~99.99%   | 
+----------------------+---------------------+--------------+
| Extended Sensors     |    3~100ms          | 99%~99.999%  |  
+----------------------+---------------------+--------------+ 
| Advanced Driving     |    3~100ms          | 99%~99.999%  |
+----------------------+---------------------+--------------+ 
| Remote Driving       |    5ms              |  99.999%     |  
+----------------------+---------------------+--------------+  

   	   </artwork>
    </figure> 
   
	</section>
    </section>
	
    <section numbered="true" toc="default"> <name>Requests to the IETF</name>
	
    <ul spacing="normal">
   <li>Real-time communication</li>
   <li>Data-intensive transmission with high-throughput and ultra-low packet loss</li>
   <li>Low bounded latency, such as us~ms</li>
   <li>High availability, such as 99.999%</li>
   </ul>
	
	</section>
   </section>
   
   <section numbered="true" toc="default"> <name>ISAC-Enabled Smart Factory</name>
   
    <section numbered="true" toc="default"> <name>Use Case Description</name>
	
	<t>A Smart Factory enabled by Integrated Sensing and Communication 
	(ISAC)-enabled cellular networks utilizes Radio Frequency (RF) signals
	(aka Sensing Signals) to construct an environmental mapping, detect and
	track objects, enable precise localization, and facilitate collision 
	avoidance for Autonomous Guided Vehicles (AGVs) and robotic systems. 
	ISAC systems encompass one or more Sensing Transmitters (Tx) that 
	transmit sensing signals and one or more Sensing Receivers (Rx) that 
	generate Sensing Data. Sensing Data are used in the cellular network 
	to describe the detected target objects in shape, location, orientation, 
	material, and spatial relationships among each other. Sensing Data are 
	then exposed to the Sensing Service Consumer that requested them and
	are used for real-time monitoring and decision-making by a Sensing 
	Service Consumer. This reduces reliance on dedicated sensors while 
	optimizing communication resources. Similar use cases have been 
	considered in ETSI ISG ISAC.  The described workflow shown in Figure 
	and illustrates a DetNet-enabled cellular network as described in 
	3GPP TS 23.501, that contains core network (CN) and Sensing Rxs, e.g., 
	user equipment (UE) or base station (BS), and a Sensing Service 
	Consumer operating.</t>
	
	<figure title="Sensing Rx in the smart factory generating Sensing Data from the Sensing Signals and sending it to a a cellular core network and Sensing Service Consumer for real-time decision making" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
                      Sensing                                     Sensing
+------------------+  Data    +---------------------------------+ Data    +---------------+
| Sensing Service  +----------| Cellular Core Network           +---------| Sensing Rx    |
|                  |          |                                 |         |  (UE, BS)     |
| Consumer         |          |                                 |         |               |
+------------------+          |                                 |         +---------------+        
                              +---------------------------------+
\___________________/        \___________________________________________________________/
  DetNet-Enabled                        DetNet-Enabled
  Data Network                          Cellular System

   	   </artwork>
    </figure> 	
	
	<t>DetNet is critical for ensuring low-latency, bounded jitter, and
	high-reliability exchange of Sensing Data between Sensing Rxs and
	the network. The Sensing Data extracted from Sensing Signals at the
	Sensing Rx must be delivered deterministically to enable accurate 
	and timely control of factory operations, such as predictive maintenance,
	AGVs coordination, safety enforcement, and autonomous route planning
	for AGVs.</t>
	
	<section numbered="true" toc="default"> <name>Predictive Maintenance</name>
	
	<t>Predictive maintenance in a Smart Factory leverages ISAC to detect
	early signs of equipment wear, misalignment, or failures by analyzing
	environmental changes. The system can monitor machine vibrations, 
	structural integrity, and operational anomalies. </t>
	
   <t>To enable real-time fault detection and proactive maintenance, the
   network must support low-latency, high-reliability, and deterministic
   data delivery to ensure timely analysis and decision-making. Delays or
   packet loss in Sensing Data transmission can result in missed failure 
   indicators, leading to unplanned downtime and costly repairs.</t>
   
   	<figure title="The Requirements of Predictive Maintenance" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
+--------------+--------------------------------------------------+
|  Requirement |                Attributes                        |
+--------------+--------------------------------------------------+
|Bandwidth     |10Mbps~1Gbps (depending on sensing resolution)    | 
+--------------+--------------------------------------------------+ 
|One-way delay |less than 5ms (for real-time anomaly detection)   |     
+--------------+--------------------------------------------------+ 
|Maximum jitter|less than 50us(to ensure stable data transmission)|
+--------------+--------------------------------------------------+ 
|Availability  |99.999%(to prevent data loss and ensure           |
|              |continuous monitoring)                            |
+-----------------------------------------------------------------+  

   	   </artwork>
    </figure> 
	
	</section>
	
	<section numbered="true" toc="default"> <name>Real-Time Process Optimization</name>
	
	<t>In a Smart Factory, real-time process optimization relies on sensing
	to dynamically adjust production parameters, robotic operations, and
	workflow scheduling based on real-time environmental and operational
	data. Processed Sensing Data measured from Sensing Signals are used 
	to provide instantaneous feedback on equipment status, material flow, 
	and environmental conditions, enabling adaptive decision-making to 
	maximize efficiency and reduce downtime.</t>
	
    <t>To ensure precise control and automation, the network must provide
	ultra-low latency, deterministic jitter, and high availability to support
	time-sensitive end-to-end data exchange between sensing receivers and 
	the cellular network and between the cellular network and the control 
	systems. Any delay or jitter in data transmission can lead to 
	inefficiencies, product defects, or production line disruptions.</t>
	
  	<figure title="The Requirements of Real-Time Process Optimization" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
+--------------+--------------------------------------------------+
|  Requirement |                Attributes                        |
+--------------+--------------------------------------------------+
|Bandwidth     |100 Mbps~10 Gbps (depending on sensing resolution)|
+--------------+--------------------------------------------------+ 
|One-way delay |less than 1ms (for closed-loop process control)   |     
+--------------+--------------------------------------------------+ 
|Maximum jitter|less than 10us(for precise synchronization)       |
+--------------+--------------------------------------------------+ 
|Availability  |99.999%                                           |
+-----------------------------------------------------------------+  

   	   </artwork>
    </figure> 	
	
	</section>
	
    <section numbered="true" toc="default"> <name> Safety Control and Maintenance</name>
	
	<t>Safety control in a Smart Factory relies on ISAC-enabled RF-based 
	sensing to detect potential hazards, such as worker proximity to 
	dangerous machinery, unexpected obstacles in AGV paths, or emergency
	situations like fires or equipment failures. Unlike traditional 
	sensor-based systems, ISAC uses Sensing Signals (RF or non-RF) 
	to track moving objects, monitor workspaces, and trigger real-time 
	safety mechanisms without requiring additional sensing infrastructure.</t>
	
	<t>To ensure instantaneous hazard detection and response, the network
	must support ultra-low latency, high availability, and deterministic
	jitter in and end-to-end fashion to guarantee timely activation of 
	emergency protocols, such as stopping machines, rerouting AGVs, or 
	alerting human operators. Any delay or packet loss when exchanging 
	Sensing Data between Sensing Rxs and the cellular network or exchanging
	Sensing Results between the cellular network and the application could 
	result in serious safety risks, including workplace accidents and
	equipment damage.</t>
	
  	<figure title="The Requirements of Real-Time Process Optimization" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
+--------------+--------------------------------------------------+
|  Requirement |                Attributes                        |
+--------------+--------------------------------------------------+
|Bandwidth     |100 Mbps~10 Gbps (for real-time updates)          |
+--------------+--------------------------------------------------+ 
|One-way delay |less than 1ms (for immediate hazard response)     |     
+--------------+--------------------------------------------------+ 
|Maximum jitter|less than 10us(for precise situation)             |
+--------------+--------------------------------------------------+ 
|Availability  |99.999999%                                        |
+-----------------------------------------------------------------+  

   	   </artwork>
    </figure>	
	
	</section>	
	
	<section numbered="true" toc="default"> <name>Interconnection of Time Sensitive Domains</name>
   
   <t>Some industrial production environments are basing their internal communications on 
   layer-2 Time Sensitive Networking. The deterministic behavior is then constrained into 
   the boundaries of the factory domains.</t>

   <t>However, is can be of interest to interconnect such domains for centralizing 
   applications or functions relevant to the production context. In order to do so, 
   it is necessary to guarantee deterministic behavior as well in the network used 
   for interconnecting such domains.</t>

   <t>[5G-ACIA] describes some initial scenarios of DetNet and TSN interworking. 
   The purpose of this use case is to allow the practical interconnection of such
   domains. The expectation is that the interconnection of those domains handle 
   the flows exiting the TSN domains providing bounded latency and extremely 
   low losses when passing through the DetNet domain in a transparent manner.</t>
   
   </section>

	</section>
	<section numbered="true" toc="default"> <name>Requests to the IETF</name>
	<t>To support Smart Factory ISAC use cases, the following enhancements 
	to DetNet are required:</t>
	
    <ul spacing="normal">
    <li>Ultra-low latency networking (as low as 1ms) for closed-loop control and real-time process optimization.</li>
    <li>Stringent jitter requirements (as low as 10us) to support precise sensing-based control.</li>
    <li>High bandwidth support (up to 10Gbps) for high-resolution sensing data transmission.</li>
    <li>High availability (up to 99.999999%) to ensure robust industrial operations. </li>
	<li>Provide bounded latency for TSN flows</li>
    <li>Provide low packet losses, as low as the frame losses in TSN</li>
	<li>Requires DetNet and TSN interworking</li>
    </ul>
    <t>DetNet should provide predictable and deterministic communication for ISAC-enabled Smart 
	Factories, ensuring timely and precise Sensing Data delivery for industrial automation and 
	control operations.</t>
	</section>
   
   </section>
   
      </section>

   <section numbered="true" toc="default"> <name>Use Case Common Themes</name>
   
   <section numbered="true" toc="default"> <name>Requirements for DetNet Multi-domains</name>
   
   <t>Many applications require deterministic connectivity that spans multiple networks
   such as industrial automation, professional audio/video and electrical utilities 
   described in <xref target="RFC8578"></xref>. And the applications mentioned
   in this document also have the multi-domains requirements for DetNet such as 
   remote control, cloud VR and AR and ISAC-enabled smart factory. These 
   networks may be operated by different administrative domains, utilize varying 
   underlying link-layer technology domains (e.g.IP/MPLS, TSN, and RAW), or 
   be deployed as different control areas to ensure scalability through multiple
   centralized controllers.</t>
   
   <t>The networks and nodes in local area networks may be interconnected with 
   heterogeneous wide area networks such as DetNet and TSN interworking. For example, 
   in ISAC-enabled smart factory, factory domains may be interconnected for 
   centralizing applications or functions relevant to the production context. 
   The cross-domain scenarios are also particularly important in industrial 
   internet, where control systems need to span multiple facilities or production
   lines. The different administrative domains need to be interconnected to achieve 
   unified control over distributed systems, enabling efficient resource management 
   and real-time decision-making. And cloud-based deployment also requires 
   transmission through multiple heterogeneous networks when when organizations 
   need to integrate distributed resources and applications across different 
   network environments, enabling unified management and seamless operation 
   of hybrid cloud architectures.</t> 
   
   <t>The primary challenge lies in maintaining deterministic behavior across 
   domain boundaries, where traffic from one domain must seamlessly flow 
   through another domain while preserving bounded latency and low packet loss rates.
   The <xref target="I-D.bernardos-detnet-multi-domain-pce"></xref> discusses the
   framework and the specific requirements on multi-domain DetNet solutions.</t>
   
   </section>

   
   <section numbered="true" toc="default"> <name>Requirements for DetNet Service Classification</name>
   
   <t>The above applications differ in the network ranges and SLAs requirements
   such as bounded latency, jitter, bandwidth, availability and packet loss.
   The classification should consider the characteristics such as traffic 
   specification and service requirements. The following table summarizes 
   deterministic requirements of industrial internet, cloud video and 
   intelligent computing applications, etc.</t>
   	
	<figure title="Characteristics of Typical Applications" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">	

+---+------------+--------------------+---------------------------------------------------------+
|   | Use Cases  | Typical            |       Differentiated Deterministic Requirements         |
|   |            | Applications       +----------+----------+---------+-------------------------+
|   |            |                    |Bandwidth | Delay    |  Jitter |Packet Loss| Availability|
+---+------------+--------------------+----------+----------+---------+-----------+-------------+
| 1 |Industrial  |Machine Vision      |  Low     |  Low     |   N/A   |    N/A    |   Medium    |
|   |Internet    +--------------------+----------+----------+---------+-----------+-------------+
|   |            |Remote Control      |  Low     |  Low     |Ultra-low|    N/A    |   High      |          
|   |            +--------------------+----------+----------+---------+-----------+-------------+
|   |            |AGV Control         |Low~High  |Low~Medium| N/A     |    N/A    | Ultra-high  |
|   |	         +--------------------+----------+----------+---------+-----------+-------------+
|   |            |AR Assistance       | Low      | Low      |Ultra-low|    N/A    |   High      |  
+---+------------+--------------------+----------+----------+---------+-----------+-------------+
| 2 |High        |Cloud VR and AR     |Medium    | Low      |  N/A    | Ultra-low |    N/A      |
|   |Experience  |                    | ~High    |          |         | or zero   |             |
|   |Video       +--------------------+----------+----------+---------+-----------+-------------+
|   |            |Cloud Games         | Low      | High     |   N/A   |    N/A    |   N/A       |
|   |            +--------------------+----------+----------+---------+-----------+-------------+
|   |            |Cloud Live Streaming| Medium   | High     |   N/A   |    N/A    |   Medium    |            
+---+------------+--------------------+----------+----------+---------+-----------+-------------+
| 3 |Intelligent |Scientific Research |Ultra-high|  Low     |   N/A   | Ultra-low |  Ultra-high |
|   |Computing   |                    |          |          |         | or zero   |             |
|   |            +--------------------+----------+----------+---------+-----------+-------------+
|   |            |Autonomous Vehicles |Ultra-high|  Low     |   N/A   | Ultra-low |  Ultra-high | 
|   |            |                    |          |          |         | or zero   |             |     
+---+------------+--------------------+----------+----------+---------+-----------+-------------+
| 4 |ISAC-Enabled|Predictive          | Medium   | Ultra-low|Ultra-low| Ultra-low |    High     |
|   |Smart       |Maintenance         | ~High    |          |         |           |             |
|   |Factory     +--------------------+----------+----------+---------+-----------+-------------+
|   |            |Real-Time Process   | Medium   | Ultra-low|Ultra-low| Ultra-low |    High     |
|   |            |Optimization        | ~High    |          |         |           |             |       
|   |            +--------------------+----------+----------+---------+-----------+-------------+
|   |            |Safety Control      | Medium   | Ultra-low|Ultra-low| Ultra-low |    High     |
|   |            |and Maintenance     | ~High    |          |         |           |             |   
+---+------------+--------------------+----------+----------+---------+-----------+-------------+

   	   </artwork>
    </figure>  
	

   <t>Since the DetNet applications differ in their requirements, it demands
   specific desired deterministic behaviors. The DetNet flows MAY be
   classified based on the service SLAs requirements of applications in
   scaling networks as per <xref target="I-D.xiong-detnet-differentiated-detnet-qos"></xref>.
   The flow aggregation based on the classification of deterministic services 
   should be taken into considerations as discussed in <xref target="I-D.xiong-detnet-flow-aggregation"></xref>. 
   It is required to provide latency, bounded jitter and packet loss dynamically
   and flexibly in all scenarios for each characterized flow. </t>
   </section>
   
   <section numbered="true" toc="default"> <name>Requirements for Ultra-low or Zero Packet Loss</name> 
 
   <t>Some high-throughput, low-latency applications such as 
   intelligent computing demand ultra-low packet loss which is critical 
   to ensure real-time data processing, maintain data integrity, optimize
   resource utilization, and support scalable and reliable operations.
   And some applications such as AR/VR do not fit as payload into a 
   single IP packet and may be fragmented into multiple smaller chunks 
   as discussed in <xref target="I-D.rc-detnet-data-unit-groups"></xref>.
   It demands zero packet loss for some chunks while a single packet
   loss can lead to the loss of the whole application. The DetNet node 
   should provide the deterministic behavior to perform any DetNet 
   queuing, shaping, scheduling, ordering or dropping to guarantee
   the packet loss on particular packets. </t> 
   </section>   
   
	</section>
   
   <section  numbered="true" toc="default"> <name>Security Considerations</name>
   <t>Security considerations for DetNet are covered in the DetNet
   Architecture <xref target="RFC8655"></xref> and DetNet use cases
   <xref target="RFC8578"></xref> and DetNet security considerations
   <xref target="RFC9055"></xref>. </t>
   </section>
   <section numbered="true" toc="default"> <name>IANA Considerations</name>
   <t>This document makes no requests for IANA action.</t>
   </section>
	
   <section numbered="true" toc="default"> <name>Acknowledgements</name>
   <t>The authors would like to acknowledge Aihua Liu, Bin Tan, Lou
   Berger and Janos Farkas for their thorough review and very helpful comments.</t>
   </section> 
   
   <section numbered="false" toc="default"> <name>Appendix A. Simulation Results in Scientific Research</name>
   
   <t>The throughput of RDMA over network in scientific research application is verified with different 
    performances such as distance, message size, latency and packet loss. 
   	The simulation result shows that, the throughput of RDMA over 1000 kilometers is directly proportional 
	to the length of message size, and inversely proportional to 
	the network packet loss rate and latency. To ensure 80% throughput
	of links over 100Gbps and 1000 kilometers, the message length needs
	to be greater than 512KB, resulting in extremely strict packet loss
	rate indicators due to increased latency.</t>
   
   <section numbered="false" toc="default"> <name>A.1. Simulation for the Long Distance and Latency</name>
   <t>The impact of long distance and latency on throughput performance is shown in Figure 14. 
   The selection of delay parameters in this experiment is mainly aimed at wide area scenarios
   of 100-2000 km, with round trip time (RTT) of 1-20 ms. </t>
   
   <t>As latency increases (1-20 ms), the RDMA message size needs to be continuously increased 
   to achieve high-performance transmission with 100% throughput. Due to the maximum message 
   length of 2 GB, a bandwidth of 100 Gbit/s can be achieved without loss, satisfying the 
   throughput theoretical calculation equation (1).</t>

   <t>Throughput = Window_Size/RTT  (1) </t>

   <t>The overall analysis shows that by adjusting RDMA parameters (such as message length), 
   high-performance transmission of 1000km (with over 90% throughput) can be achieved. 
   The message length setting is actually related to the specific network application, 
   device buffer, and buffer threshold settings, and the increase of message length is 
   unlimited.</t>
   
   
 	<figure title="The Impact of Long-distance Delay on Throughput" align="center" suppress-title="false" alt="" width="" height="">
         <artwork align="center" xml:space="preserve" name="" type="" alt="" width="" height="">
		 
 +-------------+--------------------+---------------+--------------------+
 |RTT latency  |message length(byte)|  distance     |Throughput(Gbps)    |
 +-------------+--------------------+---------------+--------------------+
 |less than 1ms|less than 1024      |less than 100km|more than90%@100Gbps|
 +-------------+--------------------+---------------+--------------------+
 |     1ms     |   256K             |     100km     |more than90%@100Gbps|
 +-------------+--------------------+---------------+--------------------+
 |     2ms     |   512K             |     200km     |more than90%@100Gbps|
 +-------------+--------------------+---------------+--------------------+
 |     5ms     |   1M               |     500km     |more than90%@100Gbps|
 +-------------+--------------------+---------------+--------------------+
 |     10ms    |   8M               |     1000km    |more than90%@100Gbps|
 +-------------+--------------------+---------------+--------------------+
		 
   	   </artwork>
    </figure>

   </section>
   
   <section numbered="false" toc="default"> <name>A.2. Simulation for the Latency and Packet Loss</name>
   
   <t>The traditional RDMA adopts the Go-Back-N retransmission mechanism, which retransmits all data 
   packets after the dropped data packet N. Loss of packets can cause significant performance degradation
   in RDMA. However, TCP only needs to retransmit lost individual packets, and the latest RDMA network
   cards have started using selective repeat. Therefore, the calculation formulas for TCP packet loss 
   rate (p), latency, and bandwidth can be referred to:</t>

   <t>Throughput = Min{MSS/RTT*C*(1/P)} (2)</t>
   
   <t>The actual testing performance of RDMA differs from that of TCP, and the main impact of wide area 
   networks is latency, with retransmission and congestion control algorithm models being similar. Therefore,
   the theoretical rate of RDMA is empirically judged by adjusting the value of parameter C in equation (2) 
   (TCP empirical value C is 1.0).</t>

   <t>When both bigger delay and packet loss coexist and over 80% throughput of a 100G link, the packet loss
   rate in the data center must be less than 0.005%. In the scenario of wide area interconnection in DCs, 
   due to the increase in retransmission cost and response time caused by basical line delay, the packet loss
   threshold is more strict and harsh in the data center, requiring the network to achieve lossless as much 
   as possible. In a wide area scenario, even with the optimization algorithm of selective retransmission, it
   is difficult to achieve a bandwidth utilization rate of over 70% when the packet loss rate is less than 0.001%.</t>
   </section>
   
   </section>  
   
  </middle>
  
  <!--  *****BACK MATTER ***** -->

 <back>
 
    <references>
      <name>References</name>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8664.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8655.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9320.xml"/>	
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8578.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9055.xml"/>	
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-detnet-scaling-requirements.xml"/>
	    <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-xiong-detnet-flow-aggregation.xml"/>
	    <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-rc-detnet-data-unit-groups.xml"/>	
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-xiong-detnet-differentiated-detnet-qos"/>
		<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-bernardos-detnet-multi-domain-pce"/>
	
      </references>
    </references>
 
 </back>
</rfc>
