Re: [ipwave] PC5 and 5.9GHz?

[Jerome Haerri <[e-mail]>]

the standard (3GPP) even forces it (only freq. allowed for PC5 (LTE rel.14)...so yes..

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..

BR,

Jérôme

Envoyé de mon iPhone

> Le 18 avr. 2019 à 19:08, Alexandre Petrescu <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> a écrit :
>>>> 
>>>> 
>>>> 
>>>>> Le 17/04/2019 à 14:32, [e-mail] <mailto:[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> *On Behalf Of *Alexandre Petrescu
>>>>> *Sent:* Mittwoch, 17. April 2019 13:18
>>>>> *To:* [e-mail] <mailto:[e-mail]>
>>>>> *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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/its
>>> 
>>> _______________________________________________
>>> its mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/its