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 <alexandre.petrescu@xxxxxxxxx> 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
