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

David Lake <d.lake@surrey.ac.uk> Thu, 14 January 2021 09:31 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 6E1483A1333 for <6gip@ietfa.amsl.com>; Thu, 14 Jan 2021 01:31:58 -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 IwS9UScB8KW0 for <6gip@ietfa.amsl.com>; Thu, 14 Jan 2021 01:31:56 -0800 (PST)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2129.outbound.protection.outlook.com [40.107.22.129]) (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 80E7A3A1326 for <6gip@ietf.org>; Thu, 14 Jan 2021 01:31:55 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KEPSQzWIFbw7gr0Fv4O3wqBnx4uLhzX5Mtbe87RfIH2fg+SSq2rrkYDf+KN6o01pNRpbgz1KFmQrytn0VkQcQ7toOJBEIgRDb9lXHQntFogEBTfb6jgi1v3Mzjoy78ExGPPlWl2LNQxgozaJ/ddRLSr7N94qKT7y7Agnj7UVvaMKv6xPVf/32WTp82jZZirls91q0fRhySjCfkh1NUBxD8KRWxvbvNXOUULk+U4jxPGYL2MDoIPuWK7ke594lSgnvl6lksJI+reoBrUIyrkLfIGbIAh+ce0qneMDts53d9htH34Ox7sZ/f1HnZBb8NZMitFZxBKC0jsqZaQHRytlMw==
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=RjRENmY3IwcLGM84BJ76YgOr5cnOlgkdu/Y7YNQHybg=; b=MtAIQhvdZ6dlW38PHAH0It1AfzYSb+hbGQQA124aMdvgcAa5WwfLMHa5BbuJjLBQreLpW8Nt42VwzuslJYBSQg5ofLQBL0Eu/7T8nAWN3X9+fD0cdMpMP2Kkc2qq+ir+P6SMHqh8uw9u9nxSPzTHNScinj2cPvEzg6y34mjaQba24f5saXyS8USoe4Iet1Rbo3VdQhv5/vxDvPXaOEM45eSVgXbmq0DSLZFI+JoOpC0ToERFXmj2+nRJ7DZENNk8/N2mgTxtqIDAzS+PgWcnW7M8cj133/XDDVran12F8w9zjUYxdZcPRhtruf+gqkHX/6bziQ90L844IxXKdTG+Dw==
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=RjRENmY3IwcLGM84BJ76YgOr5cnOlgkdu/Y7YNQHybg=; b=BxpMyIIC256irIUySZoSHCqk/Mo/RO3e0fXZJ9VdGZPI8w26aM34Im1yaw3ykQdeaYl2QRbYLBNlmbiInymow1CgYHuCKDducY+ZxUjikbU+oj8jehKZdCsE2xBeyVyRbk7OMlCwJUPV8PkxKS+fHYCWTyjtK2hLuBlmjZAYOxM=
Received: from DB7PR06MB4792.eurprd06.prod.outlook.com (2603:10a6:10:57::20) by DB7PR06MB4949.eurprd06.prod.outlook.com (2603:10a6:10:2a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Thu, 14 Jan 2021 09:31:36 +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; Thu, 14 Jan 2021 09:31:35 +0000
From: David Lake <d.lake@surrey.ac.uk>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "Flinck, Hannu (Nokia - FI/Espoo)" <hannu.flinck@nokia-bell-labs.com>, "6gip@ietf.org" <6gip@ietf.org>
Thread-Topic: [6gip] 6G in 3GPP?
Thread-Index: AQHW6cTp+mgrQaomnUyO1LwIdAQp3aomz5aAgAACmUA=
Date: Thu, 14 Jan 2021 09:31:35 +0000
Message-ID: <DB7PR06MB4792ACAF71AA663A61FC0398B5A80@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> <a636d487-49a7-24d6-5498-0434de1cf080@gmail.com>
In-Reply-To: <a636d487-49a7-24d6-5498-0434de1cf080@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: fb6288bb-7e85-4108-e223-08d8b86f300b
x-ms-traffictypediagnostic: DB7PR06MB4949:
x-microsoft-antispam-prvs: <DB7PR06MB494939FB3BE23BCE44432DA7B5A80@DB7PR06MB4949.eurprd06.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: s83HwO3LHCVf7gfkUj2euiTWiT2Gy8zgRNXChTB+mdq5P+9ihCggRcQPYDLFplIonE+aIfXYtamxY44FEwGHG+V5f7klGbJ6rAPc/4bjU48rdRNp0ws9KnQocRJEaq3CXKoOUWoVGkxguz5R9UFwHBwv86uNeWf0Ev02c+Eh1FZP5fYI30Ur5eqqbApQ3VmDBOuZwq+VmjpUEVmKr1hve710v4kYr47Q5mjsYT6E+JuYxnw2ktzJSFrBX7JiYQXhgIWpI0/Zgag+kXb8fn7nYGC95jTWXzcQ04zPKY42mV+vtJKDjFWTQWlUUaOzBcL88iwd4clKOvaIbHO5Agqu76IG2k3jqB7RxTVfuQKFXNxHws0Lg62h8yz10U2K8fbIDethiK/HnbT/hCGKU+2C35eOb+/FExdaCzHPBIk6FT2Tap0yZ9Iol4spDREvGJJcgGcZ78go49ZNbLtHSb4u2B/mg3ISUrb4aaAHYeqWksPT8wpsvT+b6C7NVSYhblDD2Inw5VHsKLPVXD4k/S4IbQ==
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)(136003)(366004)(396003)(346002)(376002)(39850400004)(53546011)(6506007)(45080400002)(33656002)(966005)(8676002)(5660300002)(2906002)(8936002)(110136005)(71200400001)(478600001)(186003)(7696005)(86362001)(66946007)(52536014)(66556008)(76116006)(55016002)(66446008)(64756008)(66476007)(316002)(786003)(9686003)(66574015)(83380400001)(56044004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: qN1yqyqdQx18Yh9cpGOCcLnWc5waQo4akXE1yi3GfuOTUtPYlawPEUn4wlz28uClmt3OZ+ibvkhdZLuZkRPGQvGoPHh/sMKLOBQO+3ZnJuD+i0gyWUNZK2OA8vXw4KmyLjJD7eQx9EEEJN4TyBwx+z45TI3yblrW/Y0X4GtGDb7ToZ6yqiSrwKv66WNPK5UsWKyUJmG1YzzMCwA37KK4FDRLOWutQsCBO+8wLsEo6qOxbtrc0Xis0FU8OvgN9JsPQteuKPAQZz3nJSvh5HKNewiFTPFwtYJVFA0vcS/IedugV4otbvvrri1wkmiZbg1uo0dpLUv9G4syjiV49FMcgRKSdeGyERo0lPhCTH+bWzh6cEREavFKy8X/28Z33G+rMaQOoRg8TXQnE+J7Ao9BccBxUvgbcrJBZRDLZw9it+YkwZzv7y+TAHKOPr6MYTE0VS2oByA6j1bLQX7KaFYwdipAvj7aXMeQBhT/I0lwTPOhVchVHXO/wsHxSdoxCdkpg9XIQ41nm/NmxFV7dFDzfaPQNC5vE5cHI+CJ/HFSsw75v8PzwrK76z29QQDa9UX/G0byiUdI0a57sfb5tJbGtTrLPcPlBbEDchOZBDGwZbnUXnEifNu7QZcGvTccVc/m4RwsKr+bs+JrUSZpuhQJcZBFrxS166Ctezu8f466QZtNE0yw4Nyv3FUN06HbPgYbNVpyEldl08i4LOC6Mw3iyFWegWZZkcr5p6HBKd/hTr3+VMvjA6xVH5POmiRX1cXRsEtJZ8NHJUVYJId7FXuKMcew2Lvwj8Mk6Vbk8FCdIAqsGCmhpH2oC1AbEeOvTaH1fD1IY2+QBcDLxsKWg0V9SS/+L+GZZXoY4Ua1/V8wtAyPgdu78JvyfFSOrGzgZkgcWVyLM89eWqlVf9C4UOr9QBqPFRzx3fX061dH3DV7nnU2Sq/uQWm9SCGD8IvrEkjDJ8VcHD7rJ5m4JQnvBPe7P8qcN+4dlaOxg62q4KT7+jdtBE37K+JVAlqmZGQap0k/iDYLcUa4X9A8TPOyExcylIdEWMz/8AWbzr5i8nuYu/Q=
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: fb6288bb-7e85-4108-e223-08d8b86f300b
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2021 09:31:35.8451 (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: WEvXY3JdoSAobeQNBfZBkHDv3/Fi/s2TtnUgS3ybFCeqzvdDp3XCWSa+zafIFB/VYAluoLr0oBxvTQ8ly3h3+A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR06MB4949
Archived-At: <https://mailarchive.ietf.org/arch/msg/6gip/__90_WTyiHSK-B0HpVF8fX4bKx4>
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: Thu, 14 Jan 2021 09:31:58 -0000

I think we're WAY ahead of ourselves here.

Much like 5G is primarily a marketing term, 6G falls into the same bucket.

5G has delivered a new air-interface (5GNR) and architectural developments in terms of functional placement.  Otherwise, it retains much of the basis of GPRS in terms of protocols and likewise it retains many of the problems of network delivery that we see in today's Internet.

Please excuse the slight rant, but ask any musician that has been trying to run interactive music-making in the past 10 months and they'll all ask why it doesn't work - when you're singing/playing and instrument with someone, you need roughly 2-5ms between everyone (that equates to 2-5ft distance between players) and that is from microphone to speaker so has to include the codec delay, SAR, transport.  It just isn't possible even if the players are in the same town (mostly due to the anchoring in DSL/4G meaning that even next-door-neighbours on different ISPs will have 20-30ms between them as the breakout point is in the centre of the MNO/ISP, often hundreds of miles away) - take a look at the Facebook pages of the Association of British Choral Directors, Making Music, ACAD, the European Piano Teacher Association or any of the major symphony orchestras or professional choral groups - as a semi-pro musician and an engineer, I get emails daily asking why with all the hype of 5G we still can't run ensembles of 50-100 as if they were sitting next to each other.   Answer - because we didn't build the Internet for interactive, real-time, low-latency communications with guaranteed end-to-end service delivery.  That is why broadcasters have been struggling for years to work out how to replace ISDN with IP.   We've had to plug round the problems on consumer video with CDNs which give the illusion of high-bandwidth/low-latency.  The closest we get are solutions from groups like CCRMA at Standford where the codec/SAR is optimised but this uses specialised hardware.

I think there ARE interesting things to consider in future networking/applications but I am not sure that an IETF WG (or even an IRTF RG) are the right place to do those 1) as IETF is concerned with interoperability of existing solutions and 2) IRTF works in more defined areas 3) IETF/IRTF seem not to be particularly commercially-minded (in terms of the economics of running a utility service).

