Re: [ipwave] Commenting on the FCC plan

[Alexandre Petrescu <[e-mail]>]

here is the rest of the points that I would like to comment:

6. "In support of its waiver request, 5GAA submitted studies of using 
10- and 20-megahertz-wide channels for C-V2X that found that allowing 
operation on a single 20-megahertz channel will support the introduction
of services “that [will] enable many important safety applications, such 
as red light warnings, basic safety messages, emergency alerts, and 
others, to enhance traffic systems and operations.”"

My comment is the following: one would benefit from considering 
carefully the statements from 5GAA.  Depending how it is interpreted it 
might be advantageous or not.  For my part, I do think that some of the 
claims of 5GAA in some trials make confusions about cellular technology 
and DSRC technology.  I do think that there is at least one publicly 
demonstrated trial under the banner of 5GAA which uses DSRC but it 
claims cellular technology.

That said, with respect to the use of the term "C-V2X": it is not very 
clear throughout the FCC Notice whether C-V2X means the traditional 
traits of cellular technology that distinguishes it from WiFi (i.e. use 
cellular frequencies, use a SIM, specific codecs, mandatory base 
station, etc.) or otherwise it means some more generic "3GPP" 
technology.  The only place where C-V2X is defined more properly is 
when, on page 37, it refers to 3GPP Release 14.  There is no pointer to 
a particular 3GPP Rel 14 document.  This lets open the imagination to 
think that it might mean the WiFi aspects of 3GPP.  3GPP is known to 
spec things by stepping into WiFi domain very often, even though in 
practice there are no 3GPP deployments on WiFi - and that, since 3G 
onwards :-)  In this sense, it might be that 'C-V2X' already means 
something from WiFi, and why not C-V2X to mean 802.11-OCB and BSM messages?

This lack of precision in mentioning "C-V2X" is what adds a lot to the 
confusion - should one accept C-V2X in 5.9GHz bands?  Well yes, provided 
'C-V2X' means a WiFi issued by 3GPP by copy/pasting IEEE.  Well no, if 
'C-V2X' means a pure cellular interface with a SIM card or software, 
mandatory base station, cellular codecs and specific expensive specific 
IPR from well-known particular companies.

7. "With this Notice, we propose that ITS in this band continue to 
provide safety of life services. We seek comment on this proposal."

This is my comment, and backed by a colleague from IETF: on which 
channel should we run IPv6-over-OCB? (RFC 8691)

8. "C-V2X in the 5.905-5.925 GHz band. Specifically, we propose to 
authorize C-V2X operations in the upper 20 megahertz of the band 
(5.905-5.925 GHz). We seek specific and detailed comment on this 
proposal that can fully inform our decision."

This is my detailed comment: when one wants to authorize a particular 
technology on a particular band, then one would like to make sure that 
technology is fully specified and understood.  It is not the case now 
with 'C-V2X'.  It is a rather new term.  Is it only the V2X part of 
3GPP?  Is it the WiFi part of it?  Which spec is meant more precisely?

This is why, in return, I would like to comment and request to publicize 
what more precisely is it meant by C-V2X?

8. "We seek comment on the available technical studies on C-V2X that 
should inform our consideration of C-V2X, including any recent studies
that provide information about how C-V2X would operate in the 5.9 GHz band."

Where are these technical studies?  Which ones?

9. "We first seek comment on whether to authorize C-V2X operations in 
the 5.895-5.905 GHz band."

My answer is no.  C-V2X is not specified, and it is a too wide term that 
might mean too many things.  If C-V2X means the WiFi part of 3GPP, and 
in particular 802.11-2016, in particular OCB mode, in particular BSM 
messages, then the answer is yes, definitely.  This would also allow RFC 
8691 IPv6 over 802.11-OCB to work.

10. "Commenters should provide detailed justification to support 
specific band plan options, including the types of services that could 
or could not be delivered by unlicensed use or by vehicularrelated
services under each option."

The type of the service that I need is the following: forming of convoy 
of 3 self-driving cars - they use IPv6 over 802.11-OCB on 3 distinct 
5.9GHz channels in order to minimize interference.   This could not be 
delivered if only one channel was available for RFC 8691 
IPv6-over-802.11-OCB.  The demo is filmed and publicly available on the web.

