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

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 12 Jun 2019 20:05:27 +0200

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

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 13 Jun 2019 11:00:24 +0200

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

---

From: John Kenney <[email-masked]>
Date: Fri, 14 Jun 2019 17:25:28 -0700

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 <[email-masked]>
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:[email-masked]] *On Behalf Of *Alexandre
> Petrescu
> *Sent:* Wednesday 12 June 2019 20:05
> *To:* [email-masked]
> *Subject:* [ipwave] Higher bandwidth is a requirement, not a number to
> avoid
>
>
>
> Hi,
>
> I received in private several replies from at least 4 people.  I also had
> a face to face meeting with our partners.
>
> 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.
>
> _______________________________________________
> its mailing list
> [email-masked]
> 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: 650-694-4160. Mobile: 650-224-6644

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 20 Jun 2019 15:49:38 +0200

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:[email-masked]] 
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 <[email-masked]> wrote:

Dear Alex,

Best Regards,

Jérôme  

Hi,

Alex

 

-- 

John Kenney

Toyota InfoTech Labs

465 Bernardo Avenue

Mountain View, CA 94043

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Jun 2019 16:11:44 +0200

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:[email-masked]]
> *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,
> 
> 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.
> 
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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…
> 
>     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:
>     ‘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
>     *From:*its [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Alexandre Petrescu
>     *To:* [email-masked] <mailto:[email-masked]>
>     *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.
> 
>     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
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 20 Jun 2019 16:12:36 +0200

[...]
> as they do not really represent 

What is the bandwidth of IPv6 demonstrated on ITS-G5/DSRC?

Alex

---

From: Jérôme Härri <[email-masked]>
Date: Thu, 20 Jun 2019 17:14:54 +0200

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:[email-masked]] 
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

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Jun 2019 11:30:17 +0200

Le 20/06/2019 à 16:49, Dick Roy a écrit :
> Sent: Thursday, June 20, 2019 7:13 AM
> */[RR] IPV6 does not “have a bandwidth”.  The ITS-G5/DSRC access layers 
> currently have 10MHz (and 20MHz in the US)bandwidth channels specified 
> if that’s your question./*

What is the bandwidth afforded by an application using TCP/IPv6 on 
ITS-G5/DSRC?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 21 Jun 2019 13:12:32 +0200

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:[email-masked]] 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
>> 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:[email-masked]] *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,
>> 
>> 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
>> <[email-masked] <mailto:[email-masked]>>
>> wrote:
>> 
>> Dear Alex,
>> 
>> 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).
>> 
>> ‘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
>> 
>> 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
>> 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…
>> 
>> 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
>> 
>> *Sent:* Wednesday 12 June 2019 20:05 *To:* [email-masked]
>> <mailto:[email-masked]> *Subject:* [ipwave] Higher bandwidth is a
>> requirement, not a number to avoid
>> 
>> Hi,
>> 
>> 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.
>> 
>> 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

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 22 Jun 2019 17:36:49 +0200

When people write apps they need to know the bandwidth they could 
afford.  E.g. I could be brave and try write skype with HD video and 
192KHz audio but that would never work on 56Kbit/s bandwidth modem.

Remark I am saying HD video, and people understand approximately what 
kind of bandwidth is needed, assuming a certain encoder ranging from no 
compression to high performance H. something.  I am also saying 192KHz 
which is a sampling rate (not bandwidth) but people understand what kind 
od bandwidth that would request, depending on the encoder used ranging 
from RAW (no compression) to high quality open source compression in Ogg.

Avoiding numbers of bandwidth available for IPv6 on ITS-G5 for 
high-quality chipsets means that probably the high quality chipsets 
never tried to send IPv6 on it.  OTherwise they could have seen the 
bandwidth.

On another hand, the bandwidth afforded by IPv6 iperf command on an open 
source DOT11a/10MHz driver is approximately 7mbit/s.  This is why there 
is where the focus of a standard should be: on the open source 
DOT11a/10MHz basis, not on the high-quality chipsets.

Of course, there are also the theoretical numbers (1Mbit/s, 2, 5, 16, 
48, etc). They are obtained from calculations on numbers, not from 
experimenting.   These numbers are theoretical upper limits of actual 
banwidth.  It is well known these limits are never reached.

Le 21/06/2019 à 22:09, Dick Roy a écrit :
>
> “What is the bandwidth afforded by an application using TCP/IPv6 on
>
> ITS-G5/DSRC?”
>
> Applications don’t have bandwidths.  They may have information (aka 
> data) rate requirements often specified in [G/M/K]bits per second, not 
> in Hertz.  Whether or not any particular network and transport layer 
> technology is used is irrelevant.  Not sure what you are asking.
>
> RR
>
> Sent: Friday, June 21, 2019 2:30 AM
> To: [email-masked]; 'Jérôme Härri'; 'John Kenney'
> Cc: 'its'
> > Subject: Re: [ipwave] Higher bandwidth is a requirement, not a number to
>
> > avoid
>
> > 
>