Re: [ipwave] Commenting on the FCC plan

[Alexandre Petrescu <[e-mail]>]

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]> 
>>>> Sent: Tuesday, 17 December 2019 16:09 To: 'Alexandre Petrescu'
>>>> <[e-mail]>; 'Abdussalam Baryun'
>>>> <[e-mail]> Cc: 'its' <[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]> On Behalf
>>>> Of Alexandre Petrescu Sent: Tuesday, 17 December 2019 15:45 To:
>>>> Abdussalam Baryun <[e-mail]> Cc: its
>>>> <[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]>> 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]>>> 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] https://www.ietf.org/mailman/listinfo/its
>>>>
>>>
>>> _______________________________________________
>>> its mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/its
>>
>> _______________________________________________
>> its mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/its
>>
> 
> _______________________________________________
> its mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/its