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

[John Kenney <[e-mail]>]

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]