Re: [ipwave] 5G deployment status (was: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt)

Sharon Barkai <sharon.barkai@getnexar.com> Thu, 26 September 2019 17:42 UTC

Return-Path: <sharon.barkai@getnexar.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 3A597120013 for <its@ietfa.amsl.com>; Thu, 26 Sep 2019 10:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=getnexar.com
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 94WGnR7bZ_38 for <its@ietfa.amsl.com>; Thu, 26 Sep 2019 10:42:01 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9431200C7 for <its@ietf.org>; Thu, 26 Sep 2019 10:42:01 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id p7so3733768wmp.4 for <its@ietf.org>; Thu, 26 Sep 2019 10:42:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=getnexar.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rFUCm1mjs99U3leN7LpNouxdL2IFCJLDbHEMU1x48A8=; b=Pql2jSd+wtmrqZ4V13JXupJm8sFPIbW5e5Kdu/W/hHk/pQyT4QuG/P2EZOQVWras+5 8/hqF3h6T91qrSMl1oun1O7Ze/+/lyRfd3dcL9sJEfNaZr7uEmEMccfWhCNxzo4cn2au rqKb07httPRJFXWzmFOYOwcRS1xRGznQ8rSVw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rFUCm1mjs99U3leN7LpNouxdL2IFCJLDbHEMU1x48A8=; b=eOHXXRFqDv5HNPZlqQgd9W+ZKb3RKHtT1v6EaUcUSn7+hq1Ev9g2m93vz8CQ42Lnct b5x5gnDmBc14n9Zt+B+qw2zgOchK1yKzpSZulcOewRFQBQwEKAVpu76nMFY+kkbMhQJg +GTP0bHukYyLFrscmJHtHjmhu8j2BXeUIdggW9FsKwIh/6g0mWYs3v18Xyyay1c/Yps4 Jl7Gk4MmfyEqvYOOZL0GbEg1+AqV2/BFsfMXpLJI4Nwv5ARSFJJbIzFEuBI4q3otnz+N FdC16bblZW8Ze6oqpA8mU2ifbhPbobnLGUZaraYTksJNwj3qLvFVAZ3+VeYrMnyu6Q36 Ot9g==
X-Gm-Message-State: APjAAAWZ89bv7812c5MQqrc+PyfV+i0RQ6StY0RkxAJa+MsazWTsqLPl kzQPaFmSjr+KosRQpLuWZS6YZjlqryxm89kWxK/Q+Z8jVWQeKm7pcsEYTQrlg4n26xouI/ZdQNp 2liAFrxLc0S2L7QKQJHUC7KlWz5Ezt3Qw94/gtvfD8YKOMf89OyhWqq98okbgf8cwGQ==
X-Google-Smtp-Source: APXvYqyTaasccaE6ccUpIIfX/uHK3jgmmlyM2gnh6TOTvPyLv7F6J+RklmAfMuovo0yhPWHj0VSc3A==
X-Received: by 2002:a7b:cd99:: with SMTP id y25mr3633855wmj.152.1569519719141; Thu, 26 Sep 2019 10:41:59 -0700 (PDT)
Received: from [192.168.1.12] ([213.57.218.196]) by smtp.gmail.com with ESMTPSA id z13sm2136464wrq.51.2019.09.26.10.41.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Sep 2019 10:41:57 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Sharon Barkai <sharon.barkai@getnexar.com>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <f1976b08-9fbb-6237-c7a4-fb0b84f636df@gmail.com>
Date: Thu, 26 Sep 2019 20:41:56 +0300
Cc: dickroy@alum.mit.edu, "Victor Moreno (vimoreno)" <vimoreno@cisco.com>, "Ratliff, Stanley" <sratliff@idirect.net>, lisp@ietf.org, its@ietf.org, William Whyte <wwhyte@qti.qualcomm.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <15C3326B-FE51-4774-BFF6-8EE17E86FF63@getnexar.com>
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>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/6biYBO1aebshXZnrpuYncx81nZc>
Subject: Re: [ipwave] 5G deployment status (was: Re: [lisp] I-D Action: draft-barkai-lisp-nexagon-10.txt)
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 17:42:04 -0000

Thank you Alex for this clarification.
Just to further clarify the proposal at hand:

1. There are significant challenges in having sensors information producers communicating directly with consumer driving applications.

- sensors may be periodically wrong or otherwise misleading, PKIs try to protect from some of that as well as protect privacy, but direct is typically more exposed. 

- its very hard to evolve the content of the information because of the intrtop matrix
its unlikely that any vendor will trust a single vendor to set the bar on all  interoperable functionality  

- its hard to navigate consumption through a flood of information from all sensors around, and, without aggregation timing gaps may preclude critical information and result in pile-ups

For these reasons among others it was suggested to use the EID layer of LISP virtual IP as a standard in-network service for aggregating and brokering information - rather then using proprietary servers.

Among the “other reasons” is one that was cited by people on the thread which is - allowing for immediate business success of mobility networks.

Until which time where each road is measured on throughout and safety on a moment by moment basis by any of the market player - gov-muni, car OEM, insurance .. we need to keep extending mobility network functionality with economical features quickly. This is hard to do without EID indirection.

2. A LISP EID based mobility brokering does not specify in any way the layer2 or RAN used for mobile IP. If there is a pervasive economical low-latency mobile IP network based on WiFi then it should be used. Cellular mobile IP is currently more pervasive and economical because it is multi-application. However its latency limits some of the heads up alert specified in the EID layer. Limits lifted gradually by real (and theres a lot of fake) 5G and MobileEdge deployments.

In any case network based alerts are there to extend the reach of the on-car sensors. For example, a heads up alert on a baby-stroller beyond the corner spotted by cross traffic immediate no-network sensors will actually meet the timeline required for vehicles making the turn when brokered over regular LTE . The point is that a lot of progress can be made using cellular mobile IP available right now.

So hopefully there is no contention between the EID based efforts using H3 virtual terrestrial state “tiles” vs other direct terrestrial communications efforts. 
Hopefully these different approaches are complementary.


--szb
Cell: +972.53.2470068
WhatsApp: +1.650.492.0794

> On Sep 25, 2019, at 5:13 PM, Alexandre Petrescu <alexandre.petrescu@gmail.com> wrote:
> 
> 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'.
> - 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