Re: [ipwave] Commenting on the FCC plan

Alexandre Petrescu <> Wed, 15 January 2020 20:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7E5F120975 for <>; Wed, 15 Jan 2020 12:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Status: No, score=-2.622 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, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CG73U5SjllYG for <>; Wed, 15 Jan 2020 12:34:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B5A6120935 for <>; Wed, 15 Jan 2020 12:34:36 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 00FKYY2c039102 for <>; Wed, 15 Jan 2020 21:34:34 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id 50CCA201B72 for <>; Wed, 15 Jan 2020 21:34:34 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 343E6201694 for <>; Wed, 15 Jan 2020 21:34:34 +0100 (CET)
Received: from [] ([]) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 00FKYMn0018648 for <>; Wed, 15 Jan 2020 21:34:22 +0100
References: <> <> <> <> <> <> <00d601d5b4ee$01cc9ae0$0565d0a0$> <> <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
Date: Wed, 15 Jan 2020 21:34:22 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------88A107AA39819A6C7016481D"
Content-Language: fr
Archived-At: <>
Subject: Re: [ipwave] Commenting on the FCC plan
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jan 2020 20:34:41 -0000

I submitted the comments that are shown in the attached file.

It is possible to submit more comments, maybe with more help from 
interested parties, or to clarify other things.  It's the same URL


Le 15/01/2020 à 21:11, Alexandre Petrescu a écrit :
> 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.