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

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

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