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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 14 Aug 2018 13:10:05 +0900

Hi Dirk and François,
Thanks for your valuable comments,

I will reflect your comments on the revision.

Thanks.

Best Regards,
Paul

On Sun, Jul 29, 2018 at 8:58 PM, François Simon <[email-masked]> wrote:

> *"** 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, t**here 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.
>
> 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] <[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
>
> 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/
>
> _______________________________________________
>
> its mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
>
> its mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/its
>
> _______________________________________________
> its mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/its
>
>

-- 
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>

---

From: Michelle Wetterwald <[email-masked]>
Date: Fri, 31 Aug 2018 16:54:57 +0200

Hi Paul,

During the Montreal meeting, I committed as well to review the draft but
could not make it before my holidays. Please find attached a marked Word
file with all my comments.
Best regards,
-- 
Michelle Wetterwald
[email-masked]

Le lun. 16 juil. 2018 à 11:35, <[email-masked]> a écrit :

> https://datatracker.ietf.org/doc/html/draft-ietf-ipwave-vehicular-networking-04
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ipwave-vehicular-networking-04
>
>
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>