Re: [6gip] 6G in 3GPP?

David Lake <d.lake@surrey.ac.uk> Fri, 15 January 2021 19:51 UTC

Return-Path: <d.lake@surrey.ac.uk>
X-Original-To: 6gip@ietfa.amsl.com
Delivered-To: 6gip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDCF3A107C for <6gip@ietfa.amsl.com>; Fri, 15 Jan 2021 11:51:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=surrey.ac.uk
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 OjdoaQ87Td2q for <6gip@ietfa.amsl.com>; Fri, 15 Jan 2021 11:51:18 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40093.outbound.protection.outlook.com [40.107.4.93]) (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 4485D3A1110 for <6gip@ietf.org>; Fri, 15 Jan 2021 11:51:18 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KYukCDV8aWekkR7WT+WCuK9nrh/6680OJv4ljYcfbQRrOUY64H1bD7h1sQ+8jZBSirLBzbTXScoxRqA7/dEoyT+s0VjVk3WuHn/nknOoHbL5hqqRGNn2aFGFg4TqgOkWrAetjrYuTJIbBGyjMgm0T740970AsIQiQlOpp81ALh+TPRv2DyOkz5gH4iw22hywYNIoc7OpkEMlIfdXZr6dMQ0xcG/baMD86xxTGspDTSZ9Bx6lWFGWrAkHLfAChSqdMMbsrYCWA6u6laVONP+5BZ3t00T4tO7OCmwJ4IgbiNnBWtfJFstQKgn0zxoqWBTvHs05AwWVRY3AmnsXsvN37g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2SualYeMruHeukz3pQjjdK/TqbE3s6LMv20ZzNSINnM=; b=hLSj7/X2UpLXvzucgWE4O5ZUmYcUdKzUBq5OO+ffgfdRa12yF8LXlPvSMu++9IydjpqCKFktOmiIvX1JYHtEZlOS1HCPIh2u5GXu0eA8gPkHfRG7X67+Omrd1w8B4GwUb7eHUNyPOi0y5QDTJWshdfwEY1pawRhYf81mDtvifZtG+gnodOMcJfBLxw0LvTxjTYfG0Cb92BKGv4BEnvB5iAqDvawB5N+vrtlsV2G4rpwFNtQVWUKUXRBU9V3XmokaJNZnOTaxrIf0S/I8O1LZSahFnMz0LBQ0eXMMDCMQJrICv5qDHarmXPMInVU02qcD2qp3kMVN+8dG0+An5l30Tw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=surrey.ac.uk; dmarc=pass action=none header.from=surrey.ac.uk; dkim=pass header.d=surrey.ac.uk; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=surrey.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2SualYeMruHeukz3pQjjdK/TqbE3s6LMv20ZzNSINnM=; b=ZNi9MoMaP443nEt3jHHpFk+p+239AbRLWEBihds2R/fzI3FWaOKQZhJWRtFHTV984AplQw8KdDTB5YzTHQTQ79NenCNC/EEoOKlJeSki4YvE+zvs2OuQk7Ovy9dYChi7eE8t+3xybExT7kdmTZ18v1bwS55XGDwi02aAOozftbA=
Received: from DB7PR06MB4792.eurprd06.prod.outlook.com (2603:10a6:10:57::20) by DB8PR06MB6457.eurprd06.prod.outlook.com (2603:10a6:10:128::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Fri, 15 Jan 2021 19:51:15 +0000
Received: from DB7PR06MB4792.eurprd06.prod.outlook.com ([fe80::eca6:b32c:11fa:21d6]) by DB7PR06MB4792.eurprd06.prod.outlook.com ([fe80::eca6:b32c:11fa:21d6%5]) with mapi id 15.20.3742.012; Fri, 15 Jan 2021 19:51:15 +0000
From: David Lake <d.lake@surrey.ac.uk>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "6gip@ietf.org" <6gip@ietf.org>
Thread-Topic: [6gip] 6G in 3GPP?
Thread-Index: AQHW6cTp+mgrQaomnUyO1LwIdAQp3aonUboAgAAg+YCAABR0gIAAA6wAgAAEOoCAAOhHwIAAReUAgAAP6KA=
Date: Fri, 15 Jan 2021 19:51:15 +0000
Message-ID: <DB7PR06MB4792C81377C428841A7D569AB5A70@DB7PR06MB4792.eurprd06.prod.outlook.com>
References: <HE1PR07MB3386A43B4B32BF2CE5DC48C79BAA0@HE1PR07MB3386.eurprd07.prod.outlook.com> <248399ab-7dc1-ee13-928c-751568ea58e5@gmail.com> <HE1PR07MB3386A19851BFFF1ED5DDECAE9BA90@HE1PR07MB3386.eurprd07.prod.outlook.com> <CAC8QAccaYy7hKAdz9Y79wMrE0UFBa_=PsERyeGpiMmYpWESLLw@mail.gmail.com> <HE1PR07MB3386B9F18A356F64A0B6DD359BA80@HE1PR07MB3386.eurprd07.prod.outlook.com> <2281d844-ae2c-ecdd-9cf7-e9e130af3739@gmail.com> <1610654118.14219.268.camel@gmail.com> <85a003a1-f833-ad5f-6f1f-a8e26cbc0039@gmail.com> <DB7PR06MB47925677D30E281EAEFC39A9B5A70@DB7PR06MB4792.eurprd06.prod.outlook.com> <b52b3d34-f389-b38c-1098-85fe52da83c1@gmail.com>
In-Reply-To: <b52b3d34-f389-b38c-1098-85fe52da83c1@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=surrey.ac.uk;
x-originating-ip: [2a00:23c4:3d04:da01:a4fb:fbe4:a807:7c03]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8116ac17-3544-4ecb-9936-08d8b98eeb58
x-ms-traffictypediagnostic: DB8PR06MB6457:
x-microsoft-antispam-prvs: <DB8PR06MB64574CBA209F89B804D02781B5A70@DB8PR06MB6457.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: uG95HysmCHols0Sum4MfgnReE2j5RBZCgN+bkNxPeSS+X3g/lQV/zYuPuoohK1cY7PLEjfySqblPk8SvJfitm62BbNCV7oNkdBYo2JtkZ+gkOSX2e71ypJdq14e5mGEpBY4+tq/G24+YPtJNImAEjz6Fe3tU8hPWJZweU3Ys8SQV47lsjzgt6P07t+s9z8NqMIfuz9PjkNRTZt3fUVio1tKa2bnWT5ZArVUvGXVsdD6ZVAbkYgbeaoK1fNiyHUW4P1MLvB3bMUy3z58AlDKLzQ8Yu9wgka1GPHgjuqWi9lHw8mdGwWD+wx0TSGsrWGJ7KDuGHuUVpYRGtPPcfjfOTDMJWacftj05kw2PAbuWDsHg8QqSNWnX112+BhMVzHptcB19aYUMwMljsj1LUXh4VAbvmEE9/rARGXkK2weHgZn50aBAQL7L5Ls4vv+Oz9EtD25eixJ4XdEwAvC6ikFmkvmPH2LJxXTbH6TnUhq4kLhMwTQbAneylf8z2KgRW8xU2VQ8BoFT0X0rKpl71MXWwhf7DUBa7XSNtlsN04BimEDtEgOGzNJ/iryci0uiJ9yAjROSkVFegeENdqZ0W/fFX9ynJiqv4c982lMDc4Qmj9Y=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR06MB4792.eurprd06.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(39840400004)(396003)(346002)(66556008)(66946007)(66476007)(66446008)(64756008)(33656002)(52536014)(71200400001)(5660300002)(6506007)(2906002)(186003)(7696005)(45080400002)(30864003)(66574015)(76116006)(8936002)(478600001)(9686003)(86362001)(786003)(110136005)(83380400001)(55016002)(53546011)(8676002)(316002)(966005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: bfVsGyv/QpAFwyiDTkdQb/bPhBzm+3jT/nd6qYRbzM/eQqCsp8Kz9F11rIYKdSv261fA9ZbKaXi9TsKpeFVF7TNy7QFpinsD/kX3bDRlAt32mej1xMaMgYqg2vniulsRS+QDjuCycagjPfj3t8NQjZ2iYWYdHJkKN6BltSY87Wp6YnaQFNOQ/gtpmQ0AUIKmYM/rbXwGBC74IC2JYIvTeTatC62t55IU+CbU1VM1ZJyfuU0HQwT7l11trVHzt9vejkzUvy+NiWcMfwsU4CG/3WbefyUm4MGafkEuvvlnZi41ZjqnoFvF/Ak7Sby6qs5m5oMo8LnjawguUsu/ZoOj2FCXzJsMUv0vXNCRDiMbAJxlPuuk7Fpo30v0FRNZzAhEbzZX2iQMJDmvKfr3r0N9v7/WRvuJwIqrUdJg9wtJpd4O9PgX6EuOi60aiI2p/nNqhbm3f6QmSrA8wLj9erNn90/bQNA0C5Poxzjk0t6lCVuFPT4HS0IodDdvJuDYjofl8LvhTGp09AyNuFbpaAimx5tuSsRrvdeDqP4qCOyAY+WvCSrXCer6x4dsE4ie+4sspqSnpSdJlzr5Mc2vApRl62EPF+EJOZS6ZPJzAChJbaMZU0xLQCH9xU6BuUSVaDTUCvMtP2KNXLunntdnvFH4Fsbr+weLOXVRIDKAuGxecniwjuPeG7HN4siTEWBkyGT6Ttwo3Gdh4yQpK1ZdX13Mv5fO31vKtqdrKToUp+BKnekmlVBTPo0UauuIrPrIcb+uhwqg4U2oKBASilkHglt2I7yNq4p7HTBWrF5hCeUKyoFriW3w1fwophTCv5mLfE1og56fZWRn3glrL4xjGhfFaoKYy14Tenm5Oev6j7JQfe898w/5onHavdJO/tHG/2Jq+RlXd9QYp7e/zt60rdJJSLcVsn3tDGKjLACaLgeoDWkOFQUtOiDeRI/q5jgPPNkSi86tmzO+t8rrZmSVlAAaGRewFP9nD4Hy6uYWUGEvNNuf662t8Wx49+4W5aELpFzKW/JnTBIWtp8q5pFr4mEh62q1OW3W6MX/wRvhKRo8dCB8rzwMfBMpdiNAk4HX/RWP
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: surrey.ac.uk
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DB7PR06MB4792.eurprd06.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8116ac17-3544-4ecb-9936-08d8b98eeb58
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2021 19:51:15.7082 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 6b902693-1074-40aa-9e21-d89446a2ebb5
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: zN3Wb4D/kb7oZSIMliR0fRRgREJYqY2bJUpCq6pMwTTyK8J4auA0FpgTfkYdQeZfnvpOcXFOSiOeDo9EeoasZA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR06MB6457
Archived-At: <https://mailarchive.ietf.org/arch/msg/6gip/C0JUCaOL43TB01f5GpeCqP7X5Fk>
Subject: Re: [6gip] 6G in 3GPP?
X-BeenThere: 6gip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IP Issues in 6th Generation Mobile Network System \(6gip\)" <6gip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6gip>, <mailto:6gip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6gip/>
List-Post: <mailto:6gip@ietf.org>
List-Help: <mailto:6gip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6gip>, <mailto:6gip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 19:51:21 -0000

Alex

<DL> in-line </DL>

David


-----Original Message-----
From: Alexandre Petrescu <alexandre.petrescu@gmail.com> 
Sent: 15 January 2021 14:12
To: Lake, David (PG/R - Elec Electronic Eng) <d.lake@surrey.ac.uk>; Rex Buddenberg <buddenbergr@gmail.com>; 6gip@ietf.org
Subject: Re: [6gip] 6G in 3GPP?



Le 15/01/2021 à 11:50, David Lake a écrit :
> Alex
> 
> You miss the point - mobile phone networks are NOT mobile in terms of 
> the protocol.  They are mobile in terms of the base connectivity.
> Whether it is 2.5G (GPRS), 3G, 4G or 5G the solution is the same -
> static IP network with a GTP tunnel to an anchor point.    The
> "network" layer as IETF understands it (i.e. Layer 3) remains static.
> 
> Also, they are managed, controlled networks - the numerology on the 
> air-interface is tightly-coupled to the service level - there are 
> levels of quality conferred by different numerologies which have known 
> propagation properties over-the-air.
> 
> For example, VoLTE uses a QCI of 1 for the VoIP traffic which has a 
> guaranteed bit rate over-the-air and very tight packet-loss, bandwidth 
> and latency parameters.
> 
> This means that traffic arriving in this class can be marked and
> policed exactly.   Because spectrum is expensive (and GBR uses more
> spectrum per bit that UBR default QCI=9 traffic) the amount of 
> spectrum allocated exactly equals the amount needed for the VoIP.
> 
> This is COMPLETELY different to how today's Internet works in several
> respects:
> 
> 1) If the air capacity isn't available on cellular to make the VoLTE 
> call, the call WILL NOT proceed.  That is tight admission control of 
> the kind we do not have on the Internet.

But we do see a large number of people on the Internet talking VoIP, are mobile on WiFi, and not on cellular smartphones.

They are not subject to tight admission control.

<DL> And the quality shows!   The number of times packets are lost, you have codec changes, dropped words.   WiFi is severely congested - you cannot fit a quart into a pint pot.  If the architecture allowed, we could put the VoIP packets over QCI 1 and then onward route.  The mobile architecture allows you to do this - it is the fixed Internet that is lacking.   This is noticeable on WoWiFi (SP delivered IMS-coupled voice over WiFi). 

In terms of QoS, I go back to Call Admission Control as done by my past employer in CallManager - we knew the bandwidth each codec needed, the speed of the circuit and therefore only allowed the right number.  The issue is that a rising tide lifts all boats - if you have 5 good calls and enough bandwidth for 5 calls only, allowing a 6th does not just break the 6th - it impacts ALL of them.

</DL>

> 2) Should the air interface display excessive loss or the network be 
> aware that the requested mobility move cannot support the VoLTE 
> service, the call will be moved to Circuit Switched (this is becoming 
> less common but many operators choose not to deploy VoLTE so as not to 
> burden themselves with this).

Yes.

But at some point it might be also too much planning.

In a world where network and computing technologies continue to grow fast, what was excessive yesterday is normal today, and can be accommodated.

I wonder what the term 'VoLTE' becomes when 5G is out, and what 2.5G, 3G, 4G and 5G become when 6G is deployed.  They might all be discarded with all their complications.

<DL> I'm trying hard to decipher this statement and can't.  The complexity is already there in that I suspect we will have to maintain 2.5G, 3G, 4G and 5G networks for many years.  Proposals to switch off 2G have been met with objections as many customers are using them for EFTPOS systems.  Plus the longer you keep a network running with customers, the better the payback. 

VoLTE is retained in 5G - it is called Vo5G and has exactly the same architecture with IMS. </DL>

> 3) Bandwidth per application is allocated both at the Air Interface 
> and Packet Core to exactly match that required by the service.  This 
> is the joint roll of IMS and radio control plane (AMF/SMF) to ensure 
> that the requirements of the media service can be delivered by the 
> radio bearers.
> 
> 4) Handover happens without any break in service - it is unusual to 
> loose even a single voice frame in cell handover (20ms
> packetization).   Handover is specified (I think ...) to operate in
> 5G when moving at >> 360km/h

