<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902" submissionType="IETF" docName="draft-bernardos-cats-isac-uc-01">

  <front>
      <title abbrev="ISAC use case for CATS">
Integrated Sensing and Communications (ISAC) for CATS
      </title>

    <!-- AUTHORS -->
    <author fullname="Carlos J. Bernardos"
            initials="CJ."
            surname="Bernardos">
      <organization abbrev="UC3M">
        Universidad Carlos III de Madrid
      </organization>
      <address>
        <postal>
          <street>Av. Universidad, 30</street>
          <city>Leganes, Madrid</city>
          <code>28911</code>
          <country>Spain</country>
        </postal>
        <phone>+34 91624 6236</phone>
        <email>cjbc@it.uc3m.es</email>
        <uri>http://www.it.uc3m.es/cjbc/</uri>
      </address>
    </author>

    <author fullname="Alain Mourad"
            initials="A."
            surname="Mourad">
      <organization abbrev="InterDigital">
        InterDigital Europe
      </organization>
      <address>
        <email>Alain.Mourad@InterDigital.com</email>
        <uri>http://www.InterDigital.com/</uri>
      </address>
    </author>

    <author fullname="Tianji Jiang"
            initials="T."
            surname="Jiang">
      <organization abbrev="CMCC">
        China Mobile
      </organization>
      <address>
        <email>tianjijiang@yahoo.com</email>
      </address>
    </author>

    <area>Routing</area>

    <workgroup>CATS WG</workgroup>

    <abstract>

      <t>
        Integrated Sensing and Communications (ISAC) represents a paradigm shift in
        wireless networks, where sensing and communication functions are jointly
        designed and optimized. By leveraging the same spectral and hardware resources,
        ISAC enables advanced capabilities such as environment perception, object
        tracking, and situational awareness, while maintaining efficient and reliable
        data transmission. This integration holds great potential for applications in
        areas such as autonomous systems, smart cities, and industrial automation, where
        precise sensing and low-latency communication are critical.
        This document presents the ISAC as a typical CATS scenario to facilitate
        discussions on the potential challenges and requirements. 
      </t>

    </abstract>

  </front>

  <middle>

    <section anchor="sec:introduction" title="Introduction">

      <t>
        Integrated Sensing and Communications (ISAC) is emerging as a key enabler for
        next-generation wireless networks, integrating sensing and communication
        functionalities within a unified system. By leveraging the same spectral,
        hardware, and computational resources, ISAC enhances network efficiency while
        enabling new capabilities such as high-resolution environment perception, object
        detection, and situational awareness. This paradigm shift is particularly
        relevant for applications requiring both reliable connectivity and precise
        sensing, such as autonomous vehicles, industrial automation, and smart city
        deployments. Given its strategic importance, ISAC has gained significant
        traction in standardization efforts. 
      </t>

      <t>
        While the ETSI Industry Specification Group (ISG)
        on ISAC has been established to explore technical requirements and use cases,
        the 3GPP organization has approved the 5G study work in its release 20 (rel-20) and 
        initiated the investigation on ISAC-related features <xref target="TR.23.700-14"/>.
        Moreover, 3GPP has agreed to continue the sensing related research 
        on future 6G systems. Furthermore, research initiatives within the IEEE
        and IETF are investigating how ISAC can be integrated into network
        architectures, spectrum management, and protocol design, making it a critical
        area of development in the evolution of wireless networks.
      </t>

      <t>
        This document presents the ISAC as a typical CATS scenario, being supplementary
        to the CATS use cases as in <xref target="I-D.ietf-cats-usecases-requirements" />,
        to facilitate discussions on the potential challenges, and requirements.
        Further, the document references the new draft on CATS reference
        model <xref target="IETF-CATS-RefModel-ACN"/>
        to briefly discuss how the ISAC case may leverage the model.
      </t>

    </section>

<!--
    <section anchor="sec:terminology" title="Terminology">

      <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" />.
      </t>

    </section>
