Hi Alex, Well, VRU will have OCB...but it depends on what you call VRU...for example, motorcycles and scooters are both part of VRUs and the CAR2CAR currently develops an adapted ITS-G5 system for them. Yet, for pedestrian, indeed no OCB foreseen so far...so, if it is about knowing who has OCB or not (say: can use OCB or cannot use), then V2VRU might be too large denomination.. BR, Jérôme -----Original Message----- From: its [mailto:its-bounces@xxxxxxxx] On Behalf Of Alexandre Petrescu Sent: Wednesday 17 April 2019 13:13 To: Sri Gundavelli (sgundave); Brian E Carpenter; NABIL BENAMAR Cc: Pascal Thubert (pthubert); ietf@xxxxxxxx; its@xxxxxxxx; int-dir@xxxxxxxx; draft-ietf-ipwave-ipv6-over-80211ocb.all@xxxxxxxx; nabil benamar Subject: Re: [ipwave] use-cases in Problem Statement Le 16/04/2019 ` 05:11, Sri Gundavelli (sgundave) a icrit : >> 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 RSUs, 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 _______________________________________________ its mailing list its@xxxxxxxx https://www.ietf.org/mailman/listinfo/its
