<?xml version="1.0" encoding="UTF-8"?>
<!-- <?xml version="1.0" encoding="US-ASCII"?> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" category="info"
    docName="draft-jeong-6man-ipmon-problem-statement-00">

<front>
    <title abbrev="IPMON Problem Statement">
    IPv6 Mobile Object Networking (IPMON): Problem Statement and Use Cases
    </title>

    <author initials="J." surname="Jeong"
        fullname="Jaehoon Paul Jeong" role="editor">		
        <organization abbrev="Sungkyunkwan University">
        Department of Computer Science and Engineering
        </organization>

        <address>
            <postal>
                <extaddr>Sungkyunkwan University</extaddr>
                <street>2066 Seobu-Ro, Jangan-Gu</street>
                <city>Suwon</city>
                <region>Gyeonggi-Do</region>
                <code>16419</code>
                <country>Republic of Korea</country>
            </postal>
            <phone>+82 31 299 4957</phone>
            <facsimile>+82 31 290 7996</facsimile>
            <email>pauljeong@skku.edu</email>
            <uri>http://iotlab.skku.edu/people-jaehoon-jeong.php
    		</uri>
        </address>
    </author>

   <author initials="Y." surname="Shen" fullname="Yiwen Chris Shen">
      <organization abbrev="Kyungsung University">
      School of Global Studies
      </organization>       
      <address>
        <postal>
          <extaddr>Kyungsung University</extaddr>
          <street>309, Suyeong-Ro, Nam-Gu</street>
          <city>Busan</city>          
          <code>48434</code>
          <country>Republic of Korea</country>
        </postal>
        <phone>+82 51 663 5968</phone>
        <email>chrisshen@ks.ac.kr</email>
        <uri>https://chrisshen.github.io
        </uri>
      </address>
    </author>

   <author initials="S." surname="Gundavelli" fullname="Sri Gundavelli">
      <organization abbrev="Cisco">
      Cisco
      </organization>       
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city> 
          <region>CA</region>
          <code>95134</code>
          <country>United States of America</country>
        </postal>
        <email>sgundave@cisco.com</email>
        <uri>https://datatracker.ietf.org/person/sgundave@cisco.com
        </uri>
      </address>
    </author>

    <date month="March" day="26" year="2023" />
	
    <area>Internet</area>

    <workgroup>6MAN Working Group</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
     the title) for use on http://www.rfc-editor.org/rfcsearch.html. -->

    <keyword>5G, IPv6, V2V, V2I, V2X, Neighbor Discovery, Mobile Object</keyword>

    <abstract>
    <t>
    This document discusses the problem statement and use cases of
    IPv6 Mobile Object Networking (IPMON).  A moving object is a physically
    movable networked device with 5G communication capability, such as 
    a terrestrial vehicle (e.g., car and motorcycle), a user's smart device
    (e.g., smartphone, smart watch, and tablet), an aerial vehicle (e.g., 
    drone and helicopter), and a marine vehicle (e.g., boat and ship).
    These mobile objects are called vehicles in this document.
    The main scenarios of vehicular communications are vehicle-to-vehicle (V2V),
    vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X) communications. 
    First, this document explains use cases using V2V, V2I, and V2X networking
    over 5G.  Next, for IPv6-over-5G vehicular networks, it makes a gap analysis of current 
    IPv6 protocols (e.g., IPv6 Neighbor Discovery).	
    </t>
    </abstract>
</front>

<middle>

