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
- [ipwave] ITU-R liaison statement 1686 housley
- Re: [ipwave] ITU-R liaison statement 1686 Mr. Jaehoon Paul Jeong
- Re: [ipwave] ITU-R liaison statement 1686 Alexandre Petrescu
- Re: [ipwave] ITU-R liaison statement 1686 Alexandre Petrescu
- Re: [ipwave] ITU-R liaison statement 1686 housley
- Re: [ipwave] ITU-R liaison statement 1686 Alexandre Petrescu
- Re: [ipwave] ITU-R liaison statement 1686 Russ Housley
- Re: [ipwave] ITU-R liaison statement 1686 Alexandre Petrescu
- Re: [ipwave] ITU-R liaison statement 1686 Alexandre Petrescu
- Re: [ipwave] ITU-R liaison statement 1686 Mr. Jaehoon Paul Jeong
- Re: [ipwave] ITU-R liaison statement 1686 Russ Housley
- Re: [ipwave] ITU-R liaison statement 1686 Abdussalam Baryun