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

Re: [STDS-802-11] Fwd: [STDS-802-11] FCC 5.9 GHz NPRM: updated comments

--- This message came from the IEEE 802.11 Working Group Reflector ---

thank you Sebastian,

Joseph has added these into rev08 and i did a little bit of formatting and just uploaded to Mentor.

basically some questions in section 4.1 and moved last paragraph in section 6 to make a new section 5.2.

with the goal to finish content updates by the end of today (wednesday), rev 08 was uploaded and will work on rev 09 in the ad hoc.

thanks

jay


From: Sebastian Schiessl <sebastian.schiessl9@xxxxxxxxx>
Date: Wed, Feb 19, 2020 at 6:12 AM
Subject: Re: [STDS-802-11] Fwd: [STDS-802-11] FCC 5.9 GHz NPRM: updated comments
To: <STDS-802-11@xxxxxxxxxxxxxxxxx>  :
--- This message came from the IEEE 802.11 Working Group Reflector ---
Dear all, 

I have some further comments on the new Rev. 7 of the document.

Section 4.1: On the sufficiency of 30 MHz of spectrum:
  • There is a missing unit: "100 vehicles" is not a density. Vehicle density should be XXX vehicles *per square-mile* or *per km^2*. US imperial units are probably best here.
  • These statements should probably backed up by a reference ASAP. I believe Dick has mentioned that he intends to add those. In particular, we must cite a study about the maximum vehicle density (under which assumptions does this hold?), and some more clarification about the statement that "DSRC technology already in the current generation of smart phones", because I don't think my phone supports .11p.
  • Even though I agree that saving lives should be the top priority and is certainly a priority for Congress, I don't think that we as engineers are entitled to state what the goals of Congress are, unless they were stated in some document that we cite. Removing at a minimum the last 7 words of this section does not weaken our technical statements. Instead, by sticking only to the technical arguments, we probably strengthen our position as neutral experts.
Section 6.1: 
  • The second paragraph of this section is just "hanging there", because it belonged to the section on Vehicle-to-Pedestrian (V2P) whose heading and first paragraph got somehow deleted in the editing process. The blue comments from Feb. 14 also refer to this deleted V2P section. 
  • I propose to delete this abandoned second paragraph in Sec. 6.1 and make a new V2P section, which is more closely related to paragraph 11 of the NPRM, and should thus become Section 5.2 (see below). I tried to address some of the comments made on Feb. 14th and also added a new reference. 
  • There was a comment that we should not mention/compare with C-V2X, but I disagree with that. We compare DSRC and C-V2X in Section 5.1, and we should point out the scenarios for which DSRC / 802.11p/bd is technically better than C-V2X to allow the FCC to make a fully informed decision. I also believe we can confidently say that adding a second modem will result in additional costs, without having to back that up.
Proposed new section 5.2 (this is based on Sec. 4.2 from Revisions 0-6)

On the suitability of C-V2X for Vehicle-to-Pedestrian Communications (V2P)

In its waiver request, the 5GAA stated that “C-V2X enables direct, peer-to-peer mode communications […] between vehicles and pedestrians, cyclists and other vulnerable persons (“V2P”) […]”. This statement is false: C-V2X would not “enable” V2P, but instead make V2P vastly more complex compared to existing DSRC technology. Mobile phones of cyclists or pedestrians are not compatible with the C-V2X PC5 sidelink interface for direct peer-to-peer communication with vehicles at 5.9 GHz. Despite strong similarities, the cellular 4G/5G interface and the C-V2X PC5 interface cannot be integrated into a single radio interface because most pedestrians would not be willing to sacrifice cellular data connectivity in order to receive V2P messages. In order to enable simultaneous cellular data connectivity and V2P connectivity, a second radio interface for C-V2X PC5 would be required, which will be very challenging to integrate due to cost, power and size constraints for each of the many components in modern smart phones.

On the contrary, DSRC enables V2P communications at significantly lower cost and complexity: Most mobile phones are now equipped with IEEE 802.11ac/ax WiFi modules. As DSRC is based on IEEE 802.11 protocols, the entire digital baseband processing could be performed on this existing hardware without significant changes. Furthermore, the analog radio frontends already support channels up to 5835 MHz and could be easily expanded up to 5925 MHz, which would already allow direct communication between vehicles and phones. Furthermore, prototype developments indicate that additional changes to the analog power amplifier designs could even allow high transmit powers of up to 760mW for IEEE 802.11p transmissions originating from mobile phones without reducing the power efficiency of WiFi transmissions [New Ref 20]. Therefore, the mobile phones of pedestrians and cyclists could be easily modified to directly communicate with vehicles based on DSRC technology, warning each other about their presence and possible collisions even at large distances. Moreover, DSRC-based V2P and regular WiFi can reside on the same radio interface, which can be switched to V2P mode when the user is on the road and to regular WiFi connectivity when the user is at home or at work. Thus, DSRC technology will in the future allow direct V2P communications using inexpensive mobile phones without the need for additional hardware. [Optional: We therefore believe that DSRC can provide V2P communications at very low cost, so that DSRC has the highest potential to protect the most vulnerable road users like children and elderly persons, who often cannot afford the most expensive smart phones.]