<section anchor="section:Introduction" title="Introduction"> 
    <t>
    New Radio (NR) called 5G is a popular wireless communication technology for
    mobile devices such as smartphone, smart watch, and tablet
    <xref target="TS23501"/><xref target="TS38300"/>.
    This 5G-based communication also plays an important role of the interaction
    among a person's mobile devices, Internet-of-Things (IoT) devices and
    autonomous networked objects (e.g., robot and drone).
    </t>

    <t>
    A moving object is defined as a physically movable networked device with
    a wireless networking capability such as cellular communications (e.g.,
    4G LTE and 5G) and IEEE 802.11 family (e.g., 802.11-OCB), which may be a
    terrestrial vehicle (e.g., car and motorcycle), a user's smart device
    (e.g., smartphone, smart watch, and tablet), an aerial vehicle (e.g.,
    drone and helicopter), and a marine vehicle (e.g., boat and ship).
    These mobile objects are called vehicles in this document. 
    </t>

    <t>
    The main scenarios of vehicular communications are vehicle-to-vehicle
    (V2V), vehicle-to-infrastructure (V2I), and vehicle-to-everything (V2X)
    communications.  First, this document explains use cases using V2V, V2I,
    and V2X networking over 5G.  Next, for IPv6-over-5G vehicular networks,
    it makes a gap analysis of current IPv6 protocols (e.g., IPv6 Neighbor
    Discovery).    
    </t>
</section>	<!--  end section "Introduction"  --> 

<section anchor="section:Terminology" title="Terminology">
    <t>
    This document uses the terminology described in <xref target="RFC8691" /><xref target="RFC9365" />.    
    </t>
    
</section>	<!--  end section "Terminology"  --> 

<section anchor="section:Use-Cases" title="Use Cases">
    <t>
    This section explains use cases of V2V, V2I, and V2X networking.
    Those three kinds of use cases are the same as the use cases in
    IPWAVE (IPv6 Wireless Access in Vehicular Environments) Problem Statement
    <xref target="RFC9365" /> by assuming that the wiress access technology
    is 5G-based V2V, V2I, and V2X instead of IEEE 802.11-OCB-based V2V, V2I,
    and V2X.
    For the detailed discussion on the V2V, V2I, and V2X use cases, refer to
    the use cases in <xref target="RFC9365" />.
    </t>

    <section anchor="subsection:V2V-Use-Cases" title="V2V">
        <t>
        The use cases of V2V networking discussed in this section include 
        <list style="symbols">
            <t>Context-aware navigation for safe driving and collision avoidance;</t>
		    <t>Collision avoidance service of end systems of Urban Air 
               Mobility (UAM);</t>        
            <t>Cooperative adaptive cruise control in a roadway;</t>
            <t>Platooning in a highway;</t>
            <t>Cooperative environment sensing.</t>
        </list>
        The above use cases are examples for using V2V networking, which can 
        be extended to other terrestrial vehicles, river/sea ships, 
        railed vehicles, UAM end systems, and pedestrians' smart devices
        (e.g., smartphone, smart watch, and tablet).
	    </t>
    </section>  <!--  end subsection "V2V Use Cases"  --> 

    <section anchor="subsection:V2I-Use-Cases" title="V2I">
        <t>
        The use cases of V2I networking discussed in this section include
        <list style="symbols">
            <t>Navigation service;</t>
            <t>Energy-efficient speed recommendation service;</t>
            <t>Accident notification service;</t>
            <t>Electric vehicle (EV) charging service;</t>
            <t>UAM navigation service with efficient battery charging.</t>
        </list>
        The above use cases are examples for using V2I networking, which can
        be extended to other terrestrial vehicles, river/sea ships, 
        railed vehicles, UAM end systems, and pedestrians' smart devices.
        </t>
    </section>  <!--  end subsection "V2I Use Cases"  --> 

    <section anchor="subsection:V2X-Use-Cases" title="V2X">
        <t>
        The use cases of V2X networking discussed in this section include
        <list style="symbols">
            <t>Protection service for vulnerable road user (VRU) (e.g.,
               pedestrian and cyclist);</t>
            <t>Human sensing-based protection service for VRUs not carrying
               smart devices.</t>
        </list>
        Note that the application area of this use case is currently limited
        to a safety service in a specific environment, such as construction
        sites, plants, and factories, since not every VRU (e.g., children)
        in a public area (e.g., streets) is equipped with a smart device.
        For a safety service for VRUs not carrying start devices, a human
        sensing technology with WiFi signal measurement can be combined with
        V2X networking between road infrastructure nodes with such human
        sensing capability and vehicles.
        </t>
    </section>  <!--  end subsection "V2X Use Cases"  --> 
        
</section>	<!--  end section "Use Cases"  --> 

