Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt

From: [email-masked]
Date: Mon, 16 Jul 2018 02:34:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Wireless Access in Vehicular Environments WG of the IETF.

        Title           : IP Wireless Access in Vehicular Environments (IPWAVE): Problem Statement and Use Cases
        Author          : Jaehoon Paul Jeong
	Filename        : draft-ietf-ipwave-vehicular-networking-04.txt
	Pages           : 30
	Date            : 2018-07-16

Abstract:
   This document discusses the problem statement and use cases on IP-
   based vehicular networks, which are considered a key component of
   Intelligent Transportation Systems (ITS).  The main topics of
   vehicular networking are vehicle-to-vehicle (V2V), vehicle-to-
   infrastructure (V2I), and vehicle-to-everything (V2X) networking.
   First, this document surveys use cases using V2V, V2I, and V2X
   networking.  Second, it analyzes proposed protocols for IP-based
   vehicular networking and highlights the limitations and difficulties
   found on those protocols.  Third, it presents a problem exploration
   for key aspects in IP-based vehicular networking, such as IPv6
   Neighbor Discovery, Mobility Management, and Security & Privacy.  For
   each key aspect, this document discusses a problem statement to
   analyze the gap between the state-of-the-art techniques and
   requirements in IP-based vehicular networking.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipwave-vehicular-networking/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-04
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Fri, 27 Jul 2018 13:27:01 +0000

Dear Jaehoon, all,

I also volunteered in Montreal to review this draft which is a good starting point to identify work items for the future.
I mainly agree with comments already made - especially on the privacy challenges and IP addresses - and would like to add some partly more editorial comments:

I suggest to add already in the abstract the clarification (given later in ch. 3) that X in V2X is understood here as everything else than I and V ... if used together with V2V and V2I.
I suggest to replace in Ch.1:
For driving safety services based on the DSRC, IEEE has standardized Access in Vehicular Environments (WAVE) standards, such as IEEE 802.11p [IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and IEEE 1609.4 [WAVE-1609.4].  
By 
For direct inter-vehicular wireless connectivity IEEE has amended WiFi standard 802.11 to enable driving safety services based on the DSRC in terms of standards for the Wireless Access in Vehicular Environments (WAVE) system.  L2 and L3 issues are addressed in IEEE 802.11p [IEEE-802.11p], security aspects are covered in IEEE 1609.2 [WAVE-1609.2], while IEEE 1609.3 [WAVE-1609.3] defines related services at network and transport layers and IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel operation.

Furthermore I suggest to put references near the related terms e.g.: 
IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to vehicular networks [RFC8200][RFC5944][RFC6275]
=> 
IPv6 [RFC8200] and Mobile IP protocols (e.g., MIPv4 [RFC5944] and MIPv6 [RFC6275]) can be applied or easily modified to vehicular networks.

standardized a standard specifying => approved a standard specifying

which is IP ...=> denoted as IP ...

Also, it also discusses relevant work items to IPWAVE => Also, it discusses relevant and potential new work items to IPWAVE WG

In Ch. 2 I suggest to change:

An RSU is deployed either at an intersection or in a road segment => An RSU is typically deployed at an intersection or in a road segment, but may also be located in car parking areas 

communications with other OBUs and RSUs. => communications with other OBUs and RSUs and may be connected to in-vehicle devices or networks

a vehicular cloud should be defined (I guess it shall just denot cloud infrastructure for vehicular networks and not computing resources distributed across a multitide of vehicles?

Ch.3:

Vehicle-to-Device (V2D) is never used again - isn't it always in the end a device? Perhaps better to add other Vulnerable Road Users (RSUs) as cyclists/bicycles ...

[CA-Cuise-Control] => [CA-Cruise-Control]

share environmental information from various sensors, such as radars, LiDARs and cameras, mounted on them with other vehicles => share environmental information from various vehicle-mounted sensors, such as radars, LiDARs and cameras, with other vehicles 

driver vehicles => driver operated vehicles / (hu)man-driven vehicles [??]

for the global road traffic optimization => for the large-scale/long-range road traffic optimization [IMHO true _global_ optimization is wishful thinking ;-)]

DSRC-based vehicular networks can be used for V2I in near future [DSRC]. I doubt this, especially since the reference is from 2010! ;-)
What about: Some players expect that DSRC-[DSRC] based vehicular networks will be availabel for V2I in the future.[?]

