Re: [lisp] 5G deployment status (was: Re: [ipwave] 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: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB2F1200E3 for <lisp@ietfa.amsl.com>; Thu, 26 Sep 2019 10:42:03 -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=ham 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 qGBais8Jv4cO for <lisp@ietfa.amsl.com>; Thu, 26 Sep 2019 10:42:01 -0700 (PDT)
Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 B5EDF120013 for <lisp@ietf.org>; Thu, 26 Sep 2019 10:42:00 -0700 (PDT)
Received: by mail-wm1-x329.google.com with SMTP id r19so3735318wmh.2 for <lisp@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=Hop8Vw6VIhQ6xR9Qq36BLlHlUwX/m+7+xXoMU1f53JmRiUegUGEMgZqZ8kKiJUm4N1 JXL51umvMNDodedCB0/DDC2PGmxZoocPAlsRvHqAlk0a2/XDL7A9oCfvyptXfvDcs1Zb kKn/FhOJyKKyCjpnNK0hiKnfsxC0ayJLdBl4JV97xZhd77OVz2jm7FUu0xoioLlffcCZ SUq1YrzVH0Wr6m949gHk2uWDg+gvkyqyRFwZNuivBFvwknZ7YBzM8yUVj/LVlkqGbnyn zO3qXCfsSlH8qq3KAJlWtX0Jh26+0YnnWuxz62WgLhaCQT88N3yYVDcweGZlZKy3RKmd sZuQ==
X-Gm-Message-State: APjAAAXbjeJK0cjn58StCexkg+wFTlzo9EBGlxmVdCRa+dQS7FDtAX9d cG7f78F7CMQFUeqfyhcCwCdXdg==
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/lisp/IX3PBefYyHxzfWZTPdxlx9foz6w>
Subject: Re: [lisp] 5G deployment status (was: Re: [ipwave] I-D Action: draft-barkai-lisp-nexagon-10.txt)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-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