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
