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

David Lake <d.lake@surrey.ac.uk> Fri, 15 January 2021 10:50 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 768513A0A1E for <6gip@ietfa.amsl.com>; Fri, 15 Jan 2021 02:50:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_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 wOHmutCDMNiy for <6gip@ietfa.amsl.com>; Fri, 15 Jan 2021 02:50:20 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2131.outbound.protection.outlook.com [40.107.21.131]) (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 C864B3A0A1D for <6gip@ietf.org>; Fri, 15 Jan 2021 02:50:19 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C5OayP1TBeVKE12s2nxQlkK2cxSpgfxQEFLqxhRs2/yJQ4EgHpMxPsc1Mczb3VheIwN0/p2CYLzFG+yui4jUNxjY0e842rmu3ME/x7TuptPvGJDhp01z6IerHT6uFTdqpbxWkrQ342AHeMRJ4hm4MjoC/iAwKvC4yXvRhJY4NopE8h8UxJtNuf81aA2n4krAQm/dHGtcrQ5BHaD4kqXBOciqX1kWmJpFHYzoNXOaI/0vKom5zV2j+f8GeUasNsPn9C1WAH1lNMGHNI29JBXBF7JJ2eWEVFno9XuwIsKU84hh1bFUbRILTOEdnurYbcnN17/iUpx1+ptP7P/WFK4FEQ==
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=llkbRrnFedFFpudkoCei3+jEY902StG0eJLcNeej/nI=; b=QcPpCrUP65rZBo7xgTkaW+XXIUwZ9a92KDj721WnAGa4VpQsOhBC9w90ptZsDojlax8upiSC5BPxnYO64lqZlusBe03wkge0dmOsZNlysfgLajTiicP3eo64LtZq/UllgDht6fBUI/Fzcfh6S2PwfkTvN2EQzY/i7wRqrhJ+p3NjMvXHqpwv7D10xzIkyh3HnvM+1/RL0RN/SRAUeg4C9QnanC7oaNt/vYb96u8sfdPwYgTOB4ALl9V24lbUK5xFfMm74rrLBml1ZSY95CeC0c9MTZi9E2q1Q8etkYRxN55gdF9BpU8pbL312Ogmp3xJFHNTF8i0l+CPFKH+1eqLNQ==
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=llkbRrnFedFFpudkoCei3+jEY902StG0eJLcNeej/nI=; b=CWkd4JGk2+W6PcfoWsTZYEXkcxbCYacMsW1BVcz7/Y7luNMbZRB++BUUIGwk8aCv26PcQShM85cfDgaUYHsVfLGEBG7tfCRpOlt80b+Eoy4yBnPLtbHvz0D9FVzRjr7qIgOuOHkGbMzKEKvRFw5CRSYnieXgF19uZw7+RNNzf2s=
Received: from DB7PR06MB4792.eurprd06.prod.outlook.com (2603:10a6:10:57::20) by DB6PR0602MB3286.eurprd06.prod.outlook.com (2603:10a6:6:4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.8; Fri, 15 Jan 2021 10:50:16 +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 10:50:16 +0000
From: David Lake <d.lake@surrey.ac.uk>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, Rex Buddenberg <buddenbergr@gmail.com>, "6gip@ietf.org" <6gip@ietf.org>
Thread-Topic: [6gip] 6G in 3GPP?
Thread-Index: AQHW6cTp+mgrQaomnUyO1LwIdAQp3aonUboAgAAg+YCAABR0gIAAA6wAgAAEOoCAAOhHwA==
Date: Fri, 15 Jan 2021 10:50:16 +0000
Message-ID: <DB7PR06MB47925677D30E281EAEFC39A9B5A70@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>
In-Reply-To: <85a003a1-f833-ad5f-6f1f-a8e26cbc0039@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:11d:de11:b39c:3a3f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d37cca0f-2cf3-4144-a754-08d8b9435837
x-ms-traffictypediagnostic: DB6PR0602MB3286:
x-microsoft-antispam-prvs: <DB6PR0602MB3286CB98D874FF5C714A646EB5A70@DB6PR0602MB3286.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: jYKLslGyjl6ipSMILi1lpPyJiIt/NtZeIe+0Zj/UJOwad2v/c0baF2KLga/k5k6CP+ffQ5pKG7NVLuUlL7Cf8S9+Dp5Qxb5wvwx7QHYwJWnPQ32DXJVZV0q8zi+L/C2aHRRZJGwLhO1UWpjhNE8US4YCLubHskFbJWYvePUYhmHY3/BBls9MfNEs4PluoMck7kS2a69o5vyuBKmQvR2HmCBrL4pKkChjCcjZUobw4ZgDsCDnOiaOxvpazVWjN6nTRVeOXph3nrZIVZsT3YhRTk27YQOLJ1yOHkVbmg+mG3XOSgfqcR0VqMCX9LCDoQgN5PZzpCJr++bK2Jm3qlfCCFwX7m77Ll5iuq94Mti998iJNJ6ZXPk3kZactOcrdTtrVZoBffHF7Q0PWgvjm3f50yqadPTXSumzgeZyhptqxgcoIFAHtpEJXwuiKdEk2fiElgpfuTMQy+P41XSAxv0rkg==
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)(346002)(366004)(376002)(39860400002)(396003)(136003)(110136005)(786003)(2906002)(316002)(71200400001)(52536014)(83380400001)(33656002)(9686003)(966005)(45080400002)(6506007)(55016002)(66946007)(76116006)(66556008)(86362001)(64756008)(66446008)(66476007)(8936002)(8676002)(7696005)(5660300002)(53546011)(478600001)(66574015)(186003); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?LLBJLKekCfl5k+3ZaJuYgUdw7CnRFBuW8vHqmMpDRKTVoTZRhq9T0QYlI1?= =?iso-8859-1?Q?GVm1WAKbszstafbNZn0GlE1E9mQNhSnEwU2rBE1ovAjm8tl3lj45CgG65Q?= =?iso-8859-1?Q?2/+3P9nmqBuqBgp1ZPbLZLsqZhmDz6tlhAPyNtR722G+DcHgUlBDeBLwky?= =?iso-8859-1?Q?DigiwWskRMoh2SsVlHPEL90L9Rq3YAPtmy4DWFbQAWEvJuYyz4264pp58O?= =?iso-8859-1?Q?mLl+29qNjDR/+BNM4A0LVbFFaE8LR+9yIkkD5yDqCpickazsk98YUZBNFZ?= =?iso-8859-1?Q?zM82SFoGj6SXh6votlinKSAfd0/VRM2S05N4V0rqxubFkFOLaEheeHl0bl?= =?iso-8859-1?Q?F5sAIjIRAqn35eyRj/h0zI+p0PSF559qOYerN/OepMWr5r2yyB/SvDQqBM?= =?iso-8859-1?Q?D6xYhL6yiWHg0g+aQ78l5Ir0y8RoQQ9IIilWeo2VAJZSxVISDhTL8Ky260?= =?iso-8859-1?Q?aPRaduawDVlqsAcgLOQQU0YoPYu0k2S53RMyrW8ObVM65td9/Xq26+jxIr?= =?iso-8859-1?Q?pl9U6X8qyWL4pYv7Qmpl1F45f8PnkOOiOCbkJXbsg64K0BJOaNMQy1le5d?= =?iso-8859-1?Q?6lWJXVjnA1g+pv3PMLyxeSK/WKepYlkyFMNiI6qD8SOA282qLqYD038KEl?= =?iso-8859-1?Q?q7PD9YuRJsToGQgaFGW3sV8K3/2tnWDGn+s/PTj/TapXRV5sfUpXplJEyc?= =?iso-8859-1?Q?OPXT4VpsP7aEEr5Wz//aQKBTtriCiC/mYV/a9Mw/HsJKL9R0yJAuV44VNu?= =?iso-8859-1?Q?o/jukR6xU9McydKJrDF/uDbg6oLDqSUwcNomTGsQP1HLis6W6nZBt4JDAX?= =?iso-8859-1?Q?WVm6JTodgDKG+rKuLENFPvnN82ybfCbYmN6vWOPRQYaJA3jhZzREUSNagq?= =?iso-8859-1?Q?oxCYYNDytntopKnBFxV9BfFoJ6hvkaBGZ5EJvqhu8L/PIS/okMS+jN82x3?= =?iso-8859-1?Q?KDYXh0xPK5qlUrbJ44WmNoW0cbEqLj1D3pCPAeSeN3L8sU3S8LuKpVcDc8?= =?iso-8859-1?Q?jc7ZSIxfdkwG4gC2S2HF2o9wI/FPni5KZKh1+o6UO1jZEhffhbu5Rwy6+j?= =?iso-8859-1?Q?3gs7AGLyhaKnDqTMQHzTbXY=3D?=
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: d37cca0f-2cf3-4144-a754-08d8b9435837
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2021 10:50:16.6095 (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: CcgkVscQYnAoQ5Hmi82/hSVge+PrYr3pHCQIY1cqsaX02/j7n7i1ibBEX9/YVUDvb600QOCtDrNmw7TwtQS4lQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0602MB3286
Archived-At: <https://mailarchive.ietf.org/arch/msg/6gip/Q1CRGNMzyoo_LuSkzenmN6i1QWA>
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 10:50:22 -0000

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.

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

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

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


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

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.

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!


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>om>; 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%40surrey.ac.uk%7Ca235f7307bed426131cc08d8b8c87704%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462518412547053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=sI7P%2FG7xoyKI1kZZmRwIeUzpQ2DBJtD7el5kpt%2FZjDk%3D&amp;reserved=0