Re: [ipwave] ITU-R liaison statement 1686

Russ Housley <housley@vigilsec.com> Fri, 23 October 2020 16:39 UTC

Return-Path: <housley@vigilsec.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 769693A0EDF for <its@ietfa.amsl.com>; Fri, 23 Oct 2020 09:39:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 F2hMDZVz8VDh for <its@ietfa.amsl.com>; Fri, 23 Oct 2020 09:39:30 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF523A0ED9 for <its@ietf.org>; Fri, 23 Oct 2020 09:39:30 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 73C8C300B7E for <its@ietf.org>; Fri, 23 Oct 2020 12:39:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id L24FhxWe587I for <its@ietf.org>; Fri, 23 Oct 2020 12:39:24 -0400 (EDT)
Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 583B5300A3B; Fri, 23 Oct 2020 12:39:24 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <ab59a476-73d0-3ab1-771b-441b950f5beb@gmail.com>
Date: Fri, 23 Oct 2020 12:39:25 -0400
Cc: its@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <22311BFA-3AAD-4821-A0A4-DE3B0BEA5627@vigilsec.com>
References: <4725B596-F5FA-49F9-A312-BC40CD053F23@kuehlewind.net> <9af15ae85892d25b98fc6dda98a8851c@vigilsec.com> <CAPK2DexczsruB-PwP0VXk6eS89F1ZQitOEJEASB1hAraQJR8cw@mail.gmail.com> <eb8f818c-a246-099f-8de3-567bcbbc023e@gmail.com> <1c00cc5f-3b7e-ae37-6f2f-1c28f0c2d3a4@gmail.com> <0fcd17f5b58ea9249bfb97acd9894ffe@vigilsec.com> <bf630134-5830-d175-efbc-3dc330e7bc50@gmail.com> <ACC30712-CBA5-43B4-BF87-2B762894D1B5@vigilsec.com> <6ab7d79a-25af-f8ae-280b-c66d88f87a38@gmail.com> <ab59a476-73d0-3ab1-771b-441b950f5beb@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3445.104.17)
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/UjWbzBd8gzOEeOs_YWesp2mC0v8>
Subject: Re: [ipwave] ITU-R liaison statement 1686
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: Fri, 23 Oct 2020 16:39:32 -0000

Alex, you have certainly done your homework.  Thanks for putting in the effort.  That said, I am quite reluctant to speak to the ITU-R as the IETF IPWAVE WG with only two people offering a point of view.  More people need to speak up if we are going to make a formal response.

Russ