11. "(a) DSRCS Roadside Units (RSUs) operating in the 5895-5905 MHz band 
must comply with the technical standard Institute of Electrical and 
Electronics Engineers (IEEE) 802.11p-2010."

This forgets that 802.11p is an old name and no longer in use.  The 
users of this name neglect that IEEE 802.11-2016 is the current spec, 
and which covers old 802.11p behaviour with an 'OCB' mode (Outside the 
Context of a BSSID).  That is the standard that should be referred to by 
this FCC Notice and not 802.11p.

Additionally, I suggest to add the keyword 'IPv6'.  I suggest to add a 
reference to RFC 8691 titled "Basic Support for IPv6 Networks Operating 
Outside the Context of a Basic Service Set over IEEE Std 802.11" which 
is publicly available on the web.

End of comments.

Alex

Le 15/01/2020 à 16:48, Abdussalam Baryun a écrit :
> Thanks Alex,
> 
> I will review again and reply as soon as possible,
> 
> AB
> 
> On Wed, Jan 15, 2020 at 5:41 PM Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     For information and update.
> 
>     1. Deadline: We do not know whether or not today is a deadline.  The
>     FCC
>     notice (attached) says the deadline is "30 days after date of
>     publication in the Federal Register" but we do not have that date of
>     publication in the Federal Register.  For my part, I would like to keep
>     that day today January 15th, if possible.  But an interested person of
>     help is influenced by a very real-world event in a city in danger,
>     which
>     might delay his availability.
> 
>     The comment to submit at https://www.fcc.gov/ecfs/filings will be
>     structured around the following points:
> 
>     2. on what channel or frequency band to run IPv6-over-802.11OCB
>     specified in RFC8691?  It is not clear from the FCC Notice whether or
>     not in the future the implementations of RFC8691 are allowed to exist,
>     because of two difficulties:
>     2.1. in the past, it was often suggested by FCC and independent
>     commenters that IPv6 should not be put on the 'Control' channel.  The
>     Control channel is known to be 5885-5895MHz in America and 5895-5905MHz
>     in Europe.
>     2.1.1 Considering the American interpretation of the term 'Control
>     channel' (5885-5895MHz), and the future allocation of 5885-5895MHz to
>     WiFi, and considering that by that WiFi the FCC Notice assumes to be
>     "802.11 with BSSID" (as opposed to '802.11-OCB - Outside the Context of
>     a BSSID'), it is clear that RFC 8691 "IPv6 over OCB" can not be run on
>     the Control channel - even less in the future than in the past.
>     2.1.2 Considering the EU interpretation of the 'Control channel'
>     (5895-5905MHz): this channel would be allocated by FCC still to DSRC in
>     the future.  It would be the only channel in which DSRC is allowed. 
>     For
>     this channel, the FCC Notice at page 40 refers clearly to IEEE
>     802.11p-2010 (and not to 802.11-2016 which covers both OCB and
>     'with-BSSID').  Is RFC8691 IPv6-over-OCB allowed on the channel
>     5895-5905MHz?  (called 'Control channel' in Europe).
> 
>     3. with respect to this comment seek in the FCC Notice: "11. We propose
>     to create sub-bands within the 5.9 GHz band to allow unlicensed
>     operations to operate in the lower 45 megahertz of the band
>     (5.850-5.895
>     GHz) and reserve the upper 30 megahertz of the band (5.895-5.925 GHz)
>     for ITS. We seek comment on this proposal"
> 
>     This is my comment: you seem to need a 45 MHz band from the 5.9GHz
>     domain in order to stick close to another WiFi band such as to allow
>     the
>     codecs to do more bandwidth.  An alternative is the following: find
>     another place for that 45MHz (not at 5.9GHz).  Invent a new
>     technique of
>     creating a wide band by virtually sticking two disparate bands from
>     largely different domains: take one 20MHz band from WiFi 5GHz and
>     another, e.g. 100MHz, from a 70GHz domain, for example.  The continuity
>     of band is an artificial requirement.  Just as artificial limits
>     existed
>     in the max file length on FAT16 at 2Gbyte (if I recollect correctly the
>     numbers).
> 
>     4. "we seek comment on the state of DSRC-based deployment".
>     This is my comment: there are very many RSUs installed in Europe and
>     very few people who use them.  There are many individual demonstrators
>     in cars.  There are no smartphones with DSRC capability.  There are
>     some
>     encouraging trials of IPv6-over-802.11-OCB RFC8691 including RSUs,
>     platoons and in laboratory.
> 
>     5. "We seek comment on the transportation and vehicular-safety related
>     applications that are particularly suited for the 5.9 GHz band as
>     compared to other spectrum bands, and how various bands can be used
>     efficiently and effectively to provide these applications."
>     This is my comment: 5.9GHz is more straight, or line-of-sight if you
>     wish, than 3.5GHz or 2.4GHz; this means on one hand that it has a
>     harder
>     time to get around the corners but, just because of that, it is better
>     suited for use with cheap simple reflectors.  Whether that is good or
>     not of applications: there are many layers between PHY and APP.  These
>     layers are what makes applications work ok on the right PHY.  It is not
>     the 5.9GHz that is better adapted or less well adapted to a particular
>     app (safety).  There are hugely safe apps that run on PHYs at very many
>     frequencies, from very low to very high.  One should avoid a situation
>     that risks the solution proposed in the notice to not be adapted,
>     and to
>     issue again the same problems later (i.e. use WiFi and C-V2X and still
>     not obtain safety; examples abound: cellular technologies are bringing
>     huge safety risks when applied like with Uber (sexism, wild parking,
>     drivers' rights), scooter accidents (reserved over cellular), double
>     Tesla accidents in just one last month, and more.
> 
>     more later.
> 
>     Alex
> 
> 
>     Le 08/01/2020 à 16:13, Alexandre Petrescu a écrit :
>      > For information and update,
>      >
>      > With Abdussalam we discussed in private:
>      > - potential implication of an ISOC representative in making a comment
>      > - the URL to file the comment is https://www.fcc.gov/ecfs/filings
>      > - the potential comment is
>      >    "what is the channel on which to use IPv6 (RFC8691 now)?"
>      >    Because the FCC Notice of Proposed Rulemaking does not contain the
>      >    word IPv6; and because often in the past FCC was not clear about
>      >    allowing IPv6 on the 'control' channel 5895-5905MHz; this is
>      >    potentially the only channel allowed for 802.11-OCB (aka DSRC)
>     in the
>      >    future - the rest of 5.9GHz channels would go to 802.11ax and to
>      >    C-V2X.
>      > - the deadline for filing comments is January 15th (30 days from Dec.
>      >    17th).
>      >
>      > I am looking for interest in this.
>      >
>      > Alex
>      >
>      > Le 20/12/2019 à 13:04, Alexandre Petrescu a écrit :
>      >> Hi, IPWAVErs,
>      >>
>      >> I am interested in commenting on the FCC plan for 5.9GHz band, in
>      >> particular with respect to the channel(s) on which to use
>      >> IPv6-over-802.11-OCB.
>      >>
>      >> There seems to be a window of opportunity of 30 days from
>     publishing
>      >> date of Dec. 17th.
>      >>
>      >> Is anybody planning to comment?  Is someone part of a group that
>     would
>      >> like to comment?
>      >>
>      >> (attached the FCC notice)
>      >>
>      >> Alex
>      >>
>      >> Le 18/12/2019 à 11:06, Alexandre Petrescu a écrit :
>      >>>
>      >>>
>      >>> Le 17/12/2019 à 16:23, Jérôme Härri a écrit :
>      >>>> Dear All,
>      >>>>
>      >>>> Sorry, wrong link..it was a presentation..
>      >>>>
>      >>>> But here is the paper:
>      >>>>
>      >>>>
>     http://www.eurecom.fr/fr/publication/5191/detail/can-ieee-802-11p-and-wi-fi-coexist-in-the-5-9ghz-its-band
> 
>      >>>>
>      >>>
>      >>> Jérôme,
>      >>>
>      >>> Thanks for the pointer to that article of 2017.  Its
>     introductory parts
>      >>> are no short of predicting what is happening now with the FCC
>     plan in
>      >>> the 5850-5895MHz band for WiFi and OCB.
>      >>>
>      >>> The paper seems to suggest a WiFi-OCB co-existence solution
>     backed by
>      >>> cognitive radio concept and simulation.
>      >>>
>      >>> Are there implementations of the WiFi-OCB co-existence in the
>     same band?
>      >>>
>      >>> Is there a demonstrator showing that WiFi with BSS and WiFi in
>     OCB mode
>      >>> can live together ok in same band?  A packet dump would be
>     illustrative.
>      >>>
>      >>> The IPv6-over-OCB draft makes a MUST to use QoS Data headers. 
>     Would
>      >>> IPv6-over-WiFi-with-BSS also be a MUST to use such headers?
>      >>>
>      >>> Alex
>      >>>
>      >>>>
>      >>>> BR,
>      >>>>
>      >>>> Jérôme
>      >>>>
>      >>>> -----Original Message----- From: Jérôme Härri
>     <[e-mail] <mailto:[e-mail]>>
>      >>>> Sent: Tuesday, 17 December 2019 16:09 To: 'Alexandre Petrescu'
>      >>>> <[e-mail]
>     <mailto:[e-mail]>>; 'Abdussalam Baryun'
>      >>>> <[e-mail]
>     <mailto:[e-mail]>> Cc: 'its' <[e-mail]
>     <mailto:[e-mail]>> Subject: RE:
>      >>>> [ipwave] FCC Moves Plan Forward to Chop Up Vehicle Safety Airwaves
>      >>>>
>      >>>> Dear All,
>      >>>>
>      >>>> We did a study a few months ago related to the coexistence between
>      >>>> WiFi and OCB on the same channel. Please find it here:
>      >>>>
>      >>>>
>     http://www.eurecom.fr/fr/publication/5395/detail/coexistence-challenges-between-rlans-and-etsi-its-g5-at-5-9ghz-for-future-connected-vehicles
> 
>      >>>>
>      >>>>
>      >>>>  John Kenney and his team also make a similar study as well...
>      >>>>
>      >>>> The methods have slightly changed since this publication, but
>      >>>> problems would still occur: which technology should 'vacate'
>     in case
>      >>>> of interferences? As far as I understood, OCB still is the
>      >>>> primary..but I leave other expert to correct this statement if
>     I am
>      >>>> wrong,
>      >>>>
>      >>>> BR,
>      >>>>
>      >>>> Jérôme
>      >>>>
>      >>>> -----Original Message----- From: its <[e-mail]
>     <mailto:[e-mail]>> On Behalf
>      >>>> Of Alexandre Petrescu Sent: Tuesday, 17 December 2019 15:45 To:
>      >>>> Abdussalam Baryun <[e-mail]
>     <mailto:[e-mail]>> Cc: its
>      >>>> <[e-mail] <mailto:[e-mail]>> Subject: Re: [ipwave] FCC
>     Moves Plan Forward to Chop
>      >>>> Up Vehicle Safety Airwaves
>      >>>>
>      >>>>
>      >>>>
>      >>>> Le 17/12/2019 à 15:29, Abdussalam Baryun a écrit :
>      >>>>> I think IEEE defines WLAN as IEEE802.11. so any IEEE802.11xx
>      >>>>> standard can be called a WLAN standard.
>     http://www.ieee802.org/11/
>      >>>>
>      >>>> Right.
>      >>>>
>      >>>> And a channel in the 2.4GHz band (WLAN) can not be linked with a
>      >>>> channel in the 5.9GHz band (WLAN) because the former is ran with a
>      >>>> BSS whereas the latter is Outside the Context of a BSS (OCB).  As
>      >>>> such it is impossible to realize the FCC claim to provide cutting
>      >>>> edge high throughput bandwidth ("the Commission proposes to
>     designate
>      >>>> the lower 45 megahertz of the band for unlicensed uses like Wi-Fi.
>      >>>> This 45 megahertz sub-band can be combined with existing
>     unlicensed
>      >>>> spectrum to provide cutting-edge high-throughput broadband
>      >>>> applications on channels up to 160 megahertz wide.")
>      >>>>
>      >>>> So if FCC wants to run WiFi with a BSS in this 5875-5895MHz band,
>      >>>> such as to legitimately call it WiFi, and to achieve high
>     throughput,
>      >>>> then it can only be in mode with a BSS, and it can not be in mode
>      >>>> without a BSS (OCB).
>      >>>>
>      >>>>> also IEEE defines WMAN as IEEE802.16 technology, which was
>     replaced
>      >>>>> by LTE cellular technology.
>      >>>>
>      >>>> There is indeed a similarity.
>      >>>>
>      >>>> But 802.16 is more different than 802.11 than 802.11-OCB is
>     different
>      >>>> than 802.11.
>      >>>>
>      >>>> 802.16 runs in licensed and paid spectrum (one has to acquire i.e.
>      >>>> pay money to get) whereas 802.11-OCB one does not have to buy
>      >>>> spectrum.
>      >>>>
>      >>>> There are other stronger differences I think.
>      >>>>
>      >>>>>
>      >>>>> AB
>      >>>>>
>      >>>>> On Tue, Dec 17, 2019 at 3:54 PM Alexandre Petrescu
>      >>>>> <[e-mail]
>     <mailto:[e-mail]>
>      >>>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>> wrote:
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>> Le 17/12/2019 à 14:40, Abdussalam Baryun a écrit :
>      >>>>>> V2X and V2V communications had two design proposals:
>      >>>>>>
>      >>>>>> 1- using WLAN technology 2- using Cellular network technology
>      >>>>>>
>      >>>>>> So we worked on the first in this WG.
>      >>>>>
>      >>>>> OCB is not the typical WLAN - it is 802.11 in mode OCB.  One cant
>      >>>>> link OCB channels to non-OCB channels (typical WiFi) such as to
>      >>>>> make very large channel widhts they seem to need.
>      >>>>>
>      >>>>>
>      >>>>> in frequency yes
>      >>>>
>      >>>> In practice: how do you think it is possible to link together two
>      >>>> channels one from 5.4GHZ WiFi and one from 5.9GHz OCB?
>      >>>>
>      >>>> I think for my part of the 'iw' command.  That allows to link
>      >>>> together two channels, by specifying the channel width: 10MHz,
>     20MHz,
>      >>>> etc.  But they must be adjacent in the first places.
>      >>>>
>      >>>> And one cant do that linking to create a channel that is in
>     part OCB
>      >>>> and in part non-OCB.  Light can be wave and particle but
>     channel cant
>      >>>> be both OCB and with BSS.
>      >>>>
>      >>>>>
>      >>>>> I think FCC wants much parts of the 5.9GHz for WLAN (not OCB)
>     and
>      >>>>> other parts for C-V2X.
>      >>>>>
>      >>>>> FCC is pushing for 5G services/qualities to be achieved.
>      >>>>
>      >>>> It is a good goal that I share entirely.  But dont invade other
>      >>>> goals.
>      >>>>
>      >>>>> I think it may depend on locations/regions, because some
>     locations
>      >>>>> may not have good cellular communication signals.
>      >>>>
>      >>>> FCC does not talk about locations or regions.
>      >>>>
>      >>>> But I do agree with you on the principle.  I talked recently to a
>      >>>> highway operator complaining about the lack of 3G 4G
>     feasibility on
>      >>>> their roads.
>      >>>>>
>      >>>>>
>      >>>>> I think the FCC question is whether or not to keep the
>      >>>>> 5895-5905MHz for DSRC or to give that too to C-V2X; that is the
>      >>>>> only question they formulate.
>      >>>>>
>      >>>>>
>      >>>>> I agree, they are pushing for that,
>      >>>>>
>      >>>>>
>      >>>>> That channel is a place where FCC hardly allowed for IPv6 in the
>      >>>>> first place.  Even in this WG it was often said that IPv6 is not
>      >>>>> for that channel.
>      >>>>>
>      >>>>> I think there is no place for OCB mode anywhere and even less
>     for
>      >>>>> IPv6.
>      >>>>>
>      >>>>>
>      >>>>> we never know what will happen tomorrow.
>      >>>>
>      >>>> BUt we cant work without a solid basis.
>      >>>>
>      >>>> Alex
>      >>>>
>      >>>>>
>      >>>>> AB
>      >>>>>
>      >>>>>
>      >>>>> Alex
>      >>>>>>
>      >>>>>> On Tue, Dec 17, 2019 at 12:58 PM Alexandre Petrescu
>      >>>>>> <[e-mail]
>     <mailto:[e-mail]>
>      >>>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>
>      >>>>> <mailto:[e-mail]
>     <mailto:[e-mail]>
>      >>>>> <mailto:[e-mail]
>     <mailto:[e-mail]>>>> wrote:
>      >>>>>>
>      >>>>>>> https://docs.fcc.gov/public/attachments/DOC-361339A1.pdf
>      >>>>>>
>      >>>>>>> For Immediate Release FCC SEEKS TO PROMOTE INNOVATION IN
>      >>>>> THE 5.9 GHZ
>      >>>>>>> BAND WASHINGTON, December 12, 2019—The Federal Communications
>      >>>>>>> Commission today voted[...]
>      >>>>>>
>      >>>>>> What does C in C-V2X mean?  Is it Cellular V2X like in 3GPP?
>      >>>>> I assume
>      >>>>>> this is what is meant by C-V2X: point-to-point links from 3GPP.
>      >>>>>>
>      >>>>>> Yes, there are 4G and 5G
>      >>>>>>
>      >>>>>> Or is C-V2X something more like BSM messages put on 802.11
>      >>>>> kind of link
>      >>>>>> (be it OCB or more traditional WiFi)?
>      >>>>>>
>      >>>>>>
>      >>>>>> no it is cellular network communication  technologies/protocols
>      >>>>>>
>      >>>>>>
>      >>>>>> What does C-V2X mean entirely?  Is it sending BSM messages or
>      >>>>> is it also
>      >>>>>> sending CAM messages (in 3GPP there are only CAM messages
>      >>>>> AFAIremember).
>      >>>>>>
>      >>>>>> What are the implementations of C-V2X  and on which hardware
>      >>>>> from which
>      >>>>>> manufacturer?
>      >>>>>>
>      >>>>>>
>      >>>>>> see our draft mentions c-v2x:
>      >>>>>>
>      >>>>>>
>      >>>>>
>     https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-03#
>      >>>>>
>      >>>>>
>      >>> page-19
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>
>      >>>>>> I think it is important that we do more work for the C-V2X
>      >>>>> section in
>      >>>>>> the draft as well.
>      >>>>>>
>      >>>>>>
>      >>>>>> Detailing this term is key to understand the plan and to be
>      >>>>> able to
>      >>>>>> answer the consultation.  It might be very worrisome as well
>      >>>>> as it might
>      >>>>>> be nothing new but a change in terms.
>      >>>>>>
>      >>>>>>
>      >>>>>> The C-V2X is challenging with WiFi V2X, it depends on what is
>      >>>>>> mostly used by countries, but the WiFi is probably will win.
>      >>>>>>
>      >>>>>> AB
>      >>>>>>
>      >>>>>>
>      >>>>>
>      >>>>
>      >>>> _______________________________________________ its mailing list
>      >>>> [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/its
>      >>>>
>      >>>
>      >>> _______________________________________________
>      >>> its mailing list
>      >>> [e-mail] <mailto:[e-mail]>
>      >>> https://www.ietf.org/mailman/listinfo/its
>      >>
>      >> _______________________________________________
>      >> its mailing list
>      >> [e-mail] <mailto:[e-mail]>
>      >> https://www.ietf.org/mailman/listinfo/its
>      >>
>      >
>      > _______________________________________________
>      > its mailing list
>      > [e-mail] <mailto:[e-mail]>
>      > https://www.ietf.org/mailman/listinfo/its
>     _______________________________________________
>     its mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/its
>