Re: [ipwave] use-cases in Problem Statement

[NABIL BENAMAR <[e-mail]>]

It's a good idea to refer to Vulnerable Road Users which refer to bicycles
as well as pedestrians.

On Wed, Apr 17, 2019, 12:12 Alexandre Petrescu <[e-mail]>
wrote:

>
>
> Le 16/04/2019 à 05:11, Sri Gundavelli (sgundave) a écrit :
> >> I am no expert, but I do know some physics, and it seems pretty
> >> clear to me that if there are multiple lanes of traffic, a large
> >> truck can easily shield signals between two cars and the shielding
> >>  will be intermittent, regardless of how much wireless power is
> >> allowed, depending on traffic movement. So it's a highly dynamic
> >> mesh network.
> >
> >
> > Part of the problem is that we have not clearly put some limits on
> > the use-cases. These unbounded limits is opening up these discussions
> > on ad-hoc full mesh network formations and the resulting challenging
> > ND scenarios. But, again I always assumed this discussion is for the
> > ND document and there should be no bearing on this document.
> >
> > V2X communications involves V2V, V2I and V2P communication modes.
>
> For the term V2P (Vehicle to Pedestrian) I would like to suggest
> addition of term VRU as well: Vulnerable Road Users.  I suggest the new
> term V2VRU: Vehicle to VRU.
>
> VRUs dont have OCB interfaces (smartphones's wifi interfaces cant be set
> at 5.9GHz), yet they are at most risk since they are not protected by
> cages like the  automobiles are.
>
> V2VRU is a problem, because OCB-equipped vehicles can communicate to
> OCB-free VRUs only by means of high-latency cellular network (50ms 4G vs
> 1.5ms OCB).  In safety, lower latency is preferred over higher latency.
>
> I would like to suggest the above addition in the Problem Statement
> draft, section 3 "Use Cases".
>
> > From the point of view of vehicular safety, its about exchange of BSM
> > (Basic Safety Messages) between vehicles as per SAEJ735 standard.
> > These safety communications is always one-hop communication and for
> > very good reason IEEE WAVE standards did not bother to require IPv6
> > transport for carrying these messages. The WSMP message which carries
> > these safety elements are defined to be carried over layer-2
> > payloads. Personally, I never thought we will replace this L2 safety
> > communication mode with layer-3 mode (IPv6-over-80211-OCB). But the
> > use of IPv6 is more for allowing applications in the vehicle to
> > communicate with the infrastructure. For example, a vehicle using
> > DSRC radio to access some traffic application in the cloud.
> >
> > In one sense, this is like a mobile node using 802.11-OCB like any
> > other radio technology (CDMA, LTE, Wi-Fi), and use IPv6 for its
> > communications. In this context, its always about vehicle to
> > infrastructure communications.
>
> I would like to suggest addidion of text about "BSM" in the Problem
> Statement draft.
>
> The localisation corrections are highly needed in OCB, potentially with
> BSM and/or other V2X message.
>
> > Now, there are other interesting peer to peer use-cases, where one
> > vehicle is streaming some video to another vehicle without using any
> > infrastructure.
>
> I would like to suggest to add in section "V2V" in the Problem Statement
> draft the following text:
>
> NEW:
> > o  see thru: streaming video from one vehicle to another vehicle
> > without using any infrastructure, to see through obstacles
>
>
>
> > While these later examples are very cool, personally, I did not
> > expect this WG to solve those use-cases day-1.
>
> I would like to suggest the addition of the term "day-1" to the Problem
> Statement draft.
>
> > For us to support those use-cases, we need to figure out many more
> > things including approaches for exchanges prefixes between two
> > vehicles that come in proximity. In my mind, these are very forward
> > looking and the only relevant application is platooning. I am not
> > interested in solving this V2V problem, but was more interested to
> > enable V2I communications, where the focus is about link model,
> > prefix hosting approaches, mobility support (building a large L2
> > domain over RSU’s, or routed approaches with mobile IP type
> > protocols) ..etc. In one realization, there may be a P2P link
> > assumption between the vehicle and the RSU, eliminating most of these
> > ND issues. But, those discussions are for the other document and that
> > clearly should remove these ND concerns from this document.
>
> I agree.
>
> Alex
>