> On Oct 22, 2020, at 5:52 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> Hi, Russ,
> 
> I looked again at the liaison statement from ITU-R, and at the freely
> available documents it refers to.  I read again our discussions.
> 
> I do not know how to answer best to that statement: there is no procedure to reply to it, nor a form at some URL, and not sure about
> the individual/organization status.
> 
> However, I think the questions this liaison raises are very relevant.
> 
> Allow me to  respond to these questions here, until I can understand how and whether a more 'official' response is needed.
> 
> I would like to know what other participants in this group think?
> 
> From document R-QUE-SG05.261-2019-MSW-E.doc:
>> 1     What is the definition of connected automated vehicle (CAV) in the context of ITS?
> 
> I think the I-D 'Vehicular Networking', the Charter and RFC 8691 do not
> define the term CAV.  The Charter does mention 'connected automated
> driving'.
> 
>> 2	What are the radiocommunication elements for CAVs?
> 
> A CAV embarks an Internet Protocol On-Board Unit (IP-OBU.)  Along the
> road there might be IP-RSUs deployed.  The IP-OBU and IP-RSU use
> communication interfaces.  These communication interfaces are at 5.9GHz
> and potentially other frequency bands at PHY layer.  At networking layer
> these communication interfaces use IP, as specified in RFC 8691.
> 
>> 3	What are the overall objectives and requirements for CAVs, including: –	service requirements: service type, service concept, grade of service;
> 
> There are numerous services for CAVs that are implemented using IP.  For
> example, in platooning the steering service is used on IP between two CAVs.
> 
>> –	radiocommunication requirements: sensors, radio interfaces, data rate, latency, reliability;
> 
> Data rate of IP packets on 802.11bgn OCB mode is around 16mbit/s.  The
> latency is between 0.9ms and 5ms.  On 802.11ac OCB mode (probably
> 802.11bd) the data rate might be 1Gbit/s and latency 500microseconds.
> 
>> –	improvement factors: safety, control, energy savings, traffic management, congestion control?
> 
>> 4	Which radiocommunication systems have the capabilities to support CAV requirements?
> 
> 802.11-OCB (OCB mode for 802.11bgn and for 802.11ac).
> 4G, 4G+, and 5G.
> 
>> 5	What CAV functions might benefit from spectrum harmonization?
> 
> All CAV functions that use IP might benefit from harmonization at all
> layers.  At app layer, CAM messages might benefit from harmonization
> with BSM messages to benefit inter-continental markets (a single
> software stack).  Further, at networking layer these CAM or BSM messages
> might benefit from being transmitted over IP (instead of being
> transmitted without networking header when on 5.9GHz and with IP when on
> 5G).  Finally, on spectrum, the transmission of all V2X-specific
> messages - on IP - in only a few (ideally just one) frequency band will
> benefit interoperability.
> 
>> 6	What are the spectrum requirements for CAV radiocommunication including: –	suitable bands;
> 
> Currently most CAVs radiocommunication used for key CAV-specific
> operation are at 5.9GHz and some are at 2.6GHz (4G) and some at 3.6GHz
> (5G).  However, many CAVs depend also very tightly on localization
> involving GNSS systems; the reception of GNSS is around 1.2GHz including
> GPS, Galileo and others.
> 
> Many CAV-related communication systems involve also IP on WiFi at
> 2.4GHz, at 5.4GHz and potentially others.
>> –	spectrum bandwidth needed?
> 
> width of the band?  (like 10MHz?)
> or bandwidth ? (like 10Mbit/s ?)
> 
> It depends.  Essentially, a CAV might function with a bandwidth
> requirement very low (3G-class bandwidth of 300kbit/s) - just attach a
> comma.AI-powered smartphone on the dashboard and plug it on the car's
> CAN.   Other scenarios might need higher bandwidth requirements
> between cars: use IP to stream lidar data between vehicles in a platoon,
> or to stream video for 'see-thru'.  That bandwidth requirement is about
> 1Gbit/s.
> 
> From the document R19-WP5A-C-0085!N16!MSW-E.doc:
>> •	Vehicles Platooning - enables the vehicles to dynamically form a group travelling together
> 
> Please note the the Internet Draft of IPWAVE WG titled "Vehicular
> Networking" also defines platooning, in its section 3.1.
> 
> 
>> Spectrum other than that previously recommended for ITS may be desirable for CAV communications. For example, it may be possible that platooning and/or other very close range cooperative
>> maneuvering communications could best be effectively supported in EHF
>> (30-300 GHz) bands. Laboratory experimentation and field test
>> results becoming available during this ITU-R study period are likely
>> to identify suitable frequency bands, if any, for these types of communication, which could be specifically used for CAV use cases.
> 
> For my part, the experimentations of platooning that I am aware of run
> on IP at 5.9GHz.
> 
> In order to consider platooning with IP at other frequency bands
> (30-300GHz) there is a need for such devices to appear cheaply on the
> market, and a need for the 5.9GHz to exhibit overcrowdedness, a need for
> codecs to reach limits in providing the necessary bandwidth.
> 
> Personally, I am not aware of cheap interfaces in a band somewhere
> between 30GHz and 300GHz, but I wonder whether they exist.
> 
> The overcrowdedness at 5.9GHz: currently I think too few 5.9GHz
> deployments exist to consider them overcrowded.  There are much less
> 5.9GHz IP-RSUs than there are 2.4GHz Access Points for WiFi, for examle.
> 
> The bandwidth requirements: currently bands of 10MHz width in the 5.9GHz
> range could be grouped together (maybe into 20MHz or 40MHz bands) such
> that the codecs achieve bandwidths of aprroximately 10Gbit/s, in theory.
> If that is not possible because the bands are already reserved for
> particular uses, then it would be good to find a new space for such
> bands beyond 5.9GHz.  I wonder whether there could be some place found
> for this somewhere between 5.9GHz and 30GHz.
> 
> Finally, in addition to platooning, I would like to mention a relevant
> CAV use case that will  almost certainly need IP and IPv6 in particular.
> The TOD (tele-operated driving, a definition by 5GAA) is a low latency
> guaranteed delivery use-case where a vehicle is controlled by an
> operator in a control center, or by law enforcement or by the car owner
> ('call my car').  The controller sends commands to the car and receives
> video on a feedback.  In this use-case it is necessary to be able to
> discover, identify and reach the car in a scalable manner; the large
> IPv6 address space can ensure that is possible  (with IPv4 is not possible).
> 
> Alex
> 
> 
> 
> Le 21/10/2020 à 21:55, Alexandre Petrescu a écrit :
>> Hi, Russ,
>> Indeed the scope I wrote might be well beyond the scope of the WG. I
>> just listed topics concerning me now.  But I will not be responding to ITU-R liaison, also because it seems to request material rather from organizations.
>> Alex
>> Le 21/10/2020 à 19:56, Russ Housley a écrit :
>>> Alex:
>>> This seems to be well beyond the scope of the IPWAVE WG.  Perhaps you should respond as an individual.
>>> Russ
>>>> On Oct 20, 2020, at 8:22 AM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
>>>> Le 17/10/2020 à 17:17, housley@vigilsec.com a écrit :
>>>>> Since it is from ITU-R, it is about spectrum.
>>>> Well, the liaison statement asks this: "Working Party 5A kindly requests the interested external organizations to provide material on the description, architecture, applications, technologies, and operational scenarios of CAVs and the radiocommunication requirements for CAVs."
>>>> This is a very broad request.  I think it is much more than just spectrum requirements for CAVs.  I think only their request of 'radiocommunication requirements for CAVs' might indeed relate
>>>> to spectrum requirements.
>>>> With respect to 'radiocommunication requirements for CAVs' we could list the following: - the use of the 5.9GHz band specific to DSRC as used in automated vehicles.  Use IP on the control channel of this band. - the use of 3.5GHz band specific to 5G as used in demonstrations of tele-operation of automated shuttle, such as the October Stockholm demonstration made by Ericsson.
>>>> With respect to 'description, architecture, applications, technologies and operation scenarios' we could provide a pointer
>>>> to the Internet Draft titled 'IPv6 Wireless Access in Vehicular
>>>> Environments (IPWAVE): Problem Statement and Use Cases'.
>>>> With respect to just the 'operational scenarios' we can provide
>>>> a few additional pointers to CAV-specific use-cases of communication technologies: - the 6G use-cases relating to vehicular networking (some such use cases are listed in the 6gip email list of IETF), - the ITU-T FG-NET2030 use-cases that
>>>> relate to automated driving, - the recent ToD (Tele Operated
>>>> Driving) use-case described by 5GAA.
>>>> An additional possibility might be to provide a list of projects involving the use of communication systems in CAVs (Connected Automated Vehicles).
>>>> Alex
>>>>> Russ On 2020-10-17 04:37, Alexandre Petrescu wrote:
>>>>>> (For information, the ISO TC204 'ITS' too is looking at creating, or enhancing, an 'ADCG' - Automated Driving
>>>>>> Control Group.  It is a group trying to oversee how to bring
>>>>>> the different characteristics of work related to AD into the various WGs of that TC.  They have started a document titled 'Terms of Reference' on which they might need feedback. This
>>>>>> is not a liaison statement from ISO TC204, just a FYI.) Alex
>>>>>> Le 17/10/2020 à 10:31, Alexandre Petrescu a écrit :
>>>>>>> I think too it is a good idea to point to our I-D. But, since the ITU-R liaison is about CAV (Connected and Automated Vehicles), I think there would be advantageous to
>>>>>>> point to particular places in the draft that make for Connected and for Automated. For the Connected part it is straightforward, because many communication protocols are referred to in the I-D. For the Automated part, maybe the V2V use-cases described in the I-D. Maybe other parts of the I-D as well. Alex Le 17/10/2020 à 09:47, Mr. Jaehoon Paul Jeong a écrit :
>>>>>>>> Hi Russ, We can point out our IPWAVE Problem Statement and Use Cases Draft can be a good foundation for their work: https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-19
>>>>>>>> 
>> <https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-19>
>>>>>> 
>> 
> Thanks.
>>>>>>>> Best Regards, Paul On Sat, Oct 17, 2020 at 4:05 AM <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote: The ITU-R sent a liaison: https://datatracker.ietf.org/liaison/1686/ <https://datatracker.ietf.org/liaison/1686/> Does anyone think that the IPWAVE WG should reply? Russ _______________________________________________ its mailing list its@ietf.org <mailto:its@ietf.org> https://www.ietf.org/mailman/listinfo/its <https://www.ietf.org/mailman/listinfo/its> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.paul@gmail.com <mailto:jaehoon.paul@gmail.com>, pauljeong@skku.edu <mailto:pauljeong@skku.edu> Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php> _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its
>>>>>>> _______________________________________________ its
>>>>>>> mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its
>>>>>> _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its
>> _______________________________________________ its mailing list its@ietf.org https://www.ietf.org/mailman/listinfo/its
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its