Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid

[Jérôme Härri <[e-mail]>]

Hi Alex,

The automotive-grade ITS-G5/DSRC devices have an enhanced PHY (something called channel tracking, among other things that I am most likely not aware...). If you are interested, this is a nice paper illustrating the issues of regular DOT11p devices confronted to fast time varying channels..."Andre Bourdoux, Hans Cappelle, Antoine Dejonghe, Channel Tracking for Fast Time-Varying Channels in IEEE802.11p Systems, IEEE globecome 2011"
Such enhanced PHY is located in the wifi modem, not in a driver (that is the 'closed/protected' part of the wifi stack in linux)...I am not aware of a way to be able to add this on a linux wifi driver. But such enhancement really adds more reliability to the ITS-G5/DSRC system (increased range, improved PDR)..

But you are correct...using the wifi DOTa with OCB at 10Mhz follows the standard...it is a valid DOT11p device...but it is not the best an Wifi-V2X system can do...My point is to say that all WiFi OCB/10Mhz are WiFi-V2X but not all WiFi-V2X are WiFi OCB/10MHz..and as in any field, there are better products than others (thus the business behind it :-) )...

So, using an 'automotive-grade' (I use brackets as indeed this usually refer to more than just performance...) could be one option to get closer to the performance you need...but of course, and as I mentioned in my early e-mail, it might not be enough for the very reason that DOT11p (generic and automotive-grade) have been designed with the performance requirements identified for Day One applications, not Day Two...

So indeed, increasing bandwidth (20Mhz) or dynamically adapting modulation or replacing DOT11p with DOT11bd are other potential strategies...and stakeholders are very aware of this...there is a need for more capacity, thus we need to do something to get it :-)
 
Best Regards,

Jérôme  

-----Original Message-----
From: Alexandre Petrescu [mailto:[e-mail]] 
Sent: Thursday 20 June 2019 16:12
To: Jérôme Härri; 'John Kenney'
Cc: 'its'
Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to avoid

I think all I am talking about is what you call a DOT11a/10MHz patch. 
IT is actually no longer a patch, because OCB is now integrated in the 
linux mainline kernel.

I am talking linux, because BSD does not support OCB.

Whereas I agree with you that the 'automotive grade' qualifier is 
commonly used to indicate higher quality, on my side I think it is used 
to justify more expensive OCB devices than others.  I can not say I 
understand what the quality is about.

It may be that what is meant by quality for some, is less quality for 
others.

It may be that what is meant by 'quality' in laboratory, is something 
that never sees the light in the streets.

It may be that a higher quality product acts excellent when everybody is 
in a single channel, but less well when multiple channels are used.

Since this spectrum is not under the control of authority, it is hard to 
define what is quality.  But it is easy to experiment.

That, said, I can tell the numbers in my trials.  It is with linux, 
cheap WiFi 'a'  cards, and OCB open source in mainline kernel.

Between two cars, the IPv6 bandwidth with iperf TCP packets peaks at 
around 7mbit/s.  During that flow, the RTT of ping is about 50ms.  On an 
empty channel (no iperf traffic), the RTT of ping is on average 1.4ms.

What I need is to be able to allow the RTMAPS programmers to send their 
packets with a frequency of 20kHz.  (20.000 TCP/IPv6 packets per 
second).  When they try that, the latency they get is around 500ms.  It 
is way too much.  It means the distance between platooned cars is way 
too much.

20kHz may appear as a programmer error, but it is not.  The programmer 
should not be told to reduce their output.  It is the network that must 
accommodate it.

If in my OCB  deployment I get a bandwidth at around 1Gbit/s (vs. 
current 7Mbit/s), then I can share the lidar data between cars.  That 
translates to huge reduction in cost.  The cheapest lidar is around 
7Keur, but most expensive can be 30Keur.  A cheap car is cheaper than a 
lidar.

Some of the lidars are connected on Gbit Ethernet.

A higher than current 7Mbit/s on OCB can be obtained by several means:
- try the iw command to use 20MHz width, instead of 10.  It would
   theoretically increase the bandwidth to 14Mbit/s.  It's not 1Gbpbs,
   but it's more.
- other linux commands?
- make the OCB patch apply to ath10k, not the ath9k currently.  That is
   something that nobody tried.  Even if one does not have an ath10k 
card (802.11ac) one could still try to adapt the OCB patch for the C 
code, and see whether it compiles.  If it compiles, it is already a good 
step forward.  We'll see later about the execution.

Maybe you know other means by which to achieve higher bandwidth on OCB?

Alex