<section anchor="section:5G-Vehicular-Networks" title="5G Vehicular Networks">
    <t>
    This section describes the context for vehicular networks supporting 5G
    V2V, V2I, and V2X communications among vehicles, gNodeBs, and other User
    Equipments (UEs) such as smartphones, smart watches, and tablets
    <xref target="TS23287"/>.
    As shown in <xref target="fig:5G-vehicular-network-architecture" />,
    infrastructure nodes for vehicles are gNodeBs in 5G vehicular networks.
    </t>

	<figure anchor="fig:5G-vehicular-network-architecture"
        title="An Example 5G Vehicular Network Architecture for V2I and V2V">
        <artwork><![CDATA[
                     Traffic Control Center in Vehicular Cloud
                    *******************************************
+-------------+    *                                           *
|Correspondent|   *             +-----------------+             *
|    Node     |<->*             | Mobility Anchor |             *
+-------------+   *             +-----------------+             *
                  *                      ^                      *
                  *                      |                      *
                   *                     v                     *
                    *******************************************
                    ^                   ^                     ^
                    |                   |                     |
                    |                   |                     |
                    v                   v                     v
              +---------+           +---------+           +---------+
              | gNodeB1 |<--------->| gNodeB2 |<--------->| gNodeB3 |
              +---------+           +---------+           +---------+
                  ^                     ^                    ^
                  :                     :                    :
           +-----------------+ +-----------------+   +-----------------+
           |      : V2I      | |        : V2I    |   |       : V2I     |
           |      v          | |        v        |   |       v         |
+--------+ |   +--------+    | |   +--------+    |   |   +--------+    |
|Vehicle1|===> |Vehicle2|===>| |   |Vehicle3|===>|   |   |Vehicle4|===>|
+--------+<...>+--------+<........>+--------+    |   |   +--------+    |
           V2V     ^         V2V        ^        |   |        ^        |
           |       : V2V     | |        : V2V    |   |        : V2V    |
           |       v         | |        v        |   |        v        |
           |  +--------+     | |   +--------+    |   |    +--------+   |
           |  |Vehicle5|===> | |   |Vehicle6|===>|   |    |Vehicle7|==>| 
           |  +--------+     | |   +--------+    |   |    +--------+   |
           +-----------------+ +-----------------+   +-----------------+
                 Subnet1              Subnet2              Subnet3
                (Prefix1)            (Prefix2)            (Prefix3)          

        <----> Wired Link   <....> Wireless Link   ===> Moving Direction
    ]]></artwork>
    </figure>		        

	<figure anchor="fig:5G-network-architecture"
        title="An Example 5G Network Architecture for Vehicular Networks">
        <artwork><![CDATA[
                           Data Network 
             *****************************************
            *                                         *
           *            +-----------------+            *
          *             | V2X Application |             *             N6
         *              |      Server     |<-------------*----------------+
         *              +-----------------+              *                |  
          *                      ^                      *                 |
           *                     |                     *                  |
            *                    v                    *                   |
             *****************************************                    |
                                                                          |
                                  5GC                                     |
+---------------------------------------------------------------------+   |
|             +---------+  +---------+  +---------+  +---------+      |   |
|             |   UDM   |  |   PCF   |  |   NEF   |  |    AF   |      |   |
|             +---------+  +---------+  +---------+  +---------+      |   |
|                  ^            ^            ^            ^           |   |
|                  |            |            |            |           |   |
|                  |            |            |            |           |   |
|                  v            v            v            v           |   |
|       ---------------------------------------------------------     |   |
|          ^            ^            ^            ^                   |   v
|          |            |            |            |               +---------+
|          |            |            |            |          ---->|   UPF   |
|          v            v            v            v         /     +---------+
|      +---------+  +---------+  +---------+  +---------+  /          |
|      |   NRF   |  |   UDR   |  |   AMF   |  |   SMF   | /           |
|      +---------+  +---------+  +---------+  +---------+             | 
+---------------------------------------------------------------------+
                                    ^
                                    |
                                    |
                                    v
+-------------------+       +--------------+     Uu      +-------------------+
|        UE1        |       |    NG-RAN    |<...........>|        UE4        | 
| (V2X Application) |       +--------------+             | (V2X Application) | 
+-------------------+                  ^                 +-------------------+ 
          ^                            :                           ^   
          : PC5 (V5)                   : Uu                        : PC5 (V5)
          v                            v                           :
+-------------------+    PC5 (V5)  +-------------------+           :
|        UE2        |<............>|        UE3        |<...........
| (V2X Application) |              | (V2X Application) | 
+-------------------+              +-------------------+
                   <----> Wired Link   <....> Wireless Link
    ]]></artwork>
    </figure>		        

    <t>
    Mobility Anchor (MA) is a node that maintains IPv6 addresses and mobility
    information of vehicles in a road network to support their IPv6 address
    autoconfiguration and mobility management with a binding table. An MA
    has End-to-End (E2E) connections (e.g., tunnels) with IP-RSUs under its
    control for the address autoconfiguration and mobility management of the
    vehicles.  This MA is similar to a Local Mobility Anchor (LMA) in PMIPv6
    <xref target="RFC5213" /> for network-based mobility management.
    Mobility Anchor consists of 5G core functions such as PCF
    (Policy Control Function), AMF (Access and Mobility Management Function),
    SMF (Session Management Function), and UPF (User Plane Function) as shown
    in <xref target="fig:5G-network-architecture" />. 
    Note that <xref target="fig:5G-network-architecture" /> shows an example
    5G network architecture for vehicular networks.
    </t>

    <t>
    Traffic Control Center (TCC) is a system that manages road infrastructure
    nodes (e.g., gNodeBs, MAs, traffic signals, and loop detectors), and also
    maintains vehicular traffic statistics (e.g., average vehicle speed and
    vehicle inter-arrival time per road segment) and vehicle information
    (e.g., a vehicle's identifier, position, direction, speed, and trajectory
    as a navigation path). TCC is part of a vehicular cloud for vehicular
    networks.
    </t>

    <t>
    V2V communication between two vehicles as UEs uses a PC5 reference point
    <xref target="TS23287"/>. 
    V2I communication between a vehicle and a gNodeB uses a Uu reference point
    <xref target="TS23287"/>.
    As shown in <xref target="fig:5G-vehicular-network-architecture" />, 
    Vehicle1 can communicate with Vehicle3 via Vehicle2 in the same Vehicular
    Ad Hoc Network (VANET).
    In this figure, Vehicle1 can communicate with Correspondent Node 
    via Vehicle2 as a relay node and gNodeB1 as an infrastructure node
    in a Radio Access Network (RAN) in 5G networks.
    </t>