collision of a pedestrian and a vehicle, which have a smartphone, in a road network. => collision of a vehicle and a pedestrian carrying a smartphone equipped with corresponding access technology.

RSU that delivers scheduling information for wireless communication to save the smartphones' battery: Not clear which role RSU plays: that of a cellular base station or WiFi-AP to connect to smartphone? Can you please elaborate?

Ch.4:

We analyze the current protocols from the following aspects: => We describe some currently existing/proposed protocols with respect to following aspects relevant/essential for vehicular networking:

conducted a comprehensive study of the cross-layer identities management in vehicular networks using multiple access network technologies, which constitutes a fundamental element of the ITS architecture 
=> conducted for heterogeneous vehicular network (i.e. employing multiple access technologies) a comprehensive study of the cross-layer identities management, which constitutes a fundamental element of the ITS architecture

speeds of vehicles are varied => speeds of vehicles are highly variable/strongly varying

For service discovery, as a popular existing service discovery protocol, DNS-based Service Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] provides service discovery. =>
To discover instances of a demanded service in vehicular networks DNS-based Service Discovery (DNS-SD) [RFC6763] with Multicast DNS [RFC6762] provides such feature, using standard DNS queries. 

via RSU1 and RSU2 via V2I communication => via RSU1 and RSU2 employing V2I (i.e. V2I2V) communication

of a mobile device (e.g., vehicle) => of a mobile (e.g., vehicle-mounted) device 

accommodation of proactive protocols because it is usually equipped with a GPS receiver. => accommodation of (mobility aware) proactive communication protocols. [i.e. independent of where the mobility information is originating from - may also be the cellular network!]

Vehicles can use the TCC as its Home => Vehicles can use the TCC as their Home / A vehicle can use the TCC as its Home

It recommebs => It recommends 

Figure 2: I miss the 2nd/3rd interface of RSU towards Internet (cloud) and other RSU as shown in Figure 1.

LTE D2D (Device to Device), => LTE Uu and D2D (Device to Device), aka. sidelink PC5 [TS-23.285-3GPP], 

Figure 3: I suggest to use not same node names for vehicle2 as used in Figure 2 for RSU1, so Router3 => Router5, RDNSS2 => RDNSS3 etc.!

Security protects vehicles roaming => strong security measures shall protect vehicles roaming

interface is used, which the interface's identifier is changed => interface should be used, with the help of which the interface's identifier can be changed 

test yet => tested yet

Ch. 5

a GPS navigator as a dedicated navigation system or a smartphone App. With this GPS navigator, =>
a GPS receiver as part of a dedicated navigation system or a corresponding smartphone App.  In case the provided location information is precise enough (well-known temporary degradations in precision may occur due to system configuration or the adverse local environment) or the precision is improved thanks to assistance by the RSUs or a cellular system with this navigation system, 

horizontal/vertical handover: I haven't found the definition here - is V2V/V2I HO meant?

Such an update of the MAC and IPv6 addresses
   should not interrupt the end-to-end communications between two
   vehicular nodes (e.g., vehicle and RSU) in terms of transport layer.

We should add here that this is a long living challenge in higher layers!

Appendix:

an intersection area, which is a coordinator for the access to wireless channels => an intersection area, where the cluster head can work as a coordinator for the access to wireless channels

Neighbor Discovery (called ND) => Neighbor Discovery (ND)

The emerging services, functions and applications in automotive industry spurs ehhanced V2X (eV2X)-based services in the future 5G era.  The 3GPP Technical Report [TR-22.886-3GPP] is studying new use cases for V2X using 5G in the future.
=> The emerging services, functions, and applications developped in automotive industry demand for reliable and efficient communication infrastructure for road networks. Correspondingly the support of enhanced V2X (eV2X)-based services by future converged and interoperable 5G systems is required.  The 3GPP Technical Report [TR-22.886-3GPP] is studying new use cases and corresponding service requirements for V2X (including V2V and V2I) using 5G in both infrastructure mode and the sidelink variations in the future.

Thanks a lot!
Best Regards
Dirk 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Montag, 16. Juli 2018 11:35
To: [email-masked]
Cc: [email-masked]
Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its

---

From: François Simon <[email-masked]>
Date: Sun, 29 Jul 2018 07:58:09 -0400