Le 20/06/2019 à 15:49, Jérôme Härri a écrit :
> Hi John, Alex,
> 
> Thanks for the details.
> 
> I would also like to add another point that I forgot to mentioned. @Alex 
> did not mention if the DOT11p radio is an automotive-grade or a 
> DOT11a/10Mhz patch…
> 
> Of course, both are valid OCB devices BUT…it has been shown on many 
> occasions that the performance of a DOT11a patched for OCB/10Mhz show 
> significantly lower performance compared to the state-of-art automotive 
> grade ITS-G5 devices.
> 
> If the tests have been done with a DOT11a patched OCB, then this could 
> also be a reason for the limited capacity. Generally speaking, the 
> current automotive-grade ITS-G5 devices are not DOT11a/10Mhz patched 
> devices anymore and have enhanced PHY features that make around 3-5 dB 
> gain in BER/SNR curves compared to normal patched DOT11a. This is 
> significant !!
> 
> But indeed, these devices are more expensive than a normal wifi chip and 
> if a normal wifi board is patched for OCB/10Mhz, then it is an IEEE 
> 802.11p device. They can clearly be used for networking (ip, ad-hoc, 
> etc..) test, but I would suggest not to use these patched devices as a 
> reference for link-layer/capacity tests, as they do not really represent 
> what an automotive-grade ITS-G5/DSRC is really capable of doing.
> 
> BR,
> 
> Jérôme
> 
> *From:*John Kenney [mailto:[e-mail]]
> *Sent:* Saturday 15 June 2019 02:25
> *To:* Jérôme Härri
> *Cc:* Alexandre Petrescu; its
> *Subject:* Re: [ipwave] Higher bandwidth is a requirement, not a number 
> to avoid
> 
> Hi Jérôme and Alex,
> 
> Sorry I have not followed this discussion in detail.  If any of my 
> comments are off base, I apologize.
> 
> Having read Jérôme's comments, I want to agree with them.  I especially 
> want to emphasize that if we are considering operating in public 
> spectrum (5.9 GHz in most regions) we have to be cognizant of how our 
> channel use may impact other users whose applications are equally 
> important from a public safety perspective, perhaps even more 
> important.  This is one reason why so many resources have been devoted 
> to researching and testing channel scalability protocols (congestion 
> control).  In the US, the FCC bandplan and the SAE J2945/0 standard 
> channel usage plan specify that every channel will be available for use 
> by safety applications.
> 
> One additional note about channel bandwidth.  IEEE 802.11 specifies 
> channel width options of 20 MHz, 10 MHz, and 5 MHz in the 5.9 GHz bands 
> of the US and Europe.  Spectrum regulations further limit those to 20 
> MHz and 10 MHz in the US and only 10 MHz in Europe.  However, while 20 
> MHz channels are in the FCC regulations for the US, we do not expect 
> overlapping 20 MHz and 10 MHz to be used in the same time and place. 
> CSMA/CA will not work well in such an overlapping case because the 
> devices will not natively detect each other's preambles.  In fact, 10 
> MHz usage is the norm, and we do not expect to see 20 MHz usage in the US.
> 
> This may change with the development of IEEE 802.11bd (Next Generation 
> V2X), which Jérôme mentioned.  That task group is considering ways to 
> specify a 20 MHz channel that coexists well with constituent 10 MHz 
> users (both 802.11bd and 802.11p).
> 
> One final point.  Some V2X researchers are quite interested in using 60 
> GHz mmWave spectrum for dissemination of information requiring bit rates 
> on the order of 100s Mbps or 1 Gpbs.  This is an active area of 
> research.  This may be a better option for high bit rate V2X 
> communication than 5.9 GHz, though of course it has different 
> characteristics and constraints.
> 
> Best Regards,
> 
> John
> 
> On Thu, Jun 13, 2019 at 2:00 AM Jérôme Härri <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     Dear Alex,
> 
>     You are totally right…applications have increased needs and it is
>     not the right wat to tell an application to send less because of
>     finite capacity of a given technology. One thing to keep in mind
>     though is that the ITS-G5/DSRC has been designed for the needs of so
>     called ‘day one’ applications (e.g. intersection collision
>     avoidance, lane change warning etc..) and it is quite clear that the
>     technology is not adapted to other applications, which would require
>     more capacity (say it is not the fault of the technology, as it has
>     been designed for something and not for something else).
> 
>     The applications you are working on fall within the ‘Day two’ or
>     ‘Day two and half’  (sorry, I am not the one giving these names…just
>     referring to them..) and for these new applications there is
>     absolutely a need for more capacity. In short, we need to find
>     better and more efficient ways to transmit much more data for ITS
>     applications, and indeed not say that people should transmit less J
> 
>     And this is very clear in ETSI, C2C-CC, SAE, even 5GAA…there are
>     specific WG discussing new spectrum usage (10Mhz vs. 20Mhz,
>     multi-channels, etc..) and the current direction to fulfill the
>     capacity requirements of these news applications are either IEEE
>     802.11bd (the next generation wifi-based V2X) or 5G-V2X (the next
>     generation C-V2X technology), as frequency rechannelization is
>     complex in terms of coexistence and using multi-channels require
>     multi transmitters…
> 
>     In this perspective, your proposed modification might be seen as a
>     temporary patch but if it works for your case, that is good, as
>     there is nothing else available at that time…And if you propose a
>     simpler way of getting more capacity to match day two applications
>     with day one technology, well this is what I would call research J…
> 
>     The point in my previous e-mail was that putting 20MHz in ‘iw’ on an
>     ocb firmware will change a few things at the physical layers that
>     will affect the performance (in good or bad) of your system..for
>     instance, the OFDM guard period will be halved, which will make your
>     link more sensitive to delay long spreads, or will lose 3dB in
>     receiver sensitivity, which would impact your Tx range. As I said in
>     my previous e-mails, there are various teams that have been
>     questioning the 10Mhz channel since a ‘very’ long time now…so, there
>     is no scientific reasons for not trying at 20Mhz and see how it
>     goes…yet, it will not be compatible with the current
>     standards/regulations at that time…(but does not mean it would not
>     change in the future J)
> 
>     Please have a look at some of the work from Prof. Eric Ström of
>     Chalmers (a nice summary is available here:
>     https://pdfs.semanticscholar.org/78ef/e53d238ae75837f5817997f27c74f1519698.pdf). 
>     In short, there are clearly performance gains in perspective…but it
>     ‘really’ depends on some parameters of the channel that you will
>     face during your tests. The most important one is the delay spread.
>     Eric mentions that a 4nSec is usually agreed, but there are other
>     studies indicating delay spreads up to 8nsec (also acknowledged by
>     Eric)…so, it would simply be interesting to test and see how it
>     works in your case…it would be good if you could have in your team
>     or project partners expect in PHY/Channel sounding to double check
>     the PHY impact of your strategy in your environment…
> 
>     To conclude, although not fitting to current spectrum regulations,
>     trying 20Mhz is good as it gets and there are many people believing
>     that this could actually help…but it might not be sufficient for
>     your applications (you might not double capacity by doubling the
>     bandwidth)…There will be much more benefits from the next generation
>     V2X technologies in the very near future (also indicated by Eric in
>     its slides, page 24) , which will fulfill your required
>     performance…that is why I mentioned that for your required
>     applications, you should follow what IEEE 802.11bd or 5G-V2X will
>     are actively being developed as we speak.
> 
>     Best Regards,
> 
>     Jérôme
> 
>     *From:*its [mailto:[e-mail]
>     <mailto:[e-mail]>] *On Behalf Of *Alexandre Petrescu
>     *Sent:* Wednesday 12 June 2019 20:05
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Subject:* [ipwave] Higher bandwidth is a requirement, not a number
>     to avoid
> 
>     Hi,
> 
>     With respect to the channel width 20MHz capability, which would
>     probably offer higher bandwidth and less latency.
> 
>     I received in private several replies from at least 4 people.  I
>     also had a face to face meeting with our partners.
> 
>     I want to say something so I am better understood: it is a
>     _requirement_ to get higher bandwidth; it is not a number to avoid.
> 
>     If the app people send 10000 RTMAPS 1480byte sized IP messages per
>     second then it is so because they need it.  Yes, that is 10KHz
>     messages, and not 20Hz; yes, that is 1428byte IP message and not
>     CAM/BSM 633byte.  And yes, that must be satisfied.  We should not
>     tell these people to reduce their outputs.  Reducing their outputs
>     will indeed guarantee better latency for ping, but they will be less
>     able to transmit valuable data.
> 
>     We should not tell app people to throttle (reduce) their output down
>     to 20 messages per second (20Hz).  That is nonsense out of standard
>     documents.  The 20Hz/10Hz/1Hz is data relevant out of GPS chipsets -
>     GPS has nothing to do with OCB.
> 
>     If in the first platooning tests it worked with less data
>     transmitted, also the convoy was less performing.  We need rich data
>     transmitted, not poor data.  We need lidar data out of the lidar
>     directly on OCB, and similar other things.
> 
>     Alex
> 
>     _______________________________________________
>     its mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/its
> 
> 
> -- 
> 
> John Kenney
> 
> Director and Sr. Principal Researcher
> 
> Toyota InfoTech Labs
> 
> 465 Bernardo Avenue
> 
> Mountain View, CA 94043
> 
> Tel: [phone]. Mobile: [phone]
>