[New Ref 20] Choi, Pilsoon, et al. "A case for leveraging 802.11 p for direct phone-to-phone communications." Proc. 2014 Int. Symp. Low Power Electronics and Design. ACM/IEEE, 2014.

Best Wishes,
Sebastian

On Tue, 18 Feb 2020 at 21:47, Sebastian Schiessl <sebastian.schiessl9@xxxxxxxxx> wrote:
Hi Jay,

here is the download link for the 3GPP report TR 36.885: 

/Sebastian

On Tue, 18 Feb 2020 at 21:43, Jay Holcomb <jholcomb@xxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
hi Sebastion and John, 
i am adding 802.18 reflector also and thanks for the input.  i have typed it into what we will review today, with John's suggestion.  if you can find a link for your last reference, that would be great. 
thanks
jay
---------- Forwarded message ---------
From: John Kenney <jkenney@xxxxxxxxxxxxxxxxx>
Date: Tue, Feb 18, 2020 at 10:13 AM
Subject: Re: [STDS-802-11] FCC 5.9 GHz NPRM: updated comments
To: <STDS-802-11@xxxxxxxxxxxxxxxxx>


--- This message came from the IEEE 802.11 Working Group Reflector ---
Hi Sebastian,
Thanks for this.
I support the thrust of this.

I wonder if you would be open to the following edit?
In the second line of the appendix text, replace
for time synchronization when accessing the channel   
with
to meet strict time synchronization requirements when accessing the channel   

Best Regards,
John


On Tue, Feb 18, 2020 at 9:06 AM Sebastian Schiessl <sebastian.schiessl9@xxxxxxxxx> wrote:
--- This message came from the IEEE 802.11 Working Group Reflector ---
Dear all,

I propose to modify section 7.4 in the .18 document 18-20-0020 commenting on the NPRM. Summary of changes (full modified text is given at the end):
  • C-V2X PC5 does not technically "require" GNSS time synchronization in the sense that it would stop working entirely without GNSS. Therefore, this should be changed to "C-V2X *uses* GNSS", and changed "requirement for GNSS" to "demand for GNSS". This statement can still be supported by Ref. [14], but this reference is optional.
  • However, the studies in support of C-V2X assume that ideal time synchronization is provided through GNSS. I've now cited two of those (3GPP TR 36.885, as well as the 5GAA Waiver Request). The whole argument therefore remains essentially the same: It's *possible* (I have not seen any studies to prove otherwise) that the lack of GNSS reception in tunnels could severely impair C-V2X performance. I added the sentence "The 3GPP or 5GAA have not provided any studies to address such concerns".
  • I also added that DSRC does not require a "central coordination entity" in support of DSRC. 
Best Wishes,
Sebastian Schiessl (u-blox)

Appendix:
Full Text Section 7.4 plus new references

Contrary to DSRC protocols, which are able to manage the access to the wireless channel in a distributed manner without requiring a central coordination entity, the C-V2X PC5 sidelink generally uses GNSS (Global Navigation Satellite System) signals like GPS for time synchronization when accessing the channel [14]. The studies cited by the 5GAA Waiver Request [New Ref 15], as well as studies conducted by the 3GPP [New Ref 16], all assume that ideal time synchronization is provided by GNSS signals. Even though this demand for GNSS does not lead to any additional costs because V2X systems already require GNSS systems for positioning, GNSS signals cannot be received in deep tunnels, which could lead to a loss of time synchronization, which could in turn reduce the efficiency and reliability of C-V2X systems in tunnels. The 3GPP or 5GAA have not provided any studies to address such concerns.
However, it is paramount for any V2X technology to provide reliable communication of safety messages in tunnels. On several past occasions, fires that resulted from traffic collisions in tunnels have spread rapidly and led to catastrophic loss of life. DSRC systems do not require time synchronization on a microsecond level and are therefore not impaired by the lack of GNSS reception in tunnels.

We note here that the lack of GNSS reception will not entirely prevent positioning. The vehicle’s position inside the tunnel could still be estimated by combining dead-reckoning systems, RADAR, LIDAR, and camera data. We acknowledge that positioning could be further improved by installing additional road-side units, which would also provide the time synchronization that is necessary for C-V2X. Nevertheless, it remains unclear whether public authorities will have sufficient funds to install these units.

[New Ref 15] 5GAA Petition for Waiver, GN Docket No. 18-357,https://ecfsapi.fcc.gov/file/11212224101742/5GAA%20Petition%20for%20Waiver%20-%20Final%2011.21.2018.pdf
[New Ref 16] 3GPP, "TR 36.885: Study on LTE-based V2X Services; (Release 14), V14.0.0", June 2016

To unsubscribe from the STDS-802-11 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&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 list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-11&A=1



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

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



--

Regards,
Jay Holcomb
IEEE 802.18
Itron, Liberty Lake (Spokane), WA



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