" For direct inter-vehicular wireless connectivity IEEE has amended WiFi
standard 802.11 to enable driving safety services based on the DSRC in terms
of standards for the Wireless Access in Vehicular Environments (WAVE)
system.  L2 and L3 issues are addressed in IEEE 802.11p [IEEE-802.11p],
security aspects are covered in IEEE 1609.2 [WAVE-1609.2], while IEEE 1609.3
[WAVE-1609.3] defines related services at network and transport layers and
IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel operation."

- In the US, DSRC denotes only the MAC and PHY specified in IEEE Std
802.11-2016; OCB mode.  WAVE applies to 1609.2, 1609.3, 1609.4, and 1609.12.

" DSRC-based vehicular networks can be used for V2I in near future [DSRC]. I
doubt this, especially since the reference is from 2010! ;-) What about:
Some players expect that DSRC-[DSRC] based vehicular networks will be
availabel for V2I in the future.[?]"

-In the US, there is no distinctions  in DSRC (MAC and PHY) for V2I and V2V.

Fygs

-----Original Message-----
From: its <[email-masked]> On Behalf Of [email-masked]
Sent: Friday, July 27, 2018 9:27 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ipwave] I-D Action:
draft-ietf-ipwave-vehicular-networking-04.txt

Dear Jaehoon, all,

I also volunteered in Montreal to review this draft which is a good starting
point to identify work items for the future.
I mainly agree with comments already made - especially on the privacy
challenges and IP addresses - and would like to add some partly more
editorial comments:

I suggest to add already in the abstract the clarification (given later in
ch. 3) that X in V2X is understood here as everything else than I and V ...
if used together with V2V and V2I.
I suggest to replace in Ch.1:
For driving safety services based on the DSRC, IEEE has standardized Access
in Vehicular Environments (WAVE) standards, such as IEEE 802.11p
[IEEE-802.11p], IEEE 1609.2 [WAVE-1609.2], IEEE 1609.3 [WAVE-1609.3], and
IEEE 1609.4 [WAVE-1609.4].  
By
For direct inter-vehicular wireless connectivity IEEE has amended WiFi
standard 802.11 to enable driving safety services based on the DSRC in terms
of standards for the Wireless Access in Vehicular Environments (WAVE)
system.  L2 and L3 issues are addressed in IEEE 802.11p [IEEE-802.11p],
security aspects are covered in IEEE 1609.2 [WAVE-1609.2], while IEEE 1609.3
[WAVE-1609.3] defines related services at network and transport layers and
IEEE 1609.4 [WAVE-1609.4] specifies the multi-channel operation.

Furthermore I suggest to put references near the related terms e.g.: 
IPv6 and Mobile IP protocols (e.g., MIPv4 and MIPv6) can be extended to
vehicular networks [RFC8200][RFC5944][RFC6275] =>
IPv6 [RFC8200] and Mobile IP protocols (e.g., MIPv4 [RFC5944] and MIPv6
[RFC6275]) can be applied or easily modified to vehicular networks.

Also, it also discusses relevant work items to IPWAVE => Also, it discusses
relevant and potential new work items to IPWAVE WG

An RSU is deployed either at an intersection or in a road segment => An RSU
is typically deployed at an intersection or in a road segment, but may also
be located in car parking areas 

communications with other OBUs and RSUs. => communications with other OBUs
and RSUs and may be connected to in-vehicle devices or networks

a vehicular cloud should be defined (I guess it shall just denot cloud
infrastructure for vehicular networks and not computing resources
distributed across a multitide of vehicles?

Ch.3:

Vehicle-to-Device (V2D) is never used again - isn't it always in the end a
device? Perhaps better to add other Vulnerable Road Users (RSUs) as
cyclists/bicycles ...

share environmental information from various sensors, such as radars, LiDARs
and cameras, mounted on them with other vehicles => share environmental
information from various vehicle-mounted sensors, such as radars, LiDARs and
cameras, with other vehicles 

for the global road traffic optimization => for the large-scale/long-range
road traffic optimization [IMHO true _global_ optimization is wishful
thinking ;-)]

DSRC-based vehicular networks can be used for V2I in near future [DSRC]. I
doubt this, especially since the reference is from 2010! ;-) What about:
Some players expect that DSRC-[DSRC] based vehicular networks will be
availabel for V2I in the future.[?]

collision of a pedestrian and a vehicle, which have a smartphone, in a road
network. => collision of a vehicle and a pedestrian carrying a smartphone
equipped with corresponding access technology.

