Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [STDS-802-11-TGBD] NGV 20MHz M/O support



Hi Joh, Friedbert, Rui, and All,

 

The discussion on if 20 MHz is mandatory or optional for NGV, is independent from the discussion of if 20 MHz will be allowed in specific regulatory regions for the following reasons:

  1. If the regulatory rules in a region do not allow 20 MHz operation, then the device will not enable 20 MHz operation, this is independent of if it can support 20 MHz operation.
  2. Cars do not necessarily stay in one regulatory region, hence a car may move between regulatory domains that support or do not support 20 MHz operation.
  3. Regulatory rules may change as technology develops – but hardware capabilities are permanent.
  4. Making 20 MHz mandatory does not mean a STA must always transmit/receive 20 MHz – it only means it is capable of transmitting and receiving 20 MHz when it is allowed/configured by higher layers to do so.

 

The only reason in my view to make 20 MHz optional is to allow devices to be built as 10 MHz only devices.  Doing so may allow for a simple device to be built, but we already have such a device specified in the current 802.11 standard.  If we are going specify NGV STAs so that they have significant new features relative to the current specification, I think adding a 20 MHz PPDU compatible with the current 10 MHz PPDUs should be one of these features.  Therefore I think is should be mandatory.  Also, I don’t think adding such a 20 MHz PPDU would significantly increase the complexity of a NGV STA.

 

Regards,

Joseph 

 

From: ** STDS-802-11-TGbd -- Enhancements for Next Generation V2X.Task Group ** <STDS-802-11-TGBD@xxxxxxxxxxxxxxxxx> On Behalf Of John Kenney
Sent: Wednesday, June 10, 2020 4:07 PM
To: STDS-802-11-TGBD@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBD] NGV 20MHz M/O support

 

Hi Rui and All:

 

Rui, thanks for starting this discussion.

 

I commented on the 0.3 draft to make 20 MHz optional.  I was thinking particularly about the EU situation, which Friedbert has now confirmed.  That alone seems like a good reason for 20 MHz to be optional.

 

As the US spectrum situation is developing, DSRC/NGV may only have access to one 10 MHz channel (sadly).  Therefore, we might not be able to use the 20 MHz capability here either if the FCC proposal is formalized.  We may find more ITS spectrum in the future. The 4.9 GHz band has been mentioned.  But, that is speculative and far from likely.

 

If the FCC limits the ITS band to 30 MHz (5895-5925 MHz), there is also the possibility of DSRC/NGV operating as unlicensed in the U-NII-4 band, or in other U-NII bands, for less critical services. This has not been discussed much.  I can think of at least two paradigms for that:

A) DSRC/NGV continues to use 10 MHz as the base channel width.  In this case the 20 MHz NGV capability could be used as well.  This would be attractive for existing DSRC implementations, e.g. New York and Tampa pilot sites and other large deployments. But, it's not clear if they will want to given the lack of interference protection.  Under this paradigm, 10 MHz DSRC, 10 MHz NGV, and 20 MHz NGV would coexist well with each other, but not with 20/40/80/160 MHz Wi-Fi should such devices be deployed in proximity.

B) DSRC/NGV moves to a 20 MHz base channel width in the 5850-5895 MHz U-NII-4 band.  DSRC already has a 20 MHz version, which chip sets support but is not deployed (to my knowledge).  20 MHz DSRC would coexist well with 20/40/80/160 MHz Wi-Fi due to a common legacy preamble.  Note that the 20 MHz version of NGV we are developing would not coexist well with 20/40/80/160 MHz Wi-Fi, because it uses two 10 MHz premables instead of a 20 MHz preamble. If this paradigm is attractive, TGbd should consider specifying a second 20 MHz format, using a 20 MHz preamble that would coexist with 20 MHz DSRC and 20/40/80/160 MHz Wi-Fi, and that would incorporate PHY/MAC enhancements compared to DSRC.  I believe Onn Haran has previously mentioned this possibility. It is important to realize that this second 20 MHz format would not be intended to coexist with the first 20 MHz format or with 10 MHz DSRC/NGV.  It would be more straight forward, I expect, than the first 20 MHz format.

 

Best Regards,

John

 

 

On Wed, Jun 10, 2020 at 12:12 PM Dick Roy <dickroy@xxxxxxxxxxxx> wrote:

I assume you meant 5925 and 5935MHz below …not 5825 and 5835.

 

RR

 


From: ** STDS-802-11-TGbd -- Enhancements for Next Generation V2X.Task Group ** [mailto:STDS-802-11-TGBD@xxxxxxxxxxxxxxxxx] On Behalf Of Friedbert Berens
Sent: Wednesday, June 10, 2020 3:03 AM
To: STDS-802-11-TGBD@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGBD] NGV 20MHz M/O support

 

Dear All,

 

from the European point of view we actually only use 10MHz channels and only this option is allowed based on the ITS regulation in the band between 5855MHz to 5825 MHz (5835MHz for Urban Rail)).

 

In ETSI a multichannel concept is being developed and here actually only 10MHz channels are considered. 

 

Thus, I would strongly recommend to keep the 20MHz bandwidth optional.

 

Friedbert

 

Am 09.06.2020 um 23:24 schrieb Rui Cao <rui.cao_2@xxxxxxx>:

 

HI All,

During today’s call, we discussed about the mandatory and optional support of NGV 20MHz PPDU and operation.

I checked our meeting motion record, and there is no specific discussion to make 20MHz mandatory. I create this email thread for discussions on this topic.

According to some discussions in today’s meeting, there are good reasons to make 20Mhz PPDU/operation optional. E.g. different countries/regions may have different available spectrum and service planning for C2C communications. We are ok to leave 20MHz PPDU/operation optional for 11bd, and let different countries/regions to make the choice.

Thank you,

Rui

size=3 width="100%" align=center style='caret-color: rgb(0, 0, 0); font-variant-caps: normal;text-align:start;-webkit-text-stroke-width: 0px; word-spacing:0px'>

To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1

 


To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1


To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1


 

--

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


To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1


To unsubscribe from the STDS-802-11-TGBD list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11-TGBD&A=1