Areas that I think we could consider:

1) Non-IP protocol support; much of the Internet was predicated on a small number of long-lived, large-packet flows (e.g. small numbers of consumers watching videos) which is what we have for the most-part today.   The ratio of header:payload works in terms of network/energy efficiency.  Move that to a landscape of IoT where the data comprises of small payload, short-lived but billions of devices and the question must be asked if the current header:payload ratio is appropriate.   There are then questions over energy efficiency and cost-per-bit of transport - where are the studies on that? 

2) QoE. Predominantly, Telcos are becoming pipes to the application but remain disconnected from the notion of service delivery.   Likewise, the economic model does not work in the same way as any other supply chain and consequently incentives for good delivery are not built into the overall solution.   The only exception to this is VoLTE where the OTA numerology is tightly-coupled to the network and admission-control is exact.  However, consumers are moving away from operator-provided services.    6G could address this to build a proper supply-chain and settlement system across both wired and wireline networks.  Currently, I have no SLA with any application and no ability to have one enforced yet I pay both the application provider AND the transport provider.  This is like buying a train ticket for a timed express service and being told "we don't know when you'll arrive or even if the train will run and you won't get your money back under any circumstances."

3) Consolidation of access.  Living where I do in the south-east of England, I have access to 4 MNOs all with good 4G service.  My parents-in-law live on the east coast of England with access to zero cellular networks (a village of 30 people means it is not cost-effective for all 4 to build so none do).   National roaming does not fix this problem.   They also get very poor DSL service which no planned upgrade.  Removing one MNO from me and placing it with them would make a massive difference to their lives and zero impact to mine but is commercially unacceptable.  But what is better for society in general?

