Re: [ipwave] FCC Moves Plan Forward to Chop Up Vehicle Safety Airwaves

Alexandre Petrescu <alexandre.petrescu@gmail.com> Tue, 17 December 2019 14:45 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9606E12084F for <its@ietfa.amsl.com>; Tue, 17 Dec 2019 06:45:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.631
X-Spam-Level:
X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q3Aagf0hngF0 for <its@ietfa.amsl.com>; Tue, 17 Dec 2019 06:45:21 -0800 (PST)
Received: from sainfoin-smtp-out.extra.cea.fr (sainfoin-smtp-out.extra.cea.fr [132.167.192.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2A32120850 for <its@ietf.org>; Tue, 17 Dec 2019 06:45:20 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBHEjJuD036249; Tue, 17 Dec 2019 15:45:19 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 0F71E206838; Tue, 17 Dec 2019 15:45:19 +0100 (CET)
Received: from muguet2-smtp-out.intra.cea.fr (muguet2-smtp-out.intra.cea.fr [132.166.192.13]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 00B1F2067EC; Tue, 17 Dec 2019 15:45:19 +0100 (CET)
Received: from [10.11.240.20] ([10.11.240.20]) by muguet2-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id xBHEjIGZ020501; Tue, 17 Dec 2019 15:45:18 +0100
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: its <its@ietf.org>
References: <EED81985-1D4C-41B2-8CCA-A46B96390A18@vigilsec.com> <1c70cda6-050b-e018-6786-abd99281b6bb@gmail.com> <CADnDZ8-opM3O5U7-C8v+KYTX6-ruQzajRZgDWzzZtXRnJt575Q@mail.gmail.com> <ad3ccd6c-cd99-c47a-d0df-bfb94b5ab40f@gmail.com> <CADnDZ8_wwa91-5UWeqxhJy=nMBp8kwu4ZvfxsAojZCY9DG8jSA@mail.gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <92850021-914f-ab6a-f8d2-ab793179fa1b@gmail.com>
Date: Tue, 17 Dec 2019 15:45:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.3.0
MIME-Version: 1.0
In-Reply-To: <CADnDZ8_wwa91-5UWeqxhJy=nMBp8kwu4ZvfxsAojZCY9DG8jSA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/koxMah5DmNB6omN9dyfusOkX3ds>
Subject: Re: [ipwave] FCC Moves Plan Forward to Chop Up Vehicle Safety Airwaves
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2019 14:45:26 -0000


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 
> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
> 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 
>> <alexandre.petrescu@gmail.com
> <mailto:alexandre.petrescu@gmail.com> 
> <mailto:alexandre.petrescu@gmail.com 
> <mailto:alexandre.petrescu@gmail.com>>> 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
>> 
>> 
>