-->


    <section anchor="sec:isac-uc" 
        title="Computing Aware distributed sensing for Integrated Sensing and Communications">

        <t>
        Integrated Sensing and Communications (ISAC) enables wireless networks to
        perform simultaneous data transmission and environmental sensing. In a
        distributed sensing scenario, multiple hardware network entities, 
        such as base stations,
        access points, or edge devices (e.g., wireless terminal equipment),
        and intelligent agents deployed as software instances on the entities 
        (e.g., AI-agents) -- collect raw sensing data from the environment.
        These data can include radio frequency (RF) reflections, Doppler shifts, channel
        state information (CSI), or other physical-layer features that provide insights
        into object movement, material composition, or environmental conditions. To
        extract meaningful information, the collected raw data must be aggregated and
        processed by a designated computing node with sufficient computational
        resources. This requires efficient coordination between sensing nodes and
        computing resources to ensure timely and accurate analysis, making it a relevant
        scenario for Computing-Aware Traffic Steering (CATS) in IETF.
        </t>
      
    <section anchor="sec:isac-uc-ETSI" title="CATS of ETSI ISAC">
        <t>
        This use case aligns with ongoing efforts in standardization bodies such as the
        ETSI ISAC Industry Specification Group (ISG), particularly Work Item #5 (WI#5),
        titled 'Integration of Computing with ISAC'. WI#5 focuses on exploring different
        forms of computing integration within ISAC systems, including sensing combined
        with computing, communications combined with computing, and the holistic
        integration of ISAC with computing. The considerations outlined in this document
        complement ETSI's work by examining how computing-aware networking solutions, as
        developed within CATS, can optimize the processing and routing of ISAC sensing
        data.
        </t>
      
        <t>
        As an example, we can consider a network domain with multiple sites capable of
        hosting the ISAC computing "service", each with potentially different
        connectivity and computing characteristics. <xref target="fig:ps_scenario" />
        shows an exemplary scenario. Considering the connectivity and computing
        latencies (just as an example of metrics), the best service site is #n-1 in the
        example used in the Figure. Note that in the figure we still use the old
        terminology in which by ICR we mean Ingress CATS-Forwarder <xref
        target="I-D.ietf-cats-framework" />, and by ECR we mean Egress CATS-Forwarder.
        </t>

