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

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

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]> 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]] On Behalf Of Alexandre Petrescu
Sent: Wednesday 12 June 2019 20:05
To: [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]
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]