YEs, it is a handover at data link layer.  IT is efficient.

But it is subject to the same overall policies that guide the admission control and the QoS allocations.

One negative side effect of how handover is performed in celllular systems is that roaming between one country to another, in Europe, still involves break in service.  During a phone call in a train passing the border there is always a break, and have to call again.  This happens even though there are roaming agreements, and in Europe there is this universal payment scheme - still the break in phone conversation happens.  It has been so for years and it continues to be so.

<DL> That is not a technical issue but a political issue. It is the same within a country - there are multiple operators that serve some areas and not others - what do you do; buy a phone on each of the 5 MNOs and always carry them with you?   The answer is a single core network which is exactly what Vodafone wanted to do across Europe but were blocked on ownership grounds.

My suspicion is that we are going to see a huge amount of consolidation in mobile operators soon and that we may even get to the point of a single operator per-country possibly under shared ownership (could be private, could be public - that is a geopolitical question) exactly as we do for power grids.   The problem we have is that the "Telco" and governmental view of the world does not match the reality of a global Internet... </DL>

> 
> 5) CoMP means that a single IP session may be served across several 
> aggregated radio bearers - QCI is maintained across CoMP.

Probably yes, but it is not so when crossing the border.

> 
> 
> There are 9 levels of QCI in LTE and 26 defined 5QI values in 5G.
> Each specifies Layer 1/2 parameters to give a defined outcome and
> have been mapped to example applications by 3GPP.   Unfortunately,
> once you leave the packet core, there is very little onward-mapping of 
> QoS other than the super-aggregated MPLS-TE bundles Toerless 
> mentioned.  None of those are "consumer dynamic" in the manner that 
> cellular networks can do.
> 
> Could you go point-to-point in cellular networks?