<figure anchor="fig:ps_scenario" title="Exemplary scenario" >
<artwork><![CDATA[
                             ________________ 
                            (     ---------- )
                           (      |        |  ) 
                         (     ---------- |   )
   ________________     (     |        | |    )     _______________
  (     ---------- )    (   ---------- | |    )    (    ---------- )
 (      |        |  )   (   |service | |-     )   (     |        |  )
(     ---------- |   )  (   |contact | |      )  (    ---------- |  )
(     |        | |   )  (   |instance|--      )  (    |        | |  )
(   ---------- | |   )   (  ----------       )   (  ---------- | |  ) 
(   |service | |-    )    ( Serv. site #N-1 )    (  |service | |-   )
(   |contact | |     )     -------+----------     (  |contact | |   )
(   |instance|--    )   Computing  \              (  |instance|--   ) 
 (  ----------     )    delay:4ms   \              ( ----------     ) 
  ( Serv. site #1 )           --------+--           ( Serv. site #N )
   -------+--------       ----| ECR#N-1 |----        ---------+-----
           \  Computing --     -----------    --  Computing  /
            \ delay:10ms      Networking          delay:5ms /
          ---+-----           delay:7ms              ------+--
        ( | ECR#1 |            //                    | ECR#N | )
       (  ---------           //                     ---------  )
      ( Networking           //                       Networking )
     (  delay:5ms           //                         delay:15ms )
    (                      //                                      )
    (                     //                                       )
     (                   //                                       )
      (                 //                                       )
       (               //                                       )
        (       ---------                     ---------        )
         -------| ICR#1 |---------------------| ICR#2 |--------
                ---------           __         --------- 
                (·)   (·)        / (  )           (·)
               (·)   -------   -  (    )         (·)
              (·)    | UE2 | /     (__) \      (·)
             (·)     -------    /         -   -------
            (·)               /  (sensing  \  | UE3 |
          -------   ---------                 -------
          | UE1 | /
          ------- 
]]></artwork>
</figure>

      </section> <!-- End of Subsection: ETSI ISAC Case -->

      <section anchor="sec:isac-uc-3GPP" title="CATS of 3GPP ISAC">
        <t>
           3GPP has specified in the stage-1 document <xref target="TR.22.870"/> the
           requirements &amp; objectives of ISAC service. 
           Fundamentally, the ISAC service
           includes offering wide area multi-dimensional sensing that provides spatial 
           information about non-connected objects as well as connected devices and 
           their movements and surroundings. Successively, the 3GPP SA2 WG has
           approved a study item (SID) in its rel-20 and initiated the 
           investigation on ISAC-related features <xref target="TR.23.700-14"/>.
           Moreover, 3GPP has agreed to continue the sensing related research on
           the on-going 6G studies. 
        </t>

        <t>
           The <xref target="fig:ISAC-3GPP-scenario"/> describes a possible sensing
           architecture that conforms to the architectural assumptions 
           as in <xref target="TR.23.700-14"/>. 
           The figure shows that there could be multiple 
           authorized sensing entities, e.g., (R)ANs, TEs (with sensors). Also,
           a new sensing function, i.e., SeNF, is promoted. Note the name of the
           sensing function is still up for discussion.
        </t>

<figure anchor="fig:ISAC-3GPP-scenario" title="3GPP ISAC exemplary scenario" >
<artwork><![CDATA[
        SeNF: Sensing Network Function
        Sensing Entities: TE (Terminal Equip), (g)RAN
               ...........................................
               :                                +-----+  :   +-------+ 
               :                                | NEF |------| AF/AS |  
               :      +-----+                   +-----+  :   +-------+
               :      | AMF |                     |      :   
               :      +-----+                     |      :
               :         |       +------+      +-----+   :
               :   ......|.......| SeNF |------| PCF |   :
               :   :     |       +------+      +-----+   :
               :   :     |      /                        :
     +------+  :   :     |     /                         :
     | TE#1 |......:     |    /                          :
     +------+  :   :     |   /                           :
     +------+......:  +------+        +-----+            :  +--------+  
     | TE#2 |--:------|(g)RAN|--------| UPF |------------:--|  Data  |  
     +------+  :      +------+        +-----+            :  | Network|                           
               :                                         :  +--------+
               :.........................................:

    ]]></artwork>
</figure>

        <t>
           There might be multiple SeNFs in a wireless network, with each SeNF 
           capable of handling both the CP and UP of the sensing service. 
           A SeNF can process received sensing data, 
           aggregate sensing reports, run detection algorithms, and filter 
           noise - to produce the sensing result that meets the service request. 
           A SeNF may also expose the sensing results to external 
           App servers (namely AS'es). Given the complex yet computationally-heavy
           tasks as conducted by the SeNF, the selection of an optimal SeNF (among
           all SeNF candidates) embodies the principles of CATS.
        </t>

        <t>
           Sensing entities on (authorized) UEs may instantiate as
           software AI-agents with sensing functionality.
           If there is a large amount of collected sensing measurement data, then 
           there might be a need to expose (i.e., transmit) the data to (external) 
           service instances (e.g., in local premise) for optimized processing 
           (if the local compute power at an agent
           is insufficient or is overloaded). 
           After that can the processed sensing results be sent to the original 
           sensing requestor for further processing. This kind of task redirection
           for better processing efficiency
           conforms to what the CATS strives for.

        </t>

      </section> <!-- End of Subsection: 3GPP ISAC Case -->

      <section anchor="sec:isac-uc-relation" 
        title="Relation to CATS">
      
        <t>
        In the distributed sensing scenario, the sensed data collected by multiple nodes
        must be efficiently routed to a computing node capable of processing it. The
        choice of the computing node depends on several factors, including computational
        load, network congestion, and latency constraints. CATS mechanisms can optimize
        the selection of the processing node by dynamically steering the traffic based
        on computing resource availability and network conditions. Additionally, as
        sensing data is often time-sensitive, CATS can ensure low-latency paths while
        balancing computational demands across different processing entities. This
        capability is essential for real-time applications such as cooperative
        perception for autonomous systems, industrial monitoring, and smart city
        infrastructure.
        </t>

        <t>
        Further, the draft <xref target="IETF-CATS-RefModel-ACN"/> has proposed a 
        CATS reference model that operates on general reference points for the
        signaling exchanges of various types of metrics, i.e., network, 
        compute and the new AI-agent metrics as defined in the draft. 
        The ISAC scenario for CATS may
        leverage the model for better operations. For example, 
        the IETF Draft of CATS reference model for ACN defines the reference
        points or RPs, e.g., the RPs between C-PS --- C-NMA, C-PS --- C-SMA, and 
        AIA (AI-agent) --- C-PS, etc. The ISAC scenario may leverage the AI-agent 
        logics and extend the RPs to sensing: AIA (sensing) --- C-PS. In some 
        scenario in the context of 3GPP, here the C-PS can even be a 
        3rd-party entity like AF/AS.
        </t>
        
      </section>

      <section anchor="sec:isac-uc-reqs" title="Requirements">

        <t>
        Several challenges need to be addressed for efficient distributed sensing in
        ISAC-enabled networks:
        </t>

        <list style="bullets">

          <li>
            Traffic Steering and Resource Allocation: Ensuring that sensing data is directed
            to the most suitable computing node while considering both network conditions
            and processing availability.
          </li>

          <li>
            Latency Sensitivity: Many ISAC applications require near-real-time processing,
            necessitating low-latency and high-reliability data forwarding strategies.
          </li>

          <li>
            Data Synchronization: Sensing nodes may have different perspectives on the
            environment, requiring synchronization and fusion of data streams before
            processing.
          </li>

          <li>
            Scalability: As the number of participating sensing nodes increases, mechanisms
            must efficiently distribute and balance the computational workload.
          </li>

          <li>
            Security and Privacy: Sensed data may contain sensitive information, requiring
            mechanisms for secure transmission and processing.
          </li>

          <li>
            Holistic Reference Model: Potentially a general CATS reference model 
            with reference points for the signaling exchanges of various types of metrics 
            among CATS entities and sensing entities.
          </li>

        </list>

      </section>

      <section anchor="sec:isac-uc-remarks" title="Additional remarks">

        <t>
        The integration of ISAC-based distributed sensing into CATS frameworks may
        require enhancements in computing-aware routing protocols, traffic steering
        algorithms, signaling mechanisms, and potentially the integration of the
        CATS reference model. Standardization efforts could focus on
        defining metrics for computing-aware path selection that is based not only on
        the existing CATS metrics but also with any future extensions 
        (e.g., 'AI-agent metrics' in <xref target="IETF-CATS-RefModel-ACN"/>), 
        developing mechanisms for
        real-time coordination between sensing and computing nodes, and ensuring
        interoperability with existing network architectures. Furthermore, coordination
        with ETSI &amp; 3GPP may help align the development of computing-aware ISAC
        networking solutions with ongoing standardization efforts in computing
        integration, ensuring cross-industry compatibility and deployment feasibility.
        </t>

      </section>

    </section>

    <section anchor="IANA" title="IANA Considerations">

      <t>
N/A.
      </t>

    </section>

    <section anchor="Security" title="Security Considerations">

      <t>
TBD.
      </t>

    </section>

    <section anchor="Acknowledgments" title="Acknowledgments">

      <t>
The work of Carlos J. Bernardos in this document has been partially supported by
the Horizon Europe MultiX (Grant Agreement No. 101192521) and Hexa-X-II (Grant
Agreement No. 101095759) projects.
      </t>

    </section>

  </middle>

  <back>

<!--
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>
    </references>
-->

    <references title="Informative References">

      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cats-framework.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-cats-usecases-requirements.xml"/>

      <reference anchor="IETF-CATS-RefModel-ACN">
        <front>
          <title>CATS Reference Model for AI-Agent Communication Network </title>

          <author initials="T., et al." surname="Jiang">
            <organization/>
          </author>
       
          <date month="June" year="2025"/>
        </front>

        <seriesInfo name="" value="https://datatracker.ietf.org/doc/draft-jiang-cats-reference-acn"/>
      </reference>

      <reference anchor="TR.23.700-14">
        <front>
          <title>3GPP TR 23.700-14 v0.2.0: Study on Stage 2 for Integrated Sensing 
                        and Communication</title>
          <author initials="3GPP">
            <organization/>
          </author>
          <date month="June" year="2025"/>
        </front>

        <seriesInfo name="" value="3GPP TR 23.700-14"/>
      </reference>

      <reference anchor="TR.22.870">
        <front>
          <title>3GPP TR 22.870 v0.3.0: Study on 6G Use Cases and
                 Service Requirements; Stage 1, Rel-20</title>
          <author initials="3GPP">
            <organization/>
          </author>
          <date month="May" year="2025"/>
        </front>

        <seriesInfo name="" value="3GPP TR 22.870"/>
      </reference>


    </references>

  </back>

</rfc>