None of these fall into the remit of an IETF or IRTF groups but I think would be far more valuable questions to ask at this point in the gestation of "6G."

I'd be very happy to talk about these areas at the next 6GIP meeting.

David

-----Original Message-----
From: 6gip <6gip-bounces@ietf.org> On Behalf Of Alexandre Petrescu
Sent: 14 January 2021 08:45
To: Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com>; 6gip@ietf.org
Subject: Re: [6gip] 6G in 3GPP?

Le 13/01/2021 à 16:57, Flinck, Hannu (Nokia - FI/Espoo) a écrit :
> Hello
> 
> Neither I know any, nor my colleagues any 3GPP documents about 6G.
> 
> 3GPP is currently at mid-way with 5G. There will still be a number of 
> releases left for 5G  to come. In fact, I assume that now when 5G is 
> pushing towards new verticals (mIoT, industry, vehicular, etc.) there 
> will be new requirements for protocol work needed for 5G. For example, 
> consider the discussion about multi-path support for QUIC in QUIC wg. 
> Similar requests are likely to come.

Hannu,

I do not disagree.

I think indeed 3GPP still works a lot on 5G.  I think it is good they do it.  I think 3GPP might not need an email list at IETF to design use-cases for 5G and 5G+ of 3GPP.

That is a personal oppinion and represents just one person.

