Internet DRAFT - draft-jeong-6man-ipmon-problem-statement
draft-jeong-6man-ipmon-problem-statement
6MAN Working Group J. Jeong, Ed.
Internet-Draft Sungkyunkwan University
Intended status: Informational Y. Shen
Expires: 27 September 2023 Kyungsung University
S. Gundavelli
Cisco
26 March 2023
IPv6 Mobile Object Networking (IPMON): Problem Statement and Use Cases
draft-jeong-6man-ipmon-problem-statement-01
Abstract
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).
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 September 2023.
Jeong, et al. Expires 27 September 2023 [Page 1]
Internet-Draft IPMON Problem Statement March 2023
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. V2V . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. V2I . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. V2X . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. 5G Vehicular Networks . . . . . . . . . . . . . . . . . . . . 5
5. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10
Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
New Radio (NR) called 5G is a popular wireless communication
technology for mobile devices such as smartphone, smart watch, and
tablet [TS23501][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).
Jeong, et al. Expires 27 September 2023 [Page 2]
Internet-Draft IPMON Problem Statement March 2023
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.
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).
2. Terminology
This document uses the terminology described in [RFC8691][RFC9365].
3. Use Cases
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 [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 [RFC9365].
3.1. V2V
The use cases of V2V networking discussed in this section include
* Context-aware navigation for safe driving and collision avoidance;
* Collision avoidance service of end systems of Urban Air Mobility
(UAM);
* Cooperative adaptive cruise control in a roadway;
* Platooning in a highway;
* Cooperative environment sensing.
Jeong, et al. Expires 27 September 2023 [Page 3]
Internet-Draft IPMON Problem Statement March 2023
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).
3.2. V2I
The use cases of V2I networking discussed in this section include
* Navigation service;
* Energy-efficient speed recommendation service;
* Accident notification service;
* Electric vehicle (EV) charging service;
* UAM navigation service with efficient battery charging.
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.
3.3. V2X
The use cases of V2X networking discussed in this section include
* Protection service for vulnerable road user (VRU) (e.g.,
pedestrian and cyclist);
* Human sensing-based protection service for VRUs not carrying smart
devices.
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.
Jeong, et al. Expires 27 September 2023 [Page 4]
Internet-Draft IPMON Problem Statement March 2023
4. 5G Vehicular Networks
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 [TS23287][TS23303][TS23304]. As shown in Figure 1,
infrastructure nodes for vehicles are gNodeBs in 5G vehicular
networks.
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
Figure 1: An Example 5G Vehicular Network Architecture for V2I
and V2V
Jeong, et al. Expires 27 September 2023 [Page 5]
Internet-Draft IPMON Problem Statement March 2023
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
Jeong, et al. Expires 27 September 2023 [Page 6]
Internet-Draft IPMON Problem Statement March 2023
Figure 2: An Example 5G Network Architecture for Vehicular Networks
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 [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 Figure 2. Note that Figure 2 shows an example
5G network architecture for vehicular networks.
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.
V2V communication between two vehicles as UEs uses a PC5 reference
point [TS23287]. V2I communication between a vehicle and a gNodeB
uses a Uu reference point [TS23287]. As shown in Figure 1, 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.
5. Problem Statement
For 5G V2V by PC5 in unicast mode, one vehicle UE (VehUE) needs to be
an IPv6 router for IPv6 Stateless Address Autoconfiguration (SLAAC)
[RFC4862]. The 5G V2X specifications [TS23287][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.
===> ===> ===> ===>
+--------+ SLAAC +--------+ SLAAC +--------+ Link-Local +--------+
|Vehicle2|<........>|Vehicle1|<........>|Vehicle3|<..........>|Vehicle4|
+--------+ +--------+ +--------+ +--------+
IPv6 Host IPv6 Router IPv6 Host IPv6 Host
<....> Wireless Link ===> Moving Direction
Jeong, et al. Expires 27 September 2023 [Page 7]
Internet-Draft IPMON Problem Statement March 2023
Figure 3: SLAAC in Unicast Mode by PC5 Interface of 5G V2V
As shown in Figure 3, 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:
* 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?
* 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?
* For a VehUE receiving IPv6 addresses/prefixes from a IPv6 router
VehUE, how many IPv6 addresses/prefixes will it have on the
movement?
* If a VehUE (e.g., Vehicle4 in Figure 3) 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?
For V2V and V2I communications among VehUEs and gNodeB, the 5G
specifications [TS23287][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.
For multihop V2V and V2I among VehUEs and gNodeB, existing routing
protocols are costly to maintain a routing table. The 5G
specifications [TS23287][TS24587] do not consider how to minimize
control traffic overhead for both routing and IPv6 Neighbor Discovery
(ND) [RFC4861].
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 [RFC9365].
Jeong, et al. Expires 27 September 2023 [Page 8]
Internet-Draft IPMON Problem Statement March 2023
6. Security Considerations
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 [RFC9365].
7. IANA Considerations
This document does not require any IANA actions.
8. References
8.1. Normative References
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC8691] Benamar, N., Härri, J., Lee, J., and T. Ernst, "Basic
Support for IPv6 Networks Operating Outside the Context of
a Basic Service Set over IEEE Std 802.11", RFC 8691,
DOI 10.17487/RFC8691, December 2019,
<https://www.rfc-editor.org/info/rfc8691>.
[RFC9365] Jeong, J., Ed., "IPv6 Wireless Access in Vehicular
Environments (IPWAVE): Problem Statement and Use Cases",
RFC 9365, DOI 10.17487/RFC9365, March 2023,
<https://www.rfc-editor.org/info/rfc9365>.
8.2. Informative References
[TS23287] 3GPP, "Architecture enhancements for 5G System (5GS) to
support Vehicle-to-Everything (V2X) services", TS 23.287
V17.5.0, December 2022,
<https://www.3gpp.org/DynaReport/23287.htm>.
Jeong, et al. Expires 27 September 2023 [Page 9]
Internet-Draft IPMON Problem Statement March 2023
[TS23303] 3GPP, "Proximity-based services (ProSe); Stage 2",
TS 23.303 V17.0.0, December 2021,
<https://www.3gpp.org/DynaReport/23303.htm>.
[TS23304] 3GPP, "Proximity based Services (ProSe) in the 5G System
(5GS)", TS 23.304 V17.5.0, December 2022,
<https://www.3gpp.org/DynaReport/23304.htm>.
[TS23501] 3GPP, "System Architecture for the 5G System (5GS); Stage
2", TS 23.501 V17.7.0, December 2022,
<https://www.3gpp.org/DynaReport/23501.htm>.
[TS24587] 3GPP, "Vehicle-to-Everything (V2X) services in 5G System
(5GS); Stage 3", TS 24.587 V18.0.0, January 2023,
<https://www.3gpp.org/DynaReport/24587.htm>.
[TS38300] 3GPP, "NR; NR and NG-RAN Overall description; Stage 2",
TS 38.300 V17.3.0, January 2023,
<https://www.3gpp.org/DynaReport/38300.htm>.
Appendix A. Acknowledgments
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).
This work was supported in part by Institute of Information &
Communications Technology Planning & 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).
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).
Appendix B. Contributors
This document is a group work, greatly benefiting from inputs and
texts by Erik Kline (Aalyria) and Eric Vyncke (Cisco). The authors
sincerely appreciate their contributions.
The following are coauthors of this document:
Bien Aime Mugabarigira
Department of Computer Science & Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Jeong, et al. Expires 27 September 2023 [Page 10]
Internet-Draft IPMON Problem Statement March 2023
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4106
Email: bienaime@skku.edu
URI: http://iotlab.skku.edu/people-Bien-Aime.php
Tae (Tom) Oh
Golisano College of Computing and Information Sciences
Rochester Institute of Technology
One Lomb Memorial Drive
Rochester, NY 14623-5603
United States of America
Phone: +1 585 475 7642
Email: Tom.Oh@rit.edu
Authors' Addresses
Jaehoon Paul Jeong (editor)
Department of Computer Science and Engineering
Sungkyunkwan University
2066 Seobu-Ro, Jangan-Gu
Suwon
Gyeonggi-Do
16419
Republic of Korea
Phone: +82 31 299 4957
Email: pauljeong@skku.edu
URI: http://iotlab.skku.edu/people-jaehoon-jeong.php
Yiwen Chris Shen
School of Global Studies
Kyungsung University
309, Suyeong-Ro, Nam-Gu
Busan
48434
Republic of Korea
Phone: +82 51 663 5968
Email: chrisshen@ks.ac.kr
URI: https://chrisshen.github.io
Jeong, et al. Expires 27 September 2023 [Page 11]
Internet-Draft IPMON Problem Statement March 2023
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
United States of America
Email: sgundave@cisco.com
URI: https://datatracker.ietf.org/person/sgundave@cisco.com
Jeong, et al. Expires 27 September 2023 [Page 12]