</section>  <!--  end section "Vehicular Networks"  --> 

<section anchor="section:Problem-Statement" title="Problem Statement">
    <t>
    For 5G V2V by PC5 in unicast mode, one vehicle UE (VehUE) needs to be an
    IPv6 router for IPv6 Stateless Address Autoconfiguration (SLAAC) 
    <xref target="RFC4862" />. The 5G V2X specifications
    <xref target="TS23287" /><xref target="TS24587"/> do not specify which
    VehUE shall be the IPv6 router for SLAAC. Also, it does not specify how
    many IPv6 addresses/prefixes a VehUE will have in this case.
    </t>

    <figure anchor="fig:slaac-in-unicast-mode-by-5G-v2v-PC5"
    title="SLAAC in Unicast Mode by PC5 Interface of 5G V2V ">
    <artwork align="center"><![CDATA[

   ===>                 ===>                 ===>                  ===>
+--------+   SLAAC   +--------+   SLAAC   +--------+ Link-Local +--------+    
|Vehicle2|<.........>|Vehicle1|<.........>|Vehicle3|<..........>|Vehicle4|
+--------+           +--------+           +--------+            +--------+    
IPv6 Host            IPv6 Router          IPv6 Host             IPv6 Host

        <....> Wireless Link   ===> Moving Direction
    ]]></artwork>
    </figure>               

    <t>
    As shown in <xref target="fig:slaac-in-unicast-mode-by-5G-v2v-PC5" />,
    a VehUE (e.g., Vehicle1) among others shall be acting as an IPv6 router
    using SLAAC to assign IPv6 addresses/prefixes for other VehUEs. 
    In this case, there are several issues as follows: 
    </t>

    <list style="symbols">
        <t>Which VehUE shall be the IPv6 router for the role to assign IPv6
           addresses/prefixes if multiple VehUEs can be or want to be an IPv6 router?</t>
        <t>For a VehUE acting as an IPv6 router, how many IPv6 addresses/prefixes will
           it assign? How much Will the role of an IPv6 router burden the IPv6 router VehUE?</t>
        <t>For a VehUE receiving IPv6 addresses/prefixes from a IPv6 router VehUE, 
           how many IPv6 addresses/prefixes will it have on the movement?</t>
        <t>If a VehUE (e.g., Vehicle4 in <xref target="fig:slaac-in-unicast-mode-by-5G-v2v-PC5" />)
           does not have any connection with an IPv6 router VehUE, it will only use
           an IPv6 link local address for communications. In this case, multihop
           routing is triggered to forward IPv6 packets. How will this scenario affect
           the IPv6 networking among VehUEs?</t>
    </list>

    <t>
    For V2V and V2I communications among VehUEs and gNodeB, the 5G
    specifications <xref target="TS23287" /><xref target="TS24587"/> do not
    mention that VehUEs will use the same IPv6 configuration. 
    It is necessary to consider whether the VehUEs will use the
    same prefix or the different prefixes for both V2V and V2I communications.
    </t>

    <t>
    For multihop V2V and V2I among VehUEs and gNodeB, existing routing
    protocols are costly to maintain a routing table. The 5G specifications
    <xref target="TS23287" /><xref target="TS24587"/> do not consider how
    to minimize control traffic overhead for both routing and IPv6 Neighbor
    Discovery (ND) <xref target="RFC4861" />.
    </t>

    <t>
    Mobility management in 5G V2X is required for the seamless communications
    between a VehUE and a server in a wired network (e.g., the Internet).
    It is necessary to consider how to manage the mobility of vehicles that
    have connections with a server while they are moving along their
    navigation paths <xref target="RFC9365" />.
    </t>
