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

[Alexandre Petrescu <[e-mail]>]

Le 20/06/2019 à 17:14, Jérôme Härri a écrit :
> 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 :-) )...

I agree we should distinguish the two terms.  To that end, we would need 
to agree on the names of the terms.

On my side, I will use 'open-source' OCB vs 'proprietary' OCB.

You seem to be used DOTa/10MHz vs 'automotive-grade'.  You used other 
terms as well.

Other people I heard also saying to me that I just use an 'a' driver 
modified.  I did not know that, but I agree to them.

> 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...

The 'automotive-grade' is thus not a DOTa/10MHz.  I think the 
'automotive-grade' OCB is something like Autotalks chips.  That is 
closed source, not open source.  That is something much more expensive 
than DOTa/10MHz.

I thank you for the recommendation to use 'automotive-grade' OCB.  I 
consider it, but I am not likely to use it, because of cost.

It is for this reason that I think I will skip the use of 
'automotive-grade' OCB towards increasing the bandwidth.

Others may do differently. (try first 'automotive-grade' OCB to obtain 
higher bandwidth than DOTa/10MHz).

I would rather look at trying the DOTa/10MHz with a 20MHz channel width. 
  Also try the OCB patch on ath10k driver.  Maybe I will get as much 
bandwidth, or even more, than the automotive-grade OCB, and at a lower cost.

> 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 :-)

I agree with you.

What do you mean by 'dynamically adapting the modulation'?  Do you mean 
it is possible to use an 'iw' command to select a modulator like 'ofdm' 
vs 'something-else-dm'?

Alex

> 
> 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]
>> 
> 
>