Re: [ipwave] mechanical layer and IPv6 in cars

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 27 March 2021 09:04 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 BB6163A2386 for <its@ietfa.amsl.com>; Sat, 27 Mar 2021 02:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Level:
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 yIlbKdOqF-LC for <its@ietfa.amsl.com>; Sat, 27 Mar 2021 02:03:56 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (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 F41DF3A2384 for <its@ietf.org>; Sat, 27 Mar 2021 02:03:55 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 12R93ome043533; Sat, 27 Mar 2021 10:03:50 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 07E3A20149A; Sat, 27 Mar 2021 10:03:50 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id EBFC6200CD8; Sat, 27 Mar 2021 10:03:49 +0100 (CET)
Received: from [10.14.0.12] ([10.14.0.12]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 12R93nJJ029571; Sat, 27 Mar 2021 10:03:49 +0100
To: dickroy@alum.mit.edu, "'Rex Buddenberg'" <buddenbergr@gmail.com>, its@ietf.org
References: <e1d2a31f-5587-cf05-da86-e38fc47adab5@gmail.com> <7799867a-7ce8-c38b-96f7-0ff03cb20bf0@gmail.com> <1613405277.18911.96.camel@gmail.com> <C9BE7A193494441CA49A08AB3EBAC498@SRA6>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <282f13a9-dc40-744a-cfcf-9453ed6fab80@gmail.com>
Date: Sat, 27 Mar 2021 10:03:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <C9BE7A193494441CA49A08AB3EBAC498@SRA6>
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/AgHs8ss6aY2MNkoXz0F5OhiZLp0>
Subject: Re: [ipwave] mechanical layer and IPv6 in cars
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: Sat, 27 Mar 2021 09:04:01 -0000


Le 16/02/2021 à 03:42, Dick Roy a écrit :
[...]
> I recommend a bicycle.  [...] and it doesn't break down every 10 
> miles.  Also, you can repair it yourself if you know which end of a 
> screwdriver to hold. :^)))

Connected self-riding bicycles :-)

Still though, this might relate to IPv6 in cars.

There is a development process for cars.  That process is particular in
many ways.  For example, it is different than mobile objects in space,
which are guided more by the NASA's TRL levels.

Often times people are asked to put IPv6 in cars with prototype computer
and network interfaces.  To do that, the very initial steps are to start
working on a desk or on the laps with a computer and USB OCB or 4G
interfaces.  A Raspberry Pi, a laptop and an USB dongle are very common
first steps.

When that works with IPv6 and Internet it's so great that the temptation
is to immediately put that in one's car.  And it works there too.

But the development process is not finished.

Going to more 'show cars', or 'concept cars', or 'prototype cars', one
hits more and more mechanical constraints.  That initial
laptop+raspberry+usb must become tamper-proof so people dont steal it,
shockproof so it absorbs shocks on the road, waterproof so no need of a
tent around a static car under the rain, even fireproof in case there is
fire in the car.  One might need gloves too.

For each of these *-proof requirements, there are some times software or
other brain-controlled organizational ideas.  For example one might use
software MAC layers in a stack to retransmit and accommodate for
intermittent mechanical disconnnections and make the IP layer think it's
all fine.  Organizationally,  one might put the box in the car far from
the engine, maybe in the trunk.

But other times a screwdriver is needed.  A USB dongle implementing OCB
mode or 4G with IPv6 should not be used in a car, because USB mechanical
interface does not feature screws.  There are some exceptions with
plastic screwing, but only on one end of an USB cable.  Rather, in a
more advanced IPv6-over-OCB-or-4G prototype one should use miniPCI kind
of board (PCB - printed circuit board) network interfaces because that
has screws and can be safely attached, thus sollicitting less the MAC
retransmissions.

A screwdriver is needed then :-)

As a side note: I also agree with you about the parts  where I ellided
text in the text you wrote: I think it is necessary that the addition of
IPv6 support in the car needs to be as less intrusive mehcanically as
possible.  This is to not defigurate the car appearance.  It should be
as less energy-consuming as possible, and at the least cost possible.

Alex