</section>  <!--  end section "Problem Statement"  --> 

<section anchor="section:Security-Considerations"
    title="Security Considerations">
    <t>
    This section discusses security and privacy for IPv6-over-5G-based
	vehicular networking. The issues and considerations in 5G-based
	V2I, V2V, and V2X are the same as those in 802.11-OCB-based V2I,
	V2V, and V2X in <xref target="RFC9365" />.
    </t>

</section>	<!--  end section "Security Considerations"  --> 

<section anchor="section:IANA-Considerations" title="IANA Considerations">
    <t>	
    This document does not require any IANA actions.
    </t>
</section>	<!--  end section "IANA Considerations"  -->

</middle>

<back>
   

<!--
  START: Referenced Papers and Standard Activities
-->

<references title="Normative References">
    <?rfc include="reference.RFC.4861"?>
    <?rfc include="reference.RFC.4862"?>
    <?rfc include="reference.RFC.5213"?>
    <?rfc include="reference.RFC.8691"?>
    <?rfc include="reference.RFC.9365"?>
</references>

<references title="Informative References">    
    <reference anchor="TS23287" target="https://www.3gpp.org/DynaReport/23287.htm">
        <front>
            <title>
                Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services
            </title>
            <author>
                <organization>3GPP</organization>
            </author>
            <date month="December" year="2022"/>
        </front>
        <seriesInfo name="TS" value="23.287 V17.5.0"/>
    </reference> 

    <reference anchor="TS23303" target="https://www.3gpp.org/DynaReport/23303.htm">
        <front>
            <title>
                Proximity-based services (ProSe); Stage 2
            </title>
            <author>
                <organization>3GPP</organization>
            </author>

            <date month="December" year="2021"/>
        </front>
        <seriesInfo name="TS" value="23.303 V17.0.0"/>
    </reference> 

    <reference anchor="TS23304" target="https://www.3gpp.org/DynaReport/23304.htm">
        <front>
            <title>
                Proximity based Services (ProSe) in the 5G System (5GS)
            </title>
            <author>
                <organization>3GPP</organization>
            </author>

            <date month="December" year="2022"/>
        </front>
        <seriesInfo name="TS" value="23.304 V17.5.0"/>
    </reference> 

    <reference anchor="TS23501" target="https://www.3gpp.org/DynaReport/23501.htm">
        <front>
            <title>
                System Architecture for the 5G System (5GS); Stage 2
            </title>
            <author>
                <organization>3GPP</organization>
            </author>

            <date month="December" year="2022"/>
        </front>
        <seriesInfo name="TS" value="23.501 V17.7.0"/>
    </reference> 

    <reference anchor="TS24587" target="https://www.3gpp.org/DynaReport/24587.htm">
        <front>
            <title>
                Vehicle-to-Everything (V2X) services in 5G System (5GS); Stage 3
            </title>
            <author>
                <organization>3GPP</organization>
            </author>
            <date month="January " year="2023"/>
        </front>
        <seriesInfo name="TS" value="24.587 V18.0.0"/>
    </reference> 

    <reference anchor="TS38300" target="https://www.3gpp.org/DynaReport/38300.htm">
        <front>
            <title>
                NR; NR and NG-RAN Overall description; Stage 2
            </title>
            <author>
                <organization>3GPP</organization>
            </author>

            <date month="January" year="2023"/>
        </front>
        <seriesInfo name="TS" value="38.300 V17.3.0"/>
    </reference>

