Re: [ipwave] 5G deployment status

<Dirk.von-Hugo@telekom.de> Thu, 26 September 2019 15:19 UTC

Return-Path: <Dirk.von-Hugo@telekom.de>
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 B7DDC120962 for <its@ietfa.amsl.com>; Thu, 26 Sep 2019 08:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.297
X-Spam-Level:
X-Spam-Status: No, score=-4.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 WUQ2aY6xa-Ex for <its@ietfa.amsl.com>; Thu, 26 Sep 2019 08:19:14 -0700 (PDT)
Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (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 E4C891201A3 for <its@ietf.org>; Thu, 26 Sep 2019 08:19:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1569511148; x=1601047148; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SsnZmksE/uDoJwbxpcBZJ9GRztdL1FCiOtmlL3YE6K8=; b=wsumK4HY7OS3l77+xdKkghaJ/gYvd5kjKgByVSlO6lTiRCtG+g2YWHy8 H2wReyIG3UghQ4oOT8cqq1VqXe6EcpgVxi7JB95YB79RyQSPPvkGXOOp8 631YTReiFOpg1O5wreA1bXx2A6OimV4kGJf300TIvXCSaCV3Y8tyX7T6+ gkZgQrESVNFKF2cvif/Z8hVYQXKjWtqPnAd92OEcRbZ4yqPUCgO3K9MJm PSVf0kAvhW3wD3hRr+1rkqRr6d+K/Z82AZgSiJj5mdN7v4bPUmAfUXjmS rABpbPBWqEpWJVU7kKcxVICwG2xFZUyVq443iPwJ9/hMelZY1wCBLH8oo g==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Sep 2019 17:19:05 +0200
X-IronPort-AV: E=Sophos;i="5.64,552,1559512800"; d="scan'208,217";a="370574352"
X-MGA-submission: MDFeMzwxfFWu6ZsgvStMjo+uThxEkJViRnmzUX05PMSzRJN/tRYw5sYJRbEBmuQrDwq+yx2pkteH1cEB951du3X2XDePzF4NuNi+ELgqdBGOUDPsVUqL4IhPuz4dDq/DCwDicKmQd3YKfT9Q8Cbo66NYP484BDJThDOh08gG40U40w==
Received: from he199745.emea1.cds.t-internal.com ([10.169.119.53]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 26 Sep 2019 17:19:09 +0200
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199745.emea1.cds.t-internal.com (10.169.119.53) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Sep 2019 17:19:08 +0200
Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 26 Sep 2019 17:19:08 +0200
Received: from GER01-FRA-obe.outbound.protection.outlook.de (51.4.80.20) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Sep 2019 17:19:08 +0200
Received: from FRXPR01MB0854.DEUPRD01.PROD.OUTLOOK.DE (10.158.155.22) by FRXPR01MB0984.DEUPRD01.PROD.OUTLOOK.DE (10.158.156.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.25; Thu, 26 Sep 2019 15:19:07 +0000
Received: from FRXPR01MB0854.DEUPRD01.PROD.OUTLOOK.DE ([fe80::f186:676f:f4c5:d7da]) by FRXPR01MB0854.DEUPRD01.PROD.OUTLOOK.DE ([fe80::f186:676f:f4c5:d7da%7]) with mapi id 15.20.2284.028; Thu, 26 Sep 2019 15:19:07 +0000
From: Dirk.von-Hugo@telekom.de
To: jaehoon.paul@gmail.com, alexandre.petrescu@gmail.com
CC: skku_iotlab_seminar@googlegroups.com, its@ietf.org
Thread-Topic: [ipwave] 5G deployment status
Thread-Index: AQHVdGj7BMyNYjGrXUClhaSY6oEJTKc+CZ4AgAAHKlA=
Date: Thu, 26 Sep 2019 15:19:07 +0000
Message-ID: <FRXPR01MB0854CFF0D3F2EA317C18D0DAD1860@FRXPR01MB0854.DEUPRD01.PROD.OUTLOOK.DE>
References: <156862357770.28196.6343819812576579929@ietfa.amsl.com> <d6358cfd-9c8f-3c27-28a5-d7ae20280ec8@joelhalpern.com> <EE82B5CD-B2AC-4590-9F6C-8543E30A68FF@gmail.com> <B452A31E-150E-4AE4-A693-A18AA630AB87@cisco.com> <109358A7-6F14-44DF-9113-3F36DE2194B5@getnexar.com> <BN6PR22MB00364FB9221E42BB7862C424DE890@BN6PR22MB0036.namprd22.prod.outlook.com> <d41c82441d50469ba13955af54fe6577@NALASEXR01H.na.qualcomm.com> <A175A6F452C44636ACCAEEC48CF8B1A7@SRA6> <3EAFD2B8-5FA0-475C-B436-A6ACFB32EED5@getnexar.com> <f1976b08-9fbb-6237-c7a4-fb0b84f636df@gmail.com> <3519a3de-d1b9-9651-6f9f-1baf2a93e3e3@gmail.com> <CAPK2Deyqvy51sY+_+hb8DJgvsSYwubg-TOE9GbLRSKqNLnV_tA@mail.gmail.com>
In-Reply-To: <CAPK2Deyqvy51sY+_+hb8DJgvsSYwubg-TOE9GbLRSKqNLnV_tA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dirk.von-Hugo@telekom.de;
x-originating-ip: [212.201.104.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b2889099-9c1a-45d6-2c2a-08d74294dffd
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600167)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:FRXPR01MB0984;
x-ms-traffictypediagnostic: FRXPR01MB0984:
x-ms-exchange-purlcount: 7
x-microsoft-antispam-prvs: <FRXPR01MB0984A6252454EE4B8F8AA717D1860@FRXPR01MB0984.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 0172F0EF77
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(376002)(39860400002)(366004)(54534003)(199004)(189003)(8936002)(8676002)(229853002)(66946007)(66446008)(66476007)(76176011)(102836004)(81156014)(26005)(81166006)(325944009)(606006)(186003)(7696005)(71200400001)(71190400001)(966005)(6246003)(16799955002)(86362001)(9686003)(14454004)(33656002)(76116006)(256004)(14444005)(4326008)(53546011)(55016002)(478600001)(54896002)(6306002)(236005)(15188155005)(66066001)(54906003)(64756008)(66574012)(2906002)(66556008)(11346002)(5660300002)(316002)(446003)(486006)(476003)(6116002)(110136005)(790700001)(3846002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:FRXPR01MB0984; H:FRXPR01MB0854.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: D1AQd7Ll5iNAVfwAOK+v9op2GMPy7FLd4azI7GAIg9pkxgTNYlN3n+vfy9dbdHE39Myp/fmYzqSLhT3NCyOthvdLm7w6YUlB8OTW7nAoYMXSDcxGWM9qQltaCf1LmLXkSKapzsfsgY8MJIIajtT3uGKsXevqpGbaoIJRzhYygpLK0xnl0dhn7IcooPfE9MfYY1HbUw0AoVTChnp+DX1UX0qS1IEzsYRWj1I6AMQh/+z9iRZI3s54LJ9MKGykCvsMU0OnFBPHf43zpfW7XjRQMM2IkOYvda01qaTxaSAG96TREKDaYOA9GV6Cvyzy15I2TsXjDxVnjV32saZ2IGTffPv6DECiPqRVmt/BQ7An3RHNR/dd+IFPQ+IiHz4NDfCVYPmS5RfS+QdLsBI4CIvxqN2zAvUvdgPr+GA6GutPBxRzZpU0ZKVj2lniwXX1LC464Zu5lgUP4Zh3kRnJqHHolg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_FRXPR01MB0854CFF0D3F2EA317C18D0DAD1860FRXPR01MB0854DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b2889099-9c1a-45d6-2c2a-08d74294dffd
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 15:19:07.5739 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Hd28igGn+s2pLmwPEj+FXQsJXqQ9so3iXTIberpU2XexcOufCIrSDkmx2m6qHxBHnhOmBpoOmopCoPVLqjC5u8iNn3Xd/koMXfgZ0hyzG3I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRXPR01MB0984
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/KOPfdYsgt2Yj0yRATMJF7y1aMwA>
Subject: Re: [ipwave] 5G deployment status
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, 26 Sep 2019 15:19:19 -0000

Hi Paul and Alex,
I can only agree that C-V2X or PC5 (as 3GPPs V2V link is called) is very important here.
Implementations also support IPv6 (see e.g. https://site.eettaiwan.com/events/iovev2019/dl/03_Keysight.pdf) and a planned SDR implementation based on Open source SDR LTE software suite from Software Radio Systems (SRS) also allow for IPv6 communication since some time (https://github.com/srsLTE/srsLTE/blob/master/CHANGELOG).
We hopefully will be able until end of this year to report some measurements …
Best regards
Dirk

From: its <its-bounces@ietf.org> On Behalf Of Mr. Jaehoon Paul Jeong
Sent: Donnerstag, 26. September 2019 16:47
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Cc: skku_iotlab_seminar@googlegroups.com; Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>; its@ietf.org
Subject: Re: [ipwave] 5G deployment status

Hi Alex,
Thanks for your opinion and status of 5G.

I think IPWAVE needs to consider IPv6 over C-V2X based on 5G because
C-V2X has higher bandwidth than 802.11-OCB based on WAVE.

My SKKU group is studying how to efficiently support IPv6 over C-V2X in vehicular networks.
This will be a possible WG item for IPWAVE WG.

Thanks.

Paul

On Thu, Sep 26, 2019 at 9:50 PM Alexandre Petrescu <alexandre..petrescu@gmail.com<mailto:alexandre.petrescu@gmail.com>> wrote:


Le 25/09/2019 à 16:13, Alexandre Petrescu a écrit :
> Hi
>
> Le 20/09/2019 à 04:23, Sharon Barkai and Dick Roy ([RR]) wrote:
> [...]
>>> */[RR] This is a really long story, however, C-V2X is being specified
>>> as an alternative to US DSRC, not as a cellular access technology
>>> since that’s already available and deployed.  The reason LTE Release
>>> 14 and successors is being specified has nothing to do with its
>>> lineage as a child of cellular; in fact, it is provably a square peg
>>> being forced into a round hole and we all know how that generally
>>> ends up, and that’s a story for another day/*
>>>
>>> The 5G evolution is supposed to match the latency of peer to peer WiFi.
>
> When that matches, WiFi will have leaped forward to below
> 100micro-second latency.  This was so (cellular catching up with a
> leaping forward WiFi latency) since the invention of WiFi 20 years ago,
> and it wont change.  It's a constant of evolution.
>
>>> */[RR] 5G is nothing but hype at the moment
>
> Here is a more precise status, according to my personal understanding.
> This obviously differs from many people's understandings, who may be
> more knowledgeable.
>
> In France, frequencies for use in 5G radio would start to be discussed
> now in September, with allocation towards December.  The allocation is
> similar, but not quite like, the process that was used for 3G: auction
> sales.  The differences from 3G are: (1) it is not expected to generate
> huge revenues for gov't and (2) some sales, like of the 3.5GHz band,
> would actually be a re-allocation from what was previously allocated to
> wimax operators  (e.g. SDH in France) and to City Authority (like Mayor)
> in places where there was no operator).
>
> Obviously, until these frequencies are allocated one cant really talk
> about 5G deployment on public roads, even if...
>
> If one wants to talk about 5G like when talking a higher bandwidth and
> lower latency than 4G, then one assumes 4G to be 50ms latency and
> 2Mbit/s bandwidth.  One can talk then about 25ms latency and 10Mbit/s,
> and claim that to be 5G.  But it is not 5G.  It is just another Class or
> Category of 4G.  In theory, one can still be 4G and run at 1Gbps (e.g.
> Category 16).
>
> Also, one can talk about a higher bandwidth outdoors network by running
> 802.11 WiFi on 5.4 GHz and, why not, at 5.9GHz.
>
> Colleagues call these 'acrobatics 5G'.
>
> This is when one wonders: what is 5G anyways? with its associated
> question: why was the predecessor of 5G called 'LTE' (Long Term
> Evolution), or where is the long term?  Is 5G LTE?
>
> With respect to other countries, I heard two recent announcements, about
> Spain and Germany.
>
> They both claim 5G is deployed in the respective areas.
>
> This claims 15 cities in Spain on June 15th, by Vodafone:
> https://www.xataka.com/empresas-y-economia/red-5g-comercial-vodafone-espana-tiene-fecha-lanzamiento-15-ciudades-15-junio
>
>
> This claims 5 cities in Germany, but it does not say when, by Deutsche
> Telekom:
> https://www.telekom.de/start/netzausbau?wt_mc=alias_1070_netzausbau
>
> As hardware for end users, this is the situation now:
> - there is no 5G smartphone for sale in France.  I guess it is the same
>    in more countries.  If it were different, it would be an isolation
>    easily spot by many.
> - iphone 11 just launched features 'Gigabit-class LTE' and 'LTE
>    Advanced' but no '5G'.  They run on 'LTE Bands' which are your typical
>    frequencies below 5GHz for cellular communications, but nowhere like a
>    26GHz of 5G.  No such band is called a '5G band'.

Further details after searches of public documents:

iphone 11 pro understands a 5G frequency band:

it is specified to understand several frequency bands, among which also
TD-LTE Band number 42, which is 3400MHz - 3600MHz.  This band is a 5G
band.  Part of this band (3490MHz - 3600MHz) is being considered for
allocation by regulator ARCEP.  It has not yet been allocated, but under
discussion.

ARCEP considers to also allocate Band 43 at 3600MHz - 3800MHz, for 5G.
But this band is not covered by iphone 11 specs.

ARCEP is silent about the range 3400MHz-3490MHz.  I suspect there might
be some errors here.

iphone 11 pro also understands TD-LTE Band 46 at 5150 MHz - 5925 MHz,
which covers WiFi 5.4GHz and 802.11-OCB at 5.9GHz.  I suspect there
would be some clashes here between deployed Road-Side Units and iphones.

For highways and roads requirements, ARCEP seems to plan to require the
licensee to cover them by December 2025.  And the required bandwidth is
between 50mbit/s to 100Mbit/s and 10ms latency.  These figures are
obviously little incitative, because 2025 is very late, 50mbit/s is what
4G already does and 10ms is much higher than 1ms 802.11-OCB today.

On another hand, ARCEP requires the 5G licensee to support IPv6,
starting end of 2020. (in French: "Le  titulaire  est  tenu  de  rendre
son  réseau  mobile  compatible  avec  le  protocole  de  routage  IPv6
à compter du 31décembre2020.").  This means that by that time, if IPv6
under its form IPv6-over-OCB does not see a huge deployment compared to
just 802.11-OCB WSMP, it might be that IPv6-over-5G on routes would be
more likely.  Which may raise a question of the potential usefulness of
a spec IPv6-over-5G.

So, this is to say that where I live it is not very clear how these
things will unfold.

Alex


> - one can buy off the shelf modules, like miniPCIe (I have a list) that
>    go very high in terms of bandwidth, well beyond what normal 4G would
>    do, but couldnt really use them at that high parameters.
>
> Alex
>
>>> and simply matching the latency would be no reason to switch from
>>> DSRC to another access technology for V2V safety, though nothing
>>> prevents the addition of 5G NR access technologies in ITS stations
>>> (aka OBUs) for other uses. /*
>
> I agree.
>
> [...]
>
> Alex
>
> _______________________________________________
> lisp mailing list
> lisp@ietf.org<mailto:lisp@ietf.org>
> https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
its mailing list
its@ietf.org<mailto:its@ietf.org>
https://www.ietf.org/mailman/listinfo/its


--
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Software
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>