> 
> 
> 
> -----Original Message----- From: its [mailto:its-bounces@ietf.org]
> On Behalf Of Rex Buddenberg Sent: Monday, February 15, 2021 8:08 AM
> To: Alexandre Petrescu; its@ietf.org Subject: Re: [ipwave] Risks for
> the future of OCB mode at 5.9GHz
> 
> The cellphone in my pocket (and probably yours) have both LTE and 
> WiFi interfaces.
> 
> 
> On Mon, 2021-02-15 at 12:37 +0100, Alexandre Petrescu wrote:
>> A colleague pointed me to a video presentation of the problem of 
>> ITS- G5 vs C-V2X of January 21, 2021.  The presentation is brief. 
>> It describes this DSRC-vs-5G to be a problem because there are two 
>> standards, too complex for deployers, and there is uncertainty for 
>> vehicle users.  IMHO this uncertainty means : should I buy a Ford 
>> (C-V2X) or a VW (ITS- G5). The presenter gives his oppinion: 
>> probably C-V2X will win.
>> 
>> Starting at around 21:02 (21min, 2 seconds) and lasts for about 2 
>> minutes:
>> 
>> https://www.real-wireless.com/predicting-2021-trends-connectivity-ins
>>
>>
>>
>>
>>
>>
>> 
ight-from-real-wireless/
>> 
>> It is interesting to note how he compares the problem to the VHS vs
>> Betacam (presumably 5G is more of VHS, and ITS-G5/DSRC more of 
>> Betacam). Certainly, in around 1995 one would no longer work on 
>> anything Betacam. But they were both overcome by DVD and Bluray 
>> later, and now by 8K.
>> 
>> Also, the notion of direct communications in cellular systems (w/o
>>  base station) existed long before 5G's PC5: 3G tried it too but
>> it did not work.  On another hand, in 3G there were no chips doing
>>  direct comm, no spectrum, but in 5G there are.
>> 
>> All in all, I am not sure how will this unfold.
>> 
>> Possibly one way forward is to consider IP: IP-over-PC5, and 
>> CAM-over-IP.
>> 
>> With IP tools at hand, the deployer would abstract from the 
>> DSRC-vs- PC5 problem.
>> 
>> What do you think is a possible way forward in the DSRC-vs-PC5 
>> problem?
>> 
>> Alex
>> 
>> 
>> Le 12/02/2021 à 11:51, Alexandre Petrescu a écrit :
>>> 
>>> I take advantage of a private message I received, in order to 
>>> explain this in English, and to the public email list.
>>> 
>>> I have some doubts about the future of OCB mode of WiFi.
>>> 
>>> The recent re-allocation of spectrum by FCC in USA divides the 
>>> space typically used for OCB mode of 802.11 into a space for 
>>> C-V2X (a different mode than 802.11) and a space for WiFi.
>>> 
>>> The C-V2X already ate the OCB mode at cca 5.8-5.9GHz, by 
>>> allocation. The WiFi is highly likely to eat the OCB mode at cca 
>>> 5.4-5.8GHz. The reason of this is that WiFi is always and will 
>>> always be looking at increasing the bandwidth; that increase can 
>>> be achieved by widening the bands.  This is what WiFi 6E does 
>>> when claiming to offer 4Gbit/s at 6GHz ('6' is a coincidence).
>>> 
>>> In the past, what FCC did in USA at 5.9GHz was simply replicated
>>>  in Europe and other parts of the world.  Even if today much RSU
>>>  deployment exists in Europe (refs available) that runs OCB at 
>>> 5.9GHz, and VW Golf 8s send CAMs to each other, many indicators 
>>> point that it might be that these will disappear.  Such 
>>> indicators are, for example, lack of OCB mode in smartphones, 
>>> pushes from industry alliance 5GAA towards 5G-V2X, lack of FCC 
>>> reply to IPv6-over-OCB comment, and other declarations.
>>> 
>>> It is for these reasons that I tend to think the future of OCB 
>>> mode of 802.11 at around 5.9GHz is probably at risk.
>>> 
>>> Alex
>>> 
>>> _______________________________________________ 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
>