</references>


<section title="Acknowledgments">
    <t indent="0" pn="section-appendix.a-1">    
    This work was supported by the National Research Foundation of Korea
    (NRF) grant funded by the Korea government, Ministry of Science and ICT
    (MSIT) (No. 2023R1A2C2002990).
    </t>

    <t indent="0" pn="section-appendix.a-2">
    This work was supported in part by Institute of Information &amp; Communications
    Technology Planning &amp; Evaluation (IITP) grant funded by the Korea
    Ministry of Science and ICT (MSIT)(No. 2022-0-01015, Development of
    Candidate Element Technology for Intelligent 6G Mobile Core Network).
    </t>

    <t indent="0" pn="section-appendix.a-3">    
    This work was supported in part by Basic Science Research Program 
    through the National Research Foundation of Korea (NRF) funded by the 
    Ministry of Education (No. 2022R1I1A1A01053915).
    </t>
        
</section>

<section anchor="section:Contributors" title="Contributors">
    <t indent="0" pn="section-appendix.b-1"> 
    This document is a group work, greatly benefiting 
    from inputs and texts by <contact fullname="Erik Kline"/> (Aalyria)
    and <contact fullname="Eric Vyncke"/> (Cisco).
    The authors sincerely appreciate their contributions.
    </t>

    <t indent="0" pn="section-appendix.b-2">  
    The following are coauthors of this document:
    </t>   

        <contact fullname="Bien Aime Mugabarigira">
        <organization showOnFrontPage="true">Department of Computer Science &amp; Engineering</organization>
        <address>
          <postal>
            <extaddr>Sungkyunkwan University</extaddr>
            <street>2066 Seobu-Ro, Jangan-Gu</street>
            <city>Suwon</city>
            <region>Gyeonggi-Do</region>
            <code>16419</code>
            <country>Republic of Korea</country>
          </postal>
          <phone>+82 31 299 4106</phone>
          <email>bienaime@skku.edu</email>
          <uri>http://iotlab.skku.edu/people-Bien-Aime.php</uri>
        </address>
      </contact>
      <contact fullname="Tae (Tom) Oh">
        <organization showOnFrontPage="true">Golisano College of Computing and Information Sciences</organization>
        <address>
          <postal>
            <extaddr>Rochester Institute of Technology</extaddr>
            <street>One Lomb Memorial Drive</street>
            <city>Rochester</city>
            <region>NY</region>
            <code>14623-5603</code>
            <country>United States of America</country>
          </postal>
          <phone>+1 585 475 7642</phone>
          <email>Tom.Oh@rit.edu</email>
        </address>
      </contact>

  </section>

</back>

<!-- <vspace blankLines="100"/> -->
<!-- page break to put addresses onto one page-->

</rfc>