RSU that delivers scheduling information for wireless communication to save
the smartphones' battery: Not clear which role RSU plays: that of a cellular
base station or WiFi-AP to connect to smartphone? Can you please elaborate?

Ch.4:

We analyze the current protocols from the following aspects: => We describe
some currently existing/proposed protocols with respect to following aspects
relevant/essential for vehicular networking:

conducted a comprehensive study of the cross-layer identities management in
vehicular networks using multiple access network technologies, which
constitutes a fundamental element of the ITS architecture => conducted for
heterogeneous vehicular network (i.e. employing multiple access
technologies) a comprehensive study of the cross-layer identities
management, which constitutes a fundamental element of the ITS architecture

speeds of vehicles are varied => speeds of vehicles are highly
variable/strongly varying

For service discovery, as a popular existing service discovery protocol,
DNS-based Service Discovery (DNS-SD) [RFC6763] with mDNS [RFC6762] provides
service discovery. => To discover instances of a demanded service in
vehicular networks DNS-based Service Discovery (DNS-SD) [RFC6763] with
Multicast DNS [RFC6762] provides such feature, using standard DNS queries. 

via RSU1 and RSU2 via V2I communication => via RSU1 and RSU2 employing V2I
(i.e. V2I2V) communication

of a mobile device (e.g., vehicle) => of a mobile (e.g., vehicle-mounted)
device 

accommodation of proactive protocols because it is usually equipped with a
GPS receiver. => accommodation of (mobility aware) proactive communication
protocols. [i.e. independent of where the mobility information is
originating from - may also be the cellular network!]

Vehicles can use the TCC as its Home => Vehicles can use the TCC as their
Home / A vehicle can use the TCC as its Home

Figure 2: I miss the 2nd/3rd interface of RSU towards Internet (cloud) and
other RSU as shown in Figure 1.

LTE D2D (Device to Device), => LTE Uu and D2D (Device to Device), aka.
sidelink PC5 [TS-23.285-3GPP], 

Figure 3: I suggest to use not same node names for vehicle2 as used in
Figure 2 for RSU1, so Router3 => Router5, RDNSS2 => RDNSS3 etc.!

Security protects vehicles roaming => strong security measures shall protect
vehicles roaming

interface is used, which the interface's identifier is changed => interface
should be used, with the help of which the interface's identifier can be
changed 

test yet => tested yet

Ch. 5

a GPS navigator as a dedicated navigation system or a smartphone App. With
this GPS navigator, => a GPS receiver as part of a dedicated navigation
system or a corresponding smartphone App.  In case the provided location
information is precise enough (well-known temporary degradations in
precision may occur due to system configuration or the adverse local
environment) or the precision is improved thanks to assistance by the RSUs
or a cellular system with this navigation system, 

horizontal/vertical handover: I haven't found the definition here - is
V2V/V2I HO meant?

Appendix:

an intersection area, which is a coordinator for the access to wireless
channels => an intersection area, where the cluster head can work as a
coordinator for the access to wireless channels

The emerging services, functions and applications in automotive industry
spurs ehhanced V2X (eV2X)-based services in the future 5G era.  The 3GPP
Technical Report [TR-22.886-3GPP] is studying new use cases for V2X using 5G
in the future.
=> The emerging services, functions, and applications developped in
automotive industry demand for reliable and efficient communication
infrastructure for road networks. Correspondingly the support of enhanced
V2X (eV2X)-based services by future converged and interoperable 5G systems
is required.  The 3GPP Technical Report [TR-22.886-3GPP] is studying new use
cases and corresponding service requirements for V2X (including V2V and V2I)
using 5G in both infrastructure mode and the sidelink variations in the
future.

Thanks a lot!
Best Regards
Dirk 

-----Original Message-----
From: its [mailto:[email-masked]] On Behalf Of
[email-masked] <mailto:[email-masked]> 
Sent: Montag, 16. Juli 2018 11:35
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [ipwave] I-D Action: draft-ietf-ipwave-vehicular-networking-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP Wireless Access in Vehicular
Environments WG of the IETF.

        Title           : IP Wireless Access in Vehicular Environments
(IPWAVE): Problem Statement and Use Cases
        Author          : Jaehoon Paul Jeong
	Filename        : draft-ietf-ipwave-vehicular-networking-04.txt
	Pages           : 30
	Date            : 2018-07-16

Abstract:

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-04
https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking
-04

_______________________________________________
its mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/its

_______________________________________________
its mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/its