Yes, again, now all cellular networks are point-to-point and are circuit-switched; the ptp links and the tunnels are 'switched' if I can say so.

This is not the old mechanical relays that 'switch' contacts; but it is not packet forwarding either.

In pure packet forwarding the decision of where to send a packet is made on a destination address; in circuit switching the decision is made on another identifier, such as the tunnel id or ptp link id.

<DL> No-one does pure packet-forwarding at scale.  Everyone does some kind of tunnelling - GTP, MPLS, PPPoE.  The only way we scale is with tunnels.   The GTP tunnel actually works very well - the header compression is highly effective and the predictive hand-over mechanisms very good.   Also remember that Lawful Intercept is a requirement and having all packets appear in one (or a few) locations helps. </DL>

   Well, yes, but
> you'd have to work out how to allocate the VERY expensive spectrum
> and deliver against tight SLAs for applications.   That then means
> you'd need some kind of central controller monitoring all the possible 
> connections and allocating resources as-needed.

Hm, but some people work ok on WiFi spectrum, I think.

<DL> Less and less.  WiFi at 2.4GHz is horrible in many locations.  Also the price of 4G is reducing rapidly - in the same way that many people no longer buy POTS lines, I suspect many will use 5G as their primary access. </DL>

> 
> Does Mobile IP fix the problem - only partially because it has ignored 
> any coupling to the most fragile part of our networks, layer
> 1.   Plus it uses tunnels...    Broadband services (DOCSIS and DSL)
> all use anchored tunnels.

