Re: [ipwave] PC5 and 5.9GHz?

Jerome Haerri <jerome.haerri@eurecom.fr> Thu, 18 April 2019 19:34 UTC

Return-Path: <jerome.haerri@eurecom.fr>
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 B48BC1200E6 for <its@ietfa.amsl.com>; Thu, 18 Apr 2019 12:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 GiIoKSPPZVhF for <its@ietfa.amsl.com>; Thu, 18 Apr 2019 12:34:07 -0700 (PDT)
Received: from smtp.eurecom.fr (smtp.eurecom.fr [193.55.113.210]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC16120346 for <its@ietf.org>; Thu, 18 Apr 2019 12:34:06 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,367,1549926000"; d="scan'208";a="9952001"
Received: from waha.eurecom.fr (HELO smtps.eurecom.fr) ([10.3.2.236]) by drago1i.eurecom.fr with ESMTP; 18 Apr 2019 21:33:53 +0200
Received: from [10.141.125.38] (unknown [92.184.100.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtps.eurecom.fr (Postfix) with ESMTPSA id 9D2CE374; Thu, 18 Apr 2019 21:33:52 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Jerome Haerri <jerome.haerri@eurecom.fr>
X-Mailer: iPhone Mail (16E227)
In-Reply-To: <c6b6f6b9-a5e6-4e5b-3421-0f4fc7605353@gmail.com>
Date: Thu, 18 Apr 2019 21:33:51 +0200
Cc: its@ietf.org, Dirk.von-Hugo@telekom.de
Content-Transfer-Encoding: quoted-printable
Message-Id: <2E41A658-FB66-4C0E-BAE7-70E6DA48A6A9@eurecom.fr>
References: <abfbf312-be3c-c957-d58e-67b141697a14@gmail.com> <LEXPR01MB06697DF790A19AEBC7E7E4D2D1250@LEXPR01MB0669.DEUPRD01.PROD.OUTLOOK.DE> <c9f2c360-dee7-c0cb-5cce-e493ef203c42@gmail.com> <EA7C2CE7-599F-4352-8EA7-3B20B6461950@eurecom.fr> <B9223A19-F544-4E84-9E39-BBD47EEC28B5@eurecom.fr> <95dbc7de-b736-1c5b-8bac-80b22024af89@gmail.com> <0B165A63-0876-4AC6-840C-1B5D896A3244@eurecom.fr> <c6b6f6b9-a5e6-4e5b-3421-0f4fc7605353@gmail.com>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/4D4I98hxZyNd9w80qDp1vG5DUBc>
Subject: Re: [ipwave] PC5 and 5.9GHz?
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: Thu, 18 Apr 2019 19:34:10 -0000

> I hope there is understanding about risks of putting together non 802.11 headers with 802.11 headers in the same frequency.

yes, a big one...and a tive research in fibding a solution..but it is slso political. Btw, in the US, you also have OCB 10Mhz headers coexisting with 20MHz Rlan wifi headers..also problematic..

> It is sufficient to drive a little bit around to listen to 5.9GHz and see there is already a lot of 802.11-OCB traffic.  Not sure how can that coexist with PC5 because this latter does not have 802.11 headers.

maybe in a few months I will be able to tell you how...earliest ETSI vote in this, March 2020...
> 
>> But: it cannot use these frequencies now (well it got some test freq. in the US) (ITU in charge for spectrum allocation in EU) as the coexistence (PHY/MAC) with ITS-G5 needs to be solved first..
> 
> Is PC5 using IP, like 5G does?

well, 3GPP allows IPv4, IPv6, and ‘non-IP’

yet, in EU, PC5 requires the ETSI geonet stack to operate on 5.9GHz, so no (or through geonet)
As it needs the ETSI security framework (even refered in 3GPP LTE sidelink standard) and use per packet wireless congestion control ..so, good old story..

btw, not clear yet that 5G-V2X will use IP on PC5..too early to tell..unless you have news about it (or you meant LTE Uu, which uses IP)

BR,

Jérôme


> 
> Alex
> 
>> BR,
>> Jérôme
>> Envoyé de mon iPhone
>>> Le 18 avr. 2019 à 19:08, Alexandre Petrescu <alexandre.petrescu@gmail.com> a écrit :
>>> 
>>> 
>>> 
>>>> Le 18/04/2019 à 15:57, Jerome Haerri a écrit :
>>>> Dear All,
>>>> just minor modification to avoid misunderstanding:
>>>>> the EU is quite clear: there should not be technology ban on the ITS-G5 SPECTRUM
>>> 
>>> I dont understand ban.
>>> 
>>> My question is simple: is PC5 at 5.9GHZ?
>>> 
>>> Alex
>>> 
>>>> Sorry about the confusion,
>>>> Jérôme
>>>> Envoyé de mon iPhone
>>>>> Le 18 avr. 2019 à 15:50, Jerome Haerri <jerome.haerri@eurecom.fr <mailto:jerome.haerri@eurecom.fr>> a écrit :
>>>>> Hi Alex, Dirk,
>>>>> 
>>>>> the EU is quite clear: there should not be technology ban on the ITS-G5 as long as it is for ’safety-related’ applications for road ITS.
>>>>> This being said, for another technology to use ITS-G5 spectrum, it must coexist with existing technologies, and be commercially available.
>>>>> 
>>>>> For now, the EU commission in its DA estimates that these two points are not there yet, thus recommened to use ITS-G5 on the CCH, only (the EU still pushes for both technologies in other channels for Day 2 applications..no regulation yet)
>>>>> 
>>>>> Indeed as of today, LTE-V2X and ITS-G5 cannot coexist at PHY and MAC layer..
>>>>> 
>>>>> Both ETSI ERM and C2C are working on PHY and MAC extentions for coexistence.
>>>>> 
>>>>> Yet, indeed even at L3, we should envision ways to differentiate between technologies. Let’s see once PHY/MAC coexistence will be completed...
>>>>> 
>>>>> BR,
>>>>> 
>>>>> Jérôme
>>>>> 
>>>>> Envoyé de mon iPhone
>>>>> 
>>>>>> Le 18 avr. 2019 à 15:17, Alexandre Petrescu <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> a écrit :
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Le 17/04/2019 à 14:32, Dirk.von-Hugo@telekom.de <mailto:Dirk.von-Hugo@telekom.de> a écrit :
>>>>>>> Hi Alex,
>>>>>>> I strongly agree with you that we need a precise definition on what we mean with cellular V2X (often denoted as C-V2X in general – so covering LTE and 5G/NR) – especially since – as you correctly pointed out - 3GPP has none such official definition as LTE-V2X or NR-V2X .
>>>>>>> However when defining LTE-V2X we should be aware that there are two different modes of operation for V2X communication in 3GPP cellular systems (as also described in Annex A.5 of PS document https://tools.ietf.org/html/draft-ietf-ipwave-vehicular-networking-08).
>>>>>>> E.g. according to 3GPP TR 21.914 giving a Release 14 (i.e. LTE) Description and Summary of Rel-14 Work Items, but similarly also for 5G/NR or Rel. 15 and higher (here in still draft TR 21.915) the modes of operation are described as
>>>>>>> -Direct V2X communication between UEs over a 3GPP sidelink (PC5 interface)
>>>>>>> -V2X communication over LTE-Uu interface (i.e. via base stations / eNBs)
>>>>>> 
>>>>>> Dirk,
>>>>>> 
>>>>>> A colleague in a group perform a study of latency comparison between 802.11-OCB and LTE-Uu between cars.  It is simulation.  They found numbers comparing the latency.
>>>>>> 
>>>>>> On another hand,
>>>>>> 
>>>>>> Do we know whether the use of the PC5 interface is allowed at 5.9GHz?
>>>>>> 
>>>>>> That may have an impact on an IP-over-OCB thing:
>>>>>> - if PC5 is allowed at 5.9GHz then the only way to make sure it co-exists with OCB at same frequency is to use Traffic Class or Flow Label field in IPv6 header.  That is a good work item.
>>>>>> 
>>>>>> If that work item works, then one may need to map these QoS fields into the QoS fields of the 802.11 header, fields required in the IPv6-over-OCB document.
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>>> In addition there are 2 different modes for PC5/sidelink:
>>>>>>> -in coverage of cellular system with LTE assistance
>>>>>>> -out of coverage: ad-hoc mode w/o assistance … very similar to OCB.
>>>>>>> So I would recommend to specify more exactly what we have in mind.
>>>>>>> LTE-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3GPP 4G – both via base station and directly between vehicles
>>>>>>> Or more general:
>>>>>>> C-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3G, 4G and successors – both in infrastructure mode (via base station / Uu interface) and ad-hoc mode (direct link / sidelink interface) if available [since sidelink is only specified for 4G/5G]
>>>>>>> Or one may even reflect differentiation between those modes in the acronym (which I would not recommend here being not in scope for this document)
>>>>>>> Just my 2 cents
>>>>>>> Kind regards
>>>>>>> Dirk
>>>>>>> *From:*its <its-bounces@ietf.org <mailto:its-bounces@ietf.org>> *On Behalf Of *Alexandre Petrescu
>>>>>>> *Sent:* Mittwoch, 17. April 2019 13:18
>>>>>>> *To:* its@ietf.org <mailto:its@ietf.org>
>>>>>>> *Subject:* [ipwave] LTE-V2X term in Problem Statement document
>>>>>>> Hi IPWAVErs,
>>>>>>> The IPWAVE Problem Statement document uses the term 'LTE-V2X' at one point. ("e.g., IEEE 802.11-OCB and LTE-V2X")
>>>>>>> I would like to suggest to make a careful definition of the term 'LTE-V2X'.
>>>>>>> One would expect the term 'LTE-V2X' to be defined precisely at 3GPP or similar.  But that is not the case.  The 3GPP document that is closest to this term is RP-161298, publicly available, defines the term 'LTE_V2X' (remark underscore '_', instead of dash '-').
>>>>>>> I suggest the addition of the following term in the Problem Statement draft:
>>>>>>> LTE-V2X: the transmission of ETSI CAM and DENM messages over IP over a cellular link such as 3G, 4G and successors.
>>>>>>> Alex
>>>>>> 
>>>>>> _______________________________________________
>>>>>> its mailing list
>>>>>> its@ietf.org <mailto:its@ietf.org>
>>>>>> https://www.ietf.org/mailman/listinfo/its
>>>>> 
>>>>> _______________________________________________
>>>>> its mailing list
>>>>> its@ietf.org <mailto:its@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/its