> Therefore, I am on the opinion that 6G work, even 6G related protocol 
> research work in the IRTF, should wait for use cases (and radio 
> extensions) that 5G is not able to respond.

I dont think so.

I think 5G work at 3GPP is great.

Would your suggestion be that 6gip email list should wait for 3GPP to work on 6G?

There might be a problem with names, but I doubt 3GPP has a trademaark on an acronym such as "6G".  "5G" itself was in years 1980 representing the 5th Generation of Computers.  People also use routinely the term "5G" to stand for 5 Gigahertz instead of the 5th Generation of telecom.

Alex

> 
> 
> Best regards Hannu
> 
> -----Original Message----- From: Alexandre Petrescu 
> <alexandre.petrescu@gmail.com> Sent: Wednesday, January 13, 2021
> 10:40 AM To: Flinck, Hannu (Nokia - FI/Espoo) 
> <hannu.flinck@nokia-bell-labs.com>; 6gip@ietf.org Subject: Re: 6G in 
> 3GPP?
> 
> Me too I would like to ask I would like whether someone knows of a 
> document on the 3gpp.org site that has the term '6G' in it?
> 
> Le 12/01/2021 à 17:55, Flinck, Hannu (Nokia - FI/Espoo) a écrit :
>> Hello Alexandre
>> 
>> In your slides you claim the 6G is discussed in Rel 17. Can you tell 
>> in which document or WG?
>> 
>> I am involved quite a bit in 3GPP as well as in 6G research and I am 
>> not aware of any of such discussion.
>> 
>> Without a reference I must consider that statement be misinformation.
>> 
>> Best regards
>> 
>> Hannu
> 
> Thanks for having gone through the slides; the slides tried to 
> summarize the discussions on the email list at that time.
> 
> It might be that a potential reationship between 3GPP and 6G to be a 
> stretch.
> 
> I might bear responsibility of having misread the emails, or read them 
> too quickly, when drawing a conclusion that 3GPP might work on 6G, and 
> writing that down.  Sorry for misunderstanding.
> 
> We had some mention on this list of an NGMN alliance (Next Generation 
> Mobile Networks) which initiated a task force on 6G; elsewhere, NGMN 
> is ack'ed as a contributor to 3GPP by a wikipedia article.  That might 
> make it that 3GPP might have some work on 6G.
> 
> It might be that some discussions between usual contributors to 3GPP 
> might have mentioned 6G even though there might be no document on 
> 3gpp.org that reads '6G'.  For my part, I do not know what document is 
> Rel 17 more precisely, but I suspect I could find Rel 17 on 3gpp.org.
> 
> It might be that other industry alliances (e.g. 5GAA) could be 
> outright opposed to work on things deemed "6G".  It might be that such 
> opposition is supported by other funding bodies.  I do not know why 
> the opposition, but that is the way it is.
> 
> If, for some reason, 3GPP considers the talk of 6G to be too early, 
> and why not potentially disruptive to the ongoing work of 5G, then 
> that is a 3GPP problem to solve.  That would not be the only problem 
> they should address.  I suspect a ling standing problem is even the 
> name "3G" in a 3GPP working on something else than 3G (e.g. 3GPP 
> working on 4G or 5G).
> 
> I want to tell also that there might be other problems of 5G, on which 
> 3GPP works, and which deserve attention.
> 
> Such problems could be solved by working on something new, like 6G.
> 
> It is a speculation from my part.
> 
> I would like to ask others whether someone knows of a document on the 
> 3gpp.org site that has the term '6G' in it?
> 
> 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%7Ca9948f6b27da441019bc08d8b868bfc7%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462107334487697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=zCyHLsSxDHArH47eWOnMY4JkKBZxN9OaQO2t0KMnirw%3D&amp;reserved=0