3GPP also uses tunnels.

> 
> Rather than asking whether mobile networks could be more like flat IP 
> networks, I think the opposite is the case - could be have a more 
> business-like arrangement on the Internet where I am actually able to 
> state what OUTCOME I want, PAY for it and have the various parts of 
> the network deliver against a contract!

Business will be made, but wouldnt put business at the fundamentals of it.

There is this 'contract-based networking' in NewIP that one would win from looking at but ultimately, the contract parties are deemed to simply to their best to achieve their commitments - best effort.

If my PC were to have a contract with each intermediate router that forwarded this datagram it would be unscalable...

<DL> That's not quite what I'm saying.   There are several elements where I think what we CURRENTLY do with the Internet is vastly different from other shared-media networks (e.g. electricity, gas, water in some countries, rail).   I think this is a longer discussion and possibly a piece of research though.

Having been involved in networking for 30+ years, I think that the nature of the Internet has changed drastically and we need to take a much more commercial view of the world.  </DL>

Alex


> 
> 
> David
> 
> -----Original Message----- From: 6gip <6gip-bounces@ietf.org> On 
> Behalf Of Alexandre Petrescu Sent: 14 January 2021 20:10 To: Rex 
> Buddenberg <buddenbergr@gmail.com>; 6gip@ietf.org Subject: Re: [6gip] 
> 6G in 3GPP?
> 
> 
> 
> Le 14/01/2021 à 20:55, Rex Buddenberg a écrit :
>> On Thu, 2021-01-14 at 20:42 +0100, Alexandre Petrescu wrote:
>>> The reason I might have mistaken "beyond-5G" for "6G" is that I 
>>> worked on a "Beyond 3G" once that never materialized.  Then I 
>>> surveilled 4G and I _think_ I didnt see a "Beyond 4G"
>> 
>> False equivalence.  Compounded by using  marketing terms which have 
>> sloppy definitions.
>> 
>> All cellphone technologies through '3G' used circuit-switch topology. 
>> The generational differences are all related to transmission, not 
>> switching. LTE is a packet switch technology.
>> This is a one-time shift. By contrast, 4G, 5G and 6G, whatever the 
>> latter two turn out to be, are safely assumed to be packet switch 
>> technologies. Or said another way, routable network segments.
> 
> But packet-switched technology on a point-to-point link is almost the 
> same as a circuity-switched technology: there is no need of src and 
> dst addresses; there are ptp tunnels in the core.  This led to many 
> quirks in the use of IPv6-related protocols on 3G, 4G, LTE, and I 
> suspect on 5G as well.
> 
> Where 4G, 5G etc be true packet switched technologies they would be 
> more allowing smartphones to talk directly to each other without going 
> through a base station, and would not use tunnels in the core network.
> 
> The tunnels and the ptp links to the UE are the new circuits.
> 
> Alex
> 
>> 
> 
> -- 6gip mailing list 6gip@ietf.org
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cd.lake%40surre
> y.ac.uk%7C4b8e2ee2147d4d17ff7b08d8b95f866a%7C6b902693107440aa9e21d8944
> 6a2ebb5%7C0%7C0%7C637463167213724943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> data=pcgPe7xjaWUcsk9cHeOHv%2Fv9g2QlImebWd%2FxqmPRSl0%3D&amp;reserved=0
>