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

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Tue, 12 Jan 2021 16:55:16 +0000

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jan 2021 09:40:14 +0100

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?

> Without a reference I must consider that statement be misinformation.

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jan 2021 09:47:18 +0100

> Without a reference I must consider that statement be misinformation.

It might be that it is just a question of time.

When is 3GPP going to start working on 6G?

That would help us in writing a timeline.  We already have a rough idea 
of timeline on 6G, but I am not sure how right is it.

In this speculative timeline in year 2030 the 6G will do the first 
deployments for public at large.

In year 2028 the first trial deployments outdoors.

Between 2024 and 2028 something about 5G+.

What do you think?

Or maybe a new acronym might come out and there would be no 6G as a 
successor to 5G?

Alex

---

From: Stefan Alfredsson <[email-masked]>
Date: Wed, 13 Jan 2021 09:24:07 +0000

On 2021-01-13, 09:39, "6gip on behalf of Alexandre Petrescu" <[email-masked] on behalf of [email-masked]> wrote:

6G is mentioned briefly in

ftp://ftp.3gpp.org/Information/Highlights/2020_Issue01/2020_09_3gpp_highlights01_optimized.pdf

https://www.3gpp.org/news-events/2142-ran_vid

/Stefan

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Wed, 13 Jan 2021 15:57:54 +0000

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.

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. 

Best regards
Hannu

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Wednesday, January 13, 2021 10:40 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
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?

> Without a reference I must consider that statement be misinformation.

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.

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

---

From: Kaippallimalil John <[email-masked]>
Date: Wed, 13 Jan 2021 16:24:24 +0000

Hi,
I share this view as well, and the QUIC example is a good one.

Work on 5G still has a long way to go, and there is no clear view or agreement on use cases /requirements for 6G.
It may be hard to define protocols or solutions for a problem that is not well understood.

Best Regards,
John

-----Original Message-----
From: 6gip <[email-masked]> On Behalf Of Flinck, Hannu (Nokia - FI/Espoo)
Sent: Wednesday, January 13, 2021 9:58 AM
To: Alexandre Petrescu <[email-masked]>; [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

Hello

Best regards
Hannu

-----Original Message-----
From: Alexandre Petrescu <[email-masked]>
Sent: Wednesday, January 13, 2021 10:40 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: 6G in 3GPP?

Alex

--
6gip mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C7fdd86f62b8a4531b7a308d8b7dc249f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637461503443285528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=fYapnHc1H75JcGA2Y6KRUXxD1%2B4VFcsyYmaBkf%2BkQOE%3D&amp;reserved=0

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 09:37:45 +0100

Le 13/01/2021 à 17:24, Kaippallimalil John a écrit :
> Hi, I share this view as well, and the QUIC example is a good one.
> 
> Work on 5G still has a long way to go, and there is no clear view or 
> agreement on use cases /requirements for 6G. It may be hard to
> define protocols or solutions for a problem that is not well
> understood.

In that sense, it might be appropriate to work on use-cases and
requirements for 6G.

It might be set that the bandwidth is 500Gbit/s and that RTT latency on
the air 1 micro-second.

What are the new use-cases that use that?  The tele-portation realistic
3D multi-party interacting holograms of humans using wand kinds of
evolved smartphones, transparent high resolution glasses, gloves, masks
and non-intrusive exo-squeletons with multi-sense instantaneous feedback
over very long distance might be such a use-case.

That is for the end user.

For the core network, one should consider the future 6G networks to be
access networks, mainly the wireless radio part.  The core network that
plugs into 6G should be a same flat Ethernet-based network that is
plugged into ADSL, fiber-to-the-home and space-terrestrial networks.  No
tunnels, no 3GPP-specific protocols in the core.  As much as there wont
be an all-optical networks that home network designs would like there
wont be an an all-space network and no all-6G network either.

What are the implications on IP protocols?  The addressing space of IPv6
might be sufficient, but maybe more intelligent control taking more
bandwidth could be useful.  Maybe better accommodating mobility of
users, of groups of users, and of satelites.  Maybe better accomodating
of QoS.

What are the implications on other IETF protocols?

What are the current tendencies in the 6MAN and V6OPS WGs of IETF about
the evolution of IP protocols?  There are some activities about IP and
1hop protocols, some discussion around the 64bit boundary that I am
aware of.  There are others.  Would they be good for the tele-portation
use-case satisfying end users, and for the re-pluggable core network?

Alex

> 
> Best Regards, John
> 
> 
> -----Original Message----- From: 6gip <[email-masked]> On 
> Behalf Of Flinck, Hannu (Nokia - FI/Espoo) Sent: Wednesday, January 
> 13, 2021 9:58 AM To: Alexandre Petrescu 
> <[email-masked]>; [email-masked] Subject: Re: [6gip] 6G 
> in 3GPP?
> 
> Hello
> 
> 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.
> 
> 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.
> 
> 
> Best regards Hannu
> 
> -----Original Message----- From: Alexandre Petrescu 
> <[email-masked]> Sent: Wednesday, January 13, 2021 
> 10:40 AM To: Flinck, Hannu (Nokia - FI/Espoo) 
> <[email-masked]>; [email-masked] Subject: Re: 6G in 
> 3GPP?
> 
> Thanks for having gone through the slides; the slides tried to 
> summarize the discussions on the email list at that time.
> 
> 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.
> 
> 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.
> 
> 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 [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 09:45:09 +0100

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

> 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

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Jan 2021 10:52:53 +0200

Hi,

> It might be set that the bandwidth is 500Gbit/s and that RTT latency on

that's pretty much where we are with datacenter technology today.

The limits here are due to physical constraints - the speed of light in vacuum is about 300000 km/sec. An RTT of 1us means that the maximum distance to a base station needs to be below 150m. (Not including coding overheads, etc.)

Unless you claim that "6G" will be a radio LAN, I don't think these assumptions are sensible.

Lars

---

From: David Lake <[email-masked]>
Date: Thu, 14 Jan 2021 09:31:35 +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 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: 14 January 2021 08:45
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

Le 13/01/2021 à 16:57, Flinck, Hannu (Nokia - FI/Espoo) a écrit :
> 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.

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

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

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

--
6gip mailing list
[email-masked]
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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 12:17:43 +0100

> that's pretty much where we are with datacenter technology today.

which makes think 1Gbit/s is where Ethernet on my laptop was in 2010 or 
so, and that nowadays 4G+ is not at 1Gbit/s.

maybe we would need to review the timeline and not expect 500Gbit/s in 
year 2030 (the year of first wide deployments of 6G).

Maybe this:

           bandwidth
           1Gbit/s     10Gbit/s     100Gbit/s    1Tbit/s
---------------------------------------------------------
year      2005        2010         2015         2020
Ethernet
---------------------------------------------------------
year      2010        2020         2025?        2030?
WiFi
---------------------------------------------------------
year      2025?       2030?        2035?        2040?
5G/6G

would these expectations of bandwidth in time be reasonable?

Or should we expect 500Gbit/s in year 2030?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 12:22:42 +0100

[...]

> assumptions are sensible.

I think 6G will stay separated from WiFi for a long time.  The spectrum
is separated in a fundamental way between 'licensed' and 'unlicensed';
the regulation at regulatory bodies, the fines to pay, the licenses to
pay are huge differences.

Even if 3G and 4G claimed to do some work on WiFi (there are many 3GPP
documents that claim to act on WiFi), these are still just allegations,
an dmaybe less about deployments.  5G might continue on these
allegations but the deployments will again be different.

6G might have a positive interest of not embarking on the WiFi paths,
and let it to the WiFi SDOs.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 12:33:09 +0100

> The limits here are due to physical constraints - the speed of light in vacuum is about 300000 km/sec. An RTT of 1us means that the maximum distance to a base station needs to be below 150m. (Not i…

The distance situation of base stations is not an impediment to achieve 
high bandwidths.

The presence of too many base stations was felt as a drawback also at 
the time prior to existence of mobile telephony.  But nowadays there are 
many base stations in densely populated areas, such as stadiums, markets 
and more.  Some times they might even be at a few hundred meters distance.

The choice of placing base stations is a matter of planning and 
agreements with the local Mayor or administrators of the real estate 
(oftentimes without involving the Citizen, but that's an Ethics issue).

The choice of placing base stations might also have to do with the 
technology used in that base station, and about the form of the 
landscape in the area.  It has to do with how waves propagates and reflects.

Active base stations vs intelligent reflecting surfaces, beam forming, 
and other wave propagation improvement tools will not prevent this 
efficient placement, and thus the obtention of higher bandwidths.

BEsides, there is also the parallelism principle: if 1microsecond cant 
be achieved by one light stream then it might be achieved by two 
simultaneous light streams, or 4, and so on.   If it can be achieved by 
n lighstreams then it can be achieved by m (larger than n) THz streams. 
  It seems light is in the range 400-700 THz.

Or maybe that's where 'fully optical' might join fiber to smartphones...

Alex

---

From: John Grant <[email-masked]>
Date: Thu, 14 Jan 2021 11:51:47 +0000

On 14/01/2021 09:31, David Lake wrote:
> 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.
However, IETF has nailed its colours to the IPv6 mast, so that 
conversation needs to happen elsewhere.

3GPP is beginning to talk about non-IP packet formats that will have a 
better balance, as is GSMA, also ETSI: 
https://www.etsi.org/technologies/non-ip-networking

-- 
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com

-- 
This email has been checked for viruses by AVG.
https://www.avg.com

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Jan 2021 14:07:14 +0200

On 2021-1-14, at 13:22, Alexandre Petrescu <[email-masked]> wrote:
> I think 6G will stay separated from WiFi for a long time.

That's not the point I'm trying to make. This is not about WiFi vs "6G".

The point I'm trying to make is that the "1 us" requirement you posed implicitly means you are talking about a LAN (as in local area network), due to speed-of-light limits.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Jan 2021 14:12:13 +0200

On 2021-1-14, at 13:33, Alexandre Petrescu <[email-masked]> wrote:
> The distance situation of base stations is not an impediment to achieve high bandwidths.

Of course it's not (quite the opposite).

But your "1 us" latency requirement means that your network will not be able to support longer distances, which makes it effectively a LAN.

> The presence of too many base stations was felt as a drawback also at the time prior to existence of mobile telephony.  But nowadays there are many base stations in densely populated areas, such as stadiums, markets and more.  Some times they might even be at a few hundred meters distance.

Yes, sometimes. But if you intend to prescribe a "1 us" radio RTT limit for "6G", *all* UEs must be closer than 150m to at least one base station at *all* times, due to speed-of-light.

This seems highly optimistic for a WAN. Or is your view of "6G" that of a network for urban areas only?

Lars

---

From: John Grant <[email-masked]>
Date: Thu, 14 Jan 2021 12:21:06 +0000

> The distance situation of base stations is not an impediment to 
No, but you also wanted 1 microsec latency, which is the time it takes 
light to go 300 metres.

BTW what kind of applications do you think would need latency that low?

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 14 Jan 2021 12:21:18 +0000

> On 14 Jan 2021, at 12:07, Lars Eggert <[email-masked]> wrote:
> 

You need to separate the distance from the radio technology. 1us is 300m one way, and that makes it short to medium range, which is relatively local. However the term LAN brings with a load of baggage which is out of scope.

Stewart

> 
> Lars
> -- 
> 6gip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6gip

---

From: David Lake <[email-masked]>
Date: Thu, 14 Jan 2021 12:27:36 +0000

Alex

I'm sorry, but I do have to pick you up again on this comment:

" The choice of placing base stations is a matter of planning and agreements with the local Mayor or administrators of the real estate (oftentimes without involving the Citizen, but that's an Ethics issue)."

At least in the UK, mobile phone masts are a matter of great controversy and many (in fact the majority) of planning applications are denied.  As technologists, we do not live in a cultural or political vacuum and we need to be designing solutions that are acceptable to the people that are our customers, the public, and we must be aware of that. 

No-one wants to live surrounded by masts, pylons, cables, wires - they just don't look very nice!  We're all trying to improve our natural environment.  The outcry over the 5G mast which was planned for Brighton was huge and rightly so.  The residents decided that it was much better to have a view of the sea a view of a 6-bay antenna system. 

Now, if we as engineers can design invisible systems that provide decent services, we're on to a winner. 

One thing that is obvious from this pandemic is that people want to live in rural locations more where objections are much higher and people do not want to be surrounded by metal and plastic!

David

-----Original Message-----
From: 6gip <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: 14 January 2021 11:33
To: Lars Eggert <[email-masked]>
Cc: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]; Kaippallimalil John <[email-masked]>
Subject: Re: [6gip] 6G

Le 14/01/2021 à 09:52, Lars Eggert a écrit :
> The limits here are due to physical constraints - the speed of light 
> in vacuum is about 300000 km/sec. An RTT of 1us means that the maximum 
> distance to a base station needs to be below 150m. (Not including 
> coding overheads, etc.)

The choice of placing base stations is a matter of planning and agreements with the local Mayor or administrators of the real estate (oftentimes without involving the Citizen, but that's an Ethics issue).

The choice of placing base stations might also have to do with the technology used in that base station, and about the form of the landscape in the area.  It has to do with how waves propagates and reflects.

Active base stations vs intelligent reflecting surfaces, beam forming, and other wave propagation improvement tools will not prevent this efficient placement, and thus the obtention of higher bandwidths.

BEsides, there is also the parallelism principle: if 1microsecond cant be achieved by one light stream then it might be achieved by two 
simultaneous light streams, or 4, and so on.   If it can be achieved by 
n lighstreams then it can be achieved by m (larger than n) THz streams. 
  It seems light is in the range 400-700 THz.

Alex

--
6gip mailing list
[email-masked]
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%7C019f79647dc8438fd21508d8b8803a25%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462208161999841%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=I0z%2BdCz41Mv0jo2FAtcWRsIGV91TuR8izBSD0RkJ4tM%3D&amp;reserved=0

---

From: David Lake <[email-masked]>
Date: Thu, 14 Jan 2021 12:29:00 +0000

Thanks.

IETF may have because IETF is about "here-and-now" but other parts of ISOC surely are looking ahead?  IRTF has been studying ICN for a very long time, for example...

This does underline my early comment that any talk of "6G" in IETF/IRTF is premature.

David

-----Original Message-----
From: 6gip <[email-masked]> On Behalf Of John Grant
Sent: 14 January 2021 11:52
To: [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

> 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 ques…
However, IETF has nailed its colours to the IPv6 mast, so that conversation needs to happen elsewhere.

3GPP is beginning to talk about non-IP packet formats that will have a better balance, as is GSMA, also ETSI: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Ftechnologies%2Fnon-ip-networking&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cfab36a5328974f764aec08d8b882e3c6%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462219597319629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=kXXkaJMOroDos8VmaJJfPUwVH7%2FgNSTUi%2FM%2B2lviMrU%3D&amp;reserved=0

--
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ninetiles.com%2F&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cfab36a5328974f764aec08d8b882e3c6%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462219597319629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=4qf7TICYgUdd5lkvBj2gvCLdSd%2Bvt1rxBqXTeTSx0D8%3D&amp;reserved=0

--
This email has been checked for viruses by AVG.
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avg.com%2F&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cfab36a5328974f764aec08d8b882e3c6%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462219597319629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=p5Ulo6lCyfOUhmu4EAKK345%2B1syBcaCUlTy0GaQAkF4%3D&amp;reserved=0

--
6gip mailing list
[email-masked]
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%7Cfab36a5328974f764aec08d8b882e3c6%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637462219597319629%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=aUSHHeIoaeU7ds0W1fTnHriXnyL6bPoDoSBz8TFOY54%3D&amp;reserved=0

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 13:41:20 +0100

Le 14/01/2021 à 13:07, Lars Eggert a écrit :
>> Le 14/01/2021 à 09:52, Lars Eggert a écrit : [...]
> The point I'm trying to make is that the "1 us" requirement you posed
> implicitly means you are talking about a LAN (as in local area
> network), due to speed-of-light limits.

But at one point in time LAN is LAN and 6G is 6G.

In year 2030, when 6G does 1us (micro-second) latency, maybe LAN does 
1ns (nano-second) latency.

Of course, for LAN to do 1ns there is a need for short cables and 
multiple flows of light carrying data.

So I wonder whether it is in year 2030 that 6G will achieve 1us latency, 
or later, or before?

We know 6G cant do 1us this year 2021, because nowadays 5G talks about 
1ms latency, and WiFi about 50us latency (WiFi 6E 4.9GBit/s).

We dont know something about year 2025.  Maybe in year 2025 work on 5G+ 
will have ended?

Alex

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Jan 2021 14:45:43 +0200

On 2021-1-14, at 14:41, Alexandre Petrescu <[email-masked]> wrote:
> In year 2030, when 6G does 1us (micro-second) latency, maybe LAN does 1ns (nano-second) latency.
> 
> Of course, for LAN to do 1ns there is a need for short cables and multiple flows of light carrying data.

Yes, short cables of at most 30cm, due to speed-of-light.

Multiple flows do not decrease latency, they (only) increase throughput.

Lars

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 15:07:45 +0100

> Yes, short cables of at most 30cm, due to speed-of-light.

Right, probably.

It might be that cables and fibers already (and always have) transmit
each bit at almost the speed of light, even though the bandwidths we
experienced across generations has always increased.

In that sense, maybe it is the electronics who are the culprit
preventing one from experiencing 500Gbit/s on 6G.  Maybe improving the
electronics will lead to higher bandwidths, and consequently lower
latencies.

I suspect that, as in computing, adding parallelization will set the sky
as the only limit to reducing the latency.

Of course, a zero latency couldnt be reached, but micro-seconds is still
far from 0.  A particular mantra in future networking talks about 'zero
latency' as well, but that might have to do with quantum Internet, in
the QIRG of IRTF.  Maybe another suggestion suggests data to be there
before it was even sent, which might question causality overall; but
micro-seconds latency is not questioning causality, because it is a
positive number.

> Multiple flows do not decrease latency, they (only) increase 

Hmm, but there has always been a tight relationship between bandwidth
(throughput?) and latency on the same medium.  On Ethernet, higher
bandwidth meant lower latency.  On 3G, 4G, 4G too.  On WiFi too.

Also, one parameter of throughput is the size of the data to be sent.
Distributing that data on two channels halves that size, so throughput
is increased.

With these two things I think I can reasoably assume that ping on 6G
might display micro-second latencies (RTT, round trip time)?

Or maybe hundreds of micro-seconds latency on 6G?

Or maybe milli-seconds latency on 6G?

Alex

---

From: Lars Eggert <[email-masked]>
Date: Thu, 14 Jan 2021 17:27:36 +0200

On 2021-1-14, at 16:07, Alexandre Petrescu <[email-masked]> wrote:
> each bit at almost the speed of light

Correct.

> , even though the bandwidths we

That's because throughput increased.

> bandwidth meant lower latency.  On 3G, 4G, 4G too.  On WiFi too.

The serialization component of latency goes down with increased throughput. Speed-of-light doesn't.

> Distributing that data on two channels halves that size, so throughput

Sure, but throughput is not latency.

I think you are confusing latency and transmission time (for a given amount of data.)

> might display micro-second latencies (RTT, round trip time)?

No, you can't.

Lars

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 16:30:38 +0100

>> might display micro-second latencies (RTT, round trip time)?

If I cant expect ping to report a micro-second RTT on 6G, then should I 
expect it to report a few hundred micro-seconds?

Alex

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Jan 2021 10:30:56 -0600

Hi Hannu,

> Neither I know any, nor my colleagues any 3GPP documents about 6G.
I checked our chair slides at  IETF 109 side meeting, we have no mention of
3GPP doing 6G there.

> releases left for 5G  to come.
>

This is wrong.
5G is already here. Samsung had 5G phone in 2019. Apple iPhone 12 was
introduced in 2020 with 5G.
There are deployments going on worldwide.

It seems you are confusing 3GPP Releases with 5G deployments. 5G came with
the first release that introduced 5G, I think it was Release 15.
So any operator compliant with that release claims to support 5G in its
network. In the US almost all major operators claim to have 5G.

Newer releases of course are developed as Release 16, 17, etc. They
introduce many nice features. No issues with that.
However, as far as I know the operators usually do not update their
networks with any new release that comes up.
With LTE, as far as I remember the most popular release was Release 12, (I
think)  which was the most widely deployed.

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.
>
> research work in the IRTF, should wait for use cases (and radio extensions)
> that 5G is not able to respond.
>
>
We do not have any IRTF request currently, so I can not talk about that,
IRTF is another issue.
For our list, we don't have a charter to follow. We are a mailing list,we
submitted a short description text to IESG which was approved.
So we can discuss freely all issues around 6G  mostly as they are related
to IP, hence the name 6gip.

We plan on continuing to host side meetings, continue to discuss the
developments on 6G, as we see projects are popping up all over the world.
The conferences are having 6G sessions, special or invited talks on 6G,
etc.
So the question of what is 6G is going to get clarified more and more as we
go along. If our discussions, the work people do in this list contributes
to that, even better.

I believe that one day 3GPP SA1 will start working on developing
requirements for 6G. We don't know when, maybe as someone active in 3GPP,
you can tell us.

Regards,
Behcet

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Jan 2021 10:36:16 -0600

Hi Alex,

Thank you for this mail and all subsequent ones in the thread.

I think the content could make a good draft writing down these things in
one document helps us a lot.
So we encourage people to consider that seriously.

I read Lars comments. They rightly indicate that as we get more greedy on
these requirements, we are going to hit the physical limits like speed of
light that we can not change.

Dirk & Behcet

---

From: John Grant <[email-masked]>
Date: Thu, 14 Jan 2021 17:41:08 +0000

On 14/01/2021 16:30, Behcet Sarikaya wrote:
>     of releases left for 5G  to come.
>
>
> This is wrong.
> It seems you are confusing 3GPP Releases with 5G deployments. 5G came 
> with the first release that introduced 5G, I think it was Release 15.
Release 15 was "5G phase 1" and concentrated on "New Radio". Later 
releases are (and were always planned to be) further phases of 5G, so 5G 
is not done yet.

It is planned to have three kinds of service: (1) faster mobile 
broadband (2) IoT with huge numbers of very simple and low-powered 
devices (3) "ultra-reliable low latency" supporting applications such as 
robots in factories, automated vehicles, and remote surgery. There are 
also big changes to the architecture of the mobile operators' fixed 
networks, mostly in Release 16. The first "5G" services the mobile 
operators have rolled out are basically just faster mobile broadband 
using New Radio with a 4G core.

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 14 Jan 2021 18:05:32 +0000

Alex,

If there is no 6G architecture from 3GPP how can you work on protocols to facilitate the 6G architecture? 
It seems to me that there is now ground for such work. At least there should be a use case that goes beyond 5G.

Best regards
Hannu
-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Thursday, January 14, 2021 10:45 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: 6G in 3GPP?

Hannu,

I do not disagree.

I dont think so.

Alex

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 14 Jan 2021 18:09:00 +0000

Hello Alex

This time line I agree. It matches well what I mentioned in my presentation. Doesn't it.
For 6G radio we need new spectrum... and you may count the time line from there.

Bets regards
Hannu

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: Wednesday, January 13, 2021 10:47 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: 6G in 3GPP? - timeline

That would help us in writing a timeline.  We already have a rough idea of timeline on 6G, but I am not sure how right is it.

In this speculative timeline in year 2030 the 6G will do the first deployments for public at large.

What do you think?

Or maybe a new acronym might come out and there would be no 6G as a successor to 5G?

Alex

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 14 Jan 2021 18:12:38 +0000

Hello Stefan

And it says the following:

Asked about 6G, he gave an indication that there may be a place-holding mid-generational step for 5G, before 6G is brought into standards. Stressing that 6G is currently only in the early stages of research and innovation projects, he shares his thoughts about a possible evolution path in terms of functions and a marketing marker, as 5G will remain centre stage for another two releases before 3GPP, as a Standards Organization, starts to think about 6G.

Notice this: " there may be a place-holding mid-generational step for 5G, before 6G is brought into standards ". So, we are at mid-way of 5G.

Best regards
Hannu

-----Original Message-----
From: 6gip <[email-masked]> On Behalf Of Stefan Alfredsson
Sent: Wednesday, January 13, 2021 11:24 AM
To: [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

/Stefan

---

From: "Flinck, Hannu (Nokia - FI/Espoo)" <[email-masked]>
Date: Thu, 14 Jan 2021 18:28:57 +0000

Hello Bechet

In your mail sent  19th of Now you are attaching presentations.
In Alex’ presentation, there is slide titled 6G-related efforts. In that slide the last bullet item reads “• 3GPP Release 17 talks also 6G”.

I can assure you that Rel 17 is not addressing 6G for sure. There are no SA1 study items on 6G.

Please have look at the link that Stefan Alfredsson shared. It is point to a mid-generation step to 5G. What is mid-generation in your opinion?
Isn’t it midway?

Best regards
Hannu

From: Behcet Sarikaya <[email-masked]>
Sent: Thursday, January 14, 2021 6:31 PM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>
Cc: [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

Hi Hannu,

On Wed, Jan 13, 2021 at 9:58 AM Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>> wrote:
Hello

I checked our chair slides at  IETF 109 side meeting, we have no mention of 3GPP doing 6G there.

This is wrong.
5G is already here. Samsung had 5G phone in 2019. Apple iPhone 12 was introduced in 2020 with 5G.
There are deployments going on worldwide.

It seems you are confusing 3GPP Releases with 5G deployments. 5G came with the first release that introduced 5G, I think it was Release 15.
So any operator compliant with that release claims to support 5G in its network. In the US almost all major operators claim to have 5G.

Newer releases of course are developed as Release 16, 17, etc. They introduce many nice features. No issues with that.
However, as far as I know the operators usually do not update their networks with any new release that comes up.
With LTE, as far as I remember the most popular release was Release 12, (I think)  which was the most widely deployed.

We do not have any IRTF request currently, so I can not talk about that, IRTF is another issue.
For our list, we don't have a charter to follow. We are a mailing list,we submitted a short description text to IESG which was approved.
So we can discuss freely all issues around 6G  mostly as they are related to IP, hence the name 6gip.

We plan on continuing to host side meetings, continue to discuss the developments on 6G, as we see projects are popping up all over the world. The conferences are having 6G sessions, special or invited talks on 6G, etc.
So the question of what is 6G is going to get clarified more and more as we go along. If our discussions, the work people do in this list contributes to that, even better.

I believe that one day 3GPP SA1 will start working on developing requirements for 6G. We don't know when, maybe as someone active in 3GPP, you can tell us.

Regards,
Behcet

Best regards
Hannu

-----Original Message-----
From: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 13, 2021 10:40 AM
To: Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
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<http://3gpp.org> site that has the term '6G' in it?

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<http://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<http://3gpp.org>.

I would like to ask others whether someone knows of a document on the 3gpp.org<http://3gpp.org> site that has the term '6G' in it?

Alex

--
6gip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6gip

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 14 Jan 2021 19:49:03 +0100

> 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 r…

More fundamentally, i have severe doubts that 3GPP has the expertise or desire
to attempt to redefine the wired underlay where low latency is "created"/ They
simply expect that to come from some "transport service", which AfAIK could
either be delivered by IEEE, IETF or some other SDO (in a standard fashion).
Given past decade history, my bet is on IEEE when it comes to managing wired
latency, unless IETF wakes up to the challenge. Right now, DetNet is not really
at the forefront of innovation, but rather at the knocklehead tailend of
converting TSN into MPLS and considering IP en-passant. Which isn't meant to
blame DetNet, but rather a matter of catchup from where IEEE is, and being
limited in what it can do when it can not really redefine the IP protocol
stack to better suit innovaive latency management goals.

> Please excuse the slight rant, but...

Great rant. Where where you when RFC8578 was baked ?

Would be lovely if detnet could consider working on an rfc8578bis to add
even more (such as your) details of all those use-cases we can't built with
IP today (i don't think section 2. captures what you described well, but check it
out). I also remember use cases of large-scale venue audio distribution and
accoustic beats if phase offsets couldn't be suynchronized to speed of sound
in the air between speakers (theme parks or the like..).

> 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 wit…

I wish i could say you are too negative and that i have seen a lot of what
i consider leading edge innovation to originate from IETF/IETF through work or
tracking of areas such as Multicast, LISP or MPLS and autonomic networking,
 but alas, it seems that especially these days, there is a lot more focus on rejection
politics and less on innovative standards engineering in the areas that
would need improvements to better manage latency at the network layer.

If IETF/IRTF goes back operating on innovative research and engineering principles
that has marked most of its history, i think it would be the best place to
create collaboration for research and later standardize these type of innovations. 

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

At the risk of boring everyone through repetition (i think i haven't said this
on this mailing list though): IP to me is like an ice-berg: 90% of its
deployments are below the water line in what we used to call controlled
networks, and what rfc8799 now calls "limited domains". Only 10% is 
"the Internet". SRv6 in a service provider is for example a limited domain,
as is any IP residential access into an SP.  The Internet is just one of many
 services tunneled across it.

When i get "Internet access" today at an SP that comes with IP Multicast
IPTV, that particular service itself is not part of "The Internet" service
i get. Its just multiplexed into my Internet service through the same
instance of IP. In the same way i could multiplex future better latency
managed services into what then still looks like the same old "Internet"
service to the subscriber.

Aka: IP (NOT THE INTERNET) IMHO would be perfectly capable to be expanded
into what i think we would need to better manage latency. IMHO, we just
need to think beyond rfc8200, in the same way we would have needed to
think beyond rfc8200 if lets say IP multicast wouldn't have been invented before rfc8200.

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

Good question. I know IoT folks in the IETF complaining about the
1280 minimum MTU in IPv6 though as one random dat point.

IoT with IPv6 today lives primarily through a lot of header compression
and state created for that compression. If we would get away from the
mantra that all future addresses of record have to be 128 bit there would
be a lot of more flexibility and simplification in the picture for
IoT.

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

This is actually a core point: Service providers will only offer better
than "Best Effort" IP services when they can figure out how to make
more money from this. Beside VoLTE, IP Multicast for their own IPTV
service is another example of how this mostly happens: primarily for
application services owned by the SP. The exception to this rule
are transport services such as L2VPN/L3VPN, where the QoE is not
tied to an SP application service itself.

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

Yes. that's one option. I personally find the complexity of trying to
persuade marketing people in service provider into introducing new
QoE services into "network/transport" offerings and then succeed
in wholesaling those - to be mindboggling.

IMHO the better approach is to focus on research into virtualizing
the forwarding plane of interest such that it can be programmable
by the actual customer. In the same way as 4G/5G cores are nowadays
often only a bunch of VMs/containers in edge-DCs, the actual forwarding
plane in metro-router/switches could become programmable to customers
such as "advanced-QoE-slice-operators" that are also owning/developing
the actual solutions/applications (such as interactive city-wide music).

Certainly, programmable forwarding plane to enable this, would today by
a research, not a standardization yet, but i can not think of a better
place to draw expertise from than IETF/IRTF to do this.

> 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 ze…

AFAIK, there is a lot of work on "tower virtualization/sharing"

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

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 20:42:09 +0100

Le 14/01/2021 à 19:28, Flinck, Hannu (Nokia - FI/Espoo) a écrit :
> Hello Bechet
> 
> In your mail sent  19^th of Now you are attaching presentations.
> 
> In Alex’ presentation, there is slide titled 6G-related efforts. In 
> that slide the last bullet item reads “• 3GPP Release 17 talks also 
> 6G”.

Sorry, I cant remember precisely why I said that, and I might have been
wrong.  Certainly I did not read a 3GPP Rel 17 document searching for
the 6G term in it.

I am trying to dig my email archives at that time on this email list.

I could find an email saying that 6G is not really at 3GPP but rather
'5GS' (a term which I dont udnerstand) and which was said to be Rel. 18
(not 17), and it said to be 'potentially'.  The document is
http://www.3gpp.org/ftp/tsg_sa/TSG_SA/TSGS_86/Docs/SP-191040.zip

I could find an email pointing to a Oulu Uni's 6G paper
http://jultika.oulu.fi/files/isbn9789526226842.pdf
That paper says "Meanwhile, along with 5G being deployed around the
world, 3GPP Release 17 and Release 18 would deal with
beyond-5G features."  It is the "beyond-5G" term which would have made
me think that "beyond-5G" to be 6G, and hence the bullet "3GPP Release
17 talks also 6G."  And it is a "would" and not an "is"; the extension
from "would" to "is" is entirely my error.

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" or I might have missed it.  I
suspected that people stopped working on "Beyond 4G" and worked on 4G+
and on 5G.  Then I might have assumed that the same would happen with
5G: there would be no "Beyond 5G" and whatever people call "Beyond 5G"
today to be "5G+" or "6G".

But I guess all this is not interesting and that it falls under the
umbrella of speculations.

I could rather list the terms I heard about what's happening after 5G:
5G+, 5G-and-beyond, beyond-5G, and a few others I cant remember but
surely there were more.  For me, they are too many and, coupled with the
deceiving term 'LTE' (what is 'long term'?) I think it's better to talk
simply about 6G and year 2030.

The fact that 3GPP might not want to talk about '6G' is a 3GPP aspect.
It is an aspect, not necessarily an issue or a problem, at this time.

Where 3GPP has one particular problem is in that '3G' term sticking
around after so many years.  3GPP has generated other problems in
terminology.  For example LTE-V2X, vs LTE_V2X.  It is a rather loosely
defined term and very misunderstood by many.  Another potential problem
is this: putting a CAM message on UDP on IP on a 5G wireless link
qualifies as "5G-V2X"?  Depends, and hence there are misunderstandings.
  There are many other similar problems with 3GPP terms.  Should we fix
them here?  If so, it wouldnt have any authority.

Maybe we want to discuss 3GPP terminology elsewhere, not at IETF(?)

What might influence our discussion here on this email list is _if_ 3GPP
comes up with a new term, let's say something like "SixthJee" instead of
6G, and if that term gets tract.  It's something it might have been
tried with LTE.  I think the 'LTE' term was supposed to stay the same
forever.  At that point, if 3GPP comes up with some new term for 6G that
gets used a lot, then we'd have to modify our terms here too.

> are no SA1 study items on 6G.

It is good to know.

> Please have look at the link that Stefan Alfredsson shared. It is 
> point to a mid-generation step to 5G. What is mid-generation in your 
> opinion?

Mid-generation to 5G would be 4.5G?

Mid-generation to 6G would be 5.5G?

> Isn’t it midway?

Midway is an island in the Pacific? :-)

I will reply to Stefan Alfredsson separately.

Another question would be also what do the smartphones display next to
the 5 increasing bars indicating signal quality?  As I know them, they
are like this:
(nothing), 2G, GPRS, 3G, H, H+, 4G,  4G+, 5G.
(I never sa 5G myself, but I guess it would be so)

I did not see 2.5G, 3.5G or 4.5G even if some people do talk about it.

Also, I think the H, H+ and GPRS display texts near the 5 signal quality
bars are errors from the past that would not be replicated in the future.

Alex

> 
> Best regards
> 
> Hannu
> 
> *From:*Behcet Sarikaya <[email-masked]> *Sent:* Thursday, 
> January 14, 2021 6:31 PM *To:* Flinck, Hannu (Nokia - FI/Espoo) 
> <[email-masked]> *Cc:* [email-masked] *Subject:*
> Re: [6gip] 6G in 3GPP?
> 
> Hi Hannu,
> 
> On Wed, Jan 13, 2021 at 9:58 AM Flinck, Hannu (Nokia - FI/Espoo) 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> Hello
> 
> It seems you are confusing 3GPP Releases with 5G deployments. 5G
> came with the first release that introduced 5G, I think it was
> Release 15.
> 
> So any operator compliant with that release claims to support 5G in 
> its network. In the US almost all major operators claim to have 5G.
> 
> With LTE, as far as I remember the most popular release was Release 
> 12, (I think)  which was the most widely deployed.
> 
> 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.
> 
> For our list, we don't have a charter to follow. We are a mailing 
> list,we submitted a short description text to IESG which was 
> approved.
> 
> developments on 6G, as we see projects are popping up all over the 
> world. The conferences are having 6G sessions, special or invited 
> talks on 6G, etc.
> 
> So the question of what is 6G is going to get clarified more and
> more as we go along. If our discussions, the work people do in this
> list contributes to that, even better.
> 
> requirements for 6G. We don't know when, maybe as someone active in 
> 3GPP, you can tell us.
> 
> Regards,
> 
> Behcet
> 
> 
> Best regards Hannu
> 
> <[email-masked] <mailto:[email-masked]>>
>  Sent: Wednesday, January 13, 2021 10:40 AM To: Flinck, Hannu (Nokia
> - FI/Espoo) <[email-masked] 
> <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]> Subject: Re: 6G in 3GPP?
> 
> document on the 3gpp.org <http://3gpp.org> site that has the term 
> '6G' in it?
> 
> 3gpp.org <http://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 <http://3gpp.org>.
> 
> the 3gpp.org <http://3gpp.org> site that has the term '6G' in it?
> 
> Alex
> 
> -- 6gip mailing list [email-masked] <mailto:[email-masked]> 
> <https://www.ietf.org/mailman/listinfo/6gip>
> 
>

---

From: Rex Buddenberg <[email-masked]>
Date: Thu, 14 Jan 2021 11:55:18 -0800

On Thu, 2021-01-14 at 20:42 +0100, Alexandre Petrescu wrote:
> 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.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 21:06:35 +0100

DAvid,

let me clarify,

Le 14/01/2021 à 13:27, David Lake a écrit :
> " The choice of placing base stations is a matter of planning and 
>  (oftentimes without involving the Citizen, but that's an Ethics 
> issue)."
> 
> At least in the UK, mobile phone masts are a matter of great 
> controversy and many (in fact the majority) of planning applications
>  are denied.

I can agree.  I remember indeed many people oppose "antennes", as they
are called here.

But earlier, they were not opposing specific terms like 3G or 4G.  I
cant remember people having anger against the '3G' or '4G' terms like
they have now against this '5G' term.

That might illustrate the success of the '5G' term over the earlier 3G
and 4G terms, or it might represent a big risk in its deployment.  We'll
see.

> As technologists, we do not live in a cultural or political vacuum 
> and we need to be designing solutions that are acceptable to the 
> people that are our customers, the public, and we must be aware of 
> that.

I agree.

Alex

> 
> No-one wants to live surrounded by masts, pylons, cables, wires - 
> they just don't look very nice!  We're all trying to improve our 
> natural environment.  The outcry over the 5G mast which was planned 
> for Brighton was huge and rightly so.  The residents decided that it
>  was much better to have a view of the sea a view of a 6-bay antenna
>  system.
> 
> One thing that is obvious from this pandemic is that people want to 
> live in rural locations more where objections are much higher and 
> people do not want to be surrounded by metal and plastic!
> 
> David
> 
> 
> Behalf Of Alexandre Petrescu Sent: 14 January 2021 11:33 To: Lars 
> Eggert <[email-masked]> Cc: Flinck, Hannu (Nokia - FI/Espoo) 
> <[email-masked]>; [email-masked]; Kaippallimalil 
> John <[email-masked]> Subject: Re: [6gip] 6G
> 
> 
> 
>> The limits here are due to physical constraints - the speed of 
>> light in vacuum is about 300000 km/sec. An RTT of 1us means that 
>> the maximum distance to a base station needs to be below 150m. (Not
>> including coding overheads, etc.)
> 
> the time prior to existence of mobile telephony.  But nowadays there
> are many base stations in densely populated areas, such as stadiums,
> markets and more.  Some times they might even be at a few hundred
> meters distance.
> 
> Active base stations vs intelligent reflecting surfaces, beam 
> forming, and other wave propagation improvement tools will not 
> prevent this efficient placement, and thus the obtention of higher 
> bandwidths.
> 
> BEsides, there is also the parallelism principle: if 1microsecond 
> cant be achieved by one light stream then it might be achieved by
> two simultaneous light streams, or 4, and so on.   If it can be
> achieved by n lighstreams then it can be achieved by m (larger than
> n) THz streams. It seems light is in the range 400-700 THz.
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 14 Jan 2021 21:10:25 +0100

Le 14/01/2021 à 20:55, Rex Buddenberg a écrit :
>> 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"
> 
> 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

---

From: David Lake <[email-masked]>
Date: Fri, 15 Jan 2021 10:50:16 +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 <[email-masked]> On Behalf Of Alexandre Petrescu
Sent: 14 January 2021 20:10
To: Rex Buddenberg <[email-masked]>; [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

Le 14/01/2021 à 20:55, Rex Buddenberg a écrit :
> 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.

Alex

--
6gip mailing list
[email-masked]
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

---

From: David Lake <[email-masked]>
Date: Fri, 15 Jan 2021 11:26:12 +0000

Toerless (and all)

(Sorry about the rant - I'm a frustrated musician and another long-ish email follows):

In fact, yesterday afternoon I was duetting with a friend 20 miles away (two pianos - Richard Rodney Bennett's Four Piece Suite for two pianos).  My playing partner, Louise, is in Reigate; I'm in Crawley.   That's about 10 miles. Her DSL provider is TalkTalk, mine is Zen.   RTTs directly between us vary from 20 to 50ms.  Ugh.

We both have 67Mbit/s DSL "services" - the bandwidth we want to use is 510kbit/s...   

We're using JackTrip (RaspberryPI with HiFiBerry and direct wired Ethernet connections - WiFi is so compromised that it is unusable).   It is MUCH better for us to use a common shared server in London (~9ms each) as the rendezvous point than it is to go point-to-point.   We're getting air-to-air latency of between 18 and 22ms (that is sound going in to microphone at one end, coming out at the other into headphones - btw that is VERY good compared to PC ADC/DAC which can be 5-10ms alone before packetisation).

That isn't good enough.  If we had two pianos in the same room, the maximum we would hit would be about 6ms and even that can be difficult (10ms = 10ft in free air) and the last thing you want is any variation in the latency - that throws ensemble playing (especially in fast passages). 

So, what I'd like to be able to do is contact my and her ISP and say "for all the packets involved in our music, guarantee that they will arrive 6ms after they are sent."   Detnet on speed, if you will... (I'll take a look at Detnet now!!!!)

You can't.  We don't have the mechanism in any part of the public Internet (bar VoLTE) to do that. 

Your point about "IP" is EXACT - I don't actually care about how the bits are arranged on the wire in any way.  What I care about is that my service is delivered in the way that I want and pay for and that I have the ability to define a required outcome.  There is nothing on today's public network that allows me to associate value with my application and have that delivered end-to-end.  I do worry that transporting my room thermometer data (2 bytes sent every minute) over cellular involves at least 4 sets of IP headers and a GTP tunnel.   That seems like a VERY bad information:overhead ratio - I wonder what the cost of processing each bit is in terms of power, minerals, production costs, shipping costs, etc...

You make a VERY interesting point here:

"IMHO the better approach is to focus on research into virtualizing the forwarding plane of interest such that it can be programmable by the actual customer. In the same way as 4G/5G cores are nowadays often only a bunch of VMs/containers in edge-DCs, the actual forwarding plane in metro-router/switches could become programmable to customers such as "advanced-QoE-slice-operators" that are also owning/developing the actual solutions/applications (such as interactive city-wide music)."

Good idea, but I'm not sure as a consumer I have enough of a view into the network to be able to do that.   Given that we have 150+ ISPs plus 25+ M(v)NOs, the complexity involved in brokering a QoE between any multiple end-points is vast.  We did a quick straw poll of one of my choirs recently - we have 140 members all within a 20 mile radius and there are over 40 different ISPs in use, each with their own anchor points.  My packets travel about 140 miles north to break out - my next door neighbour on a different ISP travel about 100 miles west.  The only common point between them despite his house being 30ft away is via an IXP.   I think we've made the Internet SO disjointed that trying to do anything other than ship packets from interface to interface is very difficult (or as you correctly say very high-level MPLS-TE paths between SPs).  Not that we shouldn't try and solve it - in fact I think if we were to try to build a proper supply-chain model it would be fundamental that we associate value/contract/outcome.  This is as-much an economic problem as it is an engineering problem but like you I see little appetite I the IETF at the moment to look at the Internet in these terms.

So my question is if we couldn't abstract the totality of network, application, service to a broker and set contracts through the broker.   And I think given that this is a commercial service we HAVE to think about how people make money and how the transaction is settled including penalties for non-delivery against the SLA.    But we still hit the same anchored-architecture issues and that doesn't change in 5G because it is still the same technology as GPRS in the core.

To my mind if "6G" is anything it is the ability to stop thinking about the access method and start thinking about service delivery. 

BTW, I'm using my trivial music pursuits as an example - project this to the issue of real-time interactive education on-line and you can see why it is of societal interest (or at least should be IMvHO).

David

-----Original Message-----
From: Toerless Eckert <[email-masked]> 
Sent: 14 January 2021 18:49
To: Lake, David (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: Alexandre Petrescu <[email-masked]>; Flinck, Hannu (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

> 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 r…

More fundamentally, i have severe doubts that 3GPP has the expertise or desire to attempt to redefine the wired underlay where low latency is "created"/ They simply expect that to come from some "transport service", which AfAIK could either be delivered by IEEE, IETF or some other SDO (in a standard fashion).
Given past decade history, my bet is on IEEE when it comes to managing wired latency, unless IETF wakes up to the challenge. Right now, DetNet is not really at the forefront of innovation, but rather at the knocklehead tailend of converting TSN into MPLS and considering IP en-passant. Which isn't meant to blame DetNet, but rather a matter of catchup from where IEEE is, and being limited in what it can do when it can not really redefine the IP protocol stack to better suit innovaive latency management goals.

Would be lovely if detnet could consider working on an rfc8578bis to add even more (such as your) details of all those use-cases we can't built with IP today (i don't think section 2. captures what you described well, but check it out). I also remember use cases of large-scale venue audio distribution and accoustic beats if phase offsets couldn't be suynchronized to speed of sound in the air between speakers (theme parks or the like..).

> 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 wit…

I wish i could say you are too negative and that i have seen a lot of what i consider leading edge innovation to originate from IETF/IETF through work or tracking of areas such as Multicast, LISP or MPLS and autonomic networking,  but alas, it seems that especially these days, there is a lot more focus on rejection politics and less on innovative standards engineering in the areas that would need improvements to better manage latency at the network layer.

If IETF/IRTF goes back operating on innovative research and engineering principles that has marked most of its history, i think it would be the best place to create collaboration for research and later standardize these type of innovations. 

> 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 m…

At the risk of boring everyone through repetition (i think i haven't said this on this mailing list though): IP to me is like an ice-berg: 90% of its deployments are below the water line in what we used to call controlled networks, and what rfc8799 now calls "limited domains". Only 10% is "the Internet". SRv6 in a service provider is for example a limited domain, as is any IP residential access into an SP.  The Internet is just one of many  services tunneled across it.

When i get "Internet access" today at an SP that comes with IP Multicast IPTV, that particular service itself is not part of "The Internet" service i get. Its just multiplexed into my Internet service through the same instance of IP. In the same way i could multiplex future better latency managed services into what then still looks like the same old "Internet"
service to the subscriber.

Aka: IP (NOT THE INTERNET) IMHO would be perfectly capable to be expanded into what i think we would need to better manage latency. IMHO, we just need to think beyond rfc8200, in the same way we would have needed to think beyond rfc8200 if lets say IP multicast wouldn't have been invented before rfc8200.

IoT with IPv6 today lives primarily through a lot of header compression and state created for that compression. If we would get away from the mantra that all future addresses of record have to be 128 bit there would be a lot of more flexibility and simplification in the picture for IoT.

> 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…

This is actually a core point: Service providers will only offer better than "Best Effort" IP services when they can figure out how to make more money from this. Beside VoLTE, IP Multicast for their own IPTV service is another example of how this mostly happens: primarily for application services owned by the SP. The exception to this rule are transport services such as L2VPN/L3VPN, where the QoE is not tied to an SP application service itself.

>   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 enfor…

Yes. that's one option. I personally find the complexity of trying to persuade marketing people in service provider into introducing new QoE services into "network/transport" offerings and then succeed in wholesaling those - to be mindboggling.

IMHO the better approach is to focus on research into virtualizing the forwarding plane of interest such that it can be programmable by the actual customer. In the same way as 4G/5G cores are nowadays often only a bunch of VMs/containers in edge-DCs, the actual forwarding plane in metro-router/switches could become programmable to customers such as "advanced-QoE-slice-operators" that are also owning/developing the actual solutions/applications (such as interactive city-wide music).

Certainly, programmable forwarding plane to enable this, would today by a research, not a standardization yet, but i can not think of a better place to draw expertise from than IETF/IRTF to do this.

Cheers
    Toerless

> To: Flinck, Hannu (Nokia - FI/Espoo) 
> <[email-masked]>; [email-masked]
> > example, consider the discussion about multi-path support for QUIC in QUIC wg.
> > radio
> > is Rel 17 more precisely, but I suspect I could find Rel 17 on 3gpp.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%7Ca3cd5fe4075e416ff7ea08d8b8bd18a6%7C6b902693107440aa9e21d8944
> 6a2ebb5%7C0%7C0%7C637462469605680996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data=QxWzKRpbv9dBLuZHYHBHEfRNBoAc%2FyA6496ZaA75ujw%3D&amp;reserved=0
> 
> --
> 6gip mailing list
> [email-masked]
> 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%7Ca3cd5fe4075e416ff7ea08d8b8bd18a6%7C6b902693107440aa9e21d8944
> 6a2ebb5%7C0%7C0%7C637462469605680996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;s
> data=QxWzKRpbv9dBLuZHYHBHEfRNBoAc%2FyA6496ZaA75ujw%3D&amp;reserved=0

--
---
[email-masked]

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 15 Jan 2021 12:38:59 +0000

David

This is a real use case. People can argue about the economics, but the inability of the existing Internet as it is deployed to deliver this real service requirement is well stated in your note. If you had stated this a year ago, this would have been considered ultra niche, but like many things the pandemic has changed the way we live work and play, and I am sure that if this service was available there would be many other uses, but those uses are currently suppressed because people simply think it is not possible.

Why not write this up as an ID, even an RFC if there are other cases, so it is on record as a referenceable requirement.

- Stewart

> On 15 Jan 2021, at 11:26, David Lake <d.lake=[email-masked]> wrote:
> 
> Toerless (and all)
>

---

From: John Grant <[email-masked]>
Date: Fri, 15 Jan 2021 13:00:56 +0000

> 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 mea…
Not sure about that; it should be possible to have a rather more 
distributed control of routing, though probably not with IP networks.

Re the two pianos, were you using RTP/UDP? Some time ago I came across 
someone who was putting the audio data in Ping packets and got much 
lower latency. Speed of light is only one of many contributors to 
latency; see also https://lola.conts.it/

---

From: David Lake <[email-masked]>
Date: Fri, 15 Jan 2021 13:29:50 +0000

Point 1 - Yes, but the difference between the controller in a cellular network and distributed control of routing (as we currently do) is that cellular network also admits/denies services and maintains quality/outcome.

Despite having tried for decades we've failed to build any sort of admission control into the Internet which is fine all the time you just carry on over-providing bandwidth but I think the wheels have come off that truck and we now need to carefully and efficiently manage every element.  I don't NEED 1Gbit/s - what I need is 510kbit/s but I need it guaranteed between any x points when I need it - there ought to be a construct where I can buy that service and then have the various actors compensated for doing exactly that.

Point 2 - Yes.   JackTrip uses UDP (although not RDP).   JackTrip uses raw PCM in UDP with buffer sizes configurable as low as 20 Bytes.    The whole issue of Network Music Performance is a very hot-topic in audio engineering as you can probably imagine.

The maximum figure that musicians can cope with in terms of real latency (called the M2E "Mouth to Ear" in other words the total delay between making a sound at one end and hearing it at the other) is 24ms.    This is considerably lower that humans can manage for speech is about 100ms.   It makes for interesting issues - USB, for example, only polls every 1ms so if you have a USB connected mic and speak, that could be 2-4ms of your budget lost already.  DACs can add as much as 5ms.  That is 14ms lost before you've even put the packet on the wire.

One "technique" that much of the current NMP software uses to get round the issues of packet loss is exactly what we'd rather they didn't - send the packet more than once! 

David

-----Original Message----- 
From: 6gip <[email-masked]> On Behalf Of John Grant
Sent: 15 January 2021 13:01
To: [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

> 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 mea…
Not sure about that; it should be possible to have a rather more distributed control of routing, though probably not with IP networks.

Re the two pianos, were you using RTP/UDP? Some time ago I came across someone who was putting the audio data in Ping packets and got much lower latency. Speed of light is only one of many contributors to latency; see also https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flola.conts.it%2F&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cd309a70a506440a2a70908d8b955a9cf%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637463124860235172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=6M3N7A169qspoLjkda25qKmGTfCeexVEUcU2VUahMag%3D&amp;reserved=0

--
John Grant
Nine Tiles, Cambridge, England
+44 1223 862599 and +44 1223 511455
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Ftechnologies%2Fnon-ip-networking&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cd309a70a506440a2a70908d8b955a9cf%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637463124860245159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=F3UpyD0kgE4HKKNe5mYNtRUZ%2B98DsZUL5Pu3DrrpbXM%3D&amp;reserved=0
https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ninetiles.com%2F&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cd309a70a506440a2a70908d8b955a9cf%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637463124860245159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=BKNdDS3nxNEibPgRj9vSoBFSwVq%2Boc0YyOuSUVMSANs%3D&amp;reserved=0

--
This email has been checked for viruses by AVG.
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avg.com%2F&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Cd309a70a506440a2a70908d8b955a9cf%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637463124860245159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=pSprOsQMDrZRBifwvMuyriqWfoO0sCIoEeatjCLFEnE%3D&amp;reserved=0

--
6gip mailing list
[email-masked]
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%7Cd309a70a506440a2a70908d8b955a9cf%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637463124860245159%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=ebdHN0Zm1KujKMHF5NFsphhSOAtJqDdgbOMvghaaMl8%3D&amp;reserved=0

---

From: David Lake <[email-masked]>
Date: Fri, 15 Jan 2021 13:39:02 +0000

Stewart

Great idea - I shall do so.

I'm actually in the process of writing two papers about exactly this problem for two other groups:

- Making Music; the UK body that represents Amateur Music Making.  They represent the 2.5 million people who take part per-week in some kind of amateur music making in the country.
- ABCD, the Association of British Choral Directors, the body that represents both amateur and professional choirs across the UK for their peer-reviewed journal Choral Research Directions.

What I've noticed in the course of the pandemic is a fundamental shift in how we are using the Internet - pre-pandemic it was mostly to consume content (TV, media, etc).  During pandemic it has been to interact with people in real-time which current technology does do particularly well as I'm sure we all witness daily...

David

-----Original Message-----
From: Stewart Bryant <[email-masked]> 
Sent: 15 January 2021 12:39
To: Lake, David (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: Stewart Bryant <[email-masked]>; Toerless Eckert <[email-masked]>; [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

David

- Stewart

> Cc: Alexandre Petrescu <[email-masked]>; Flinck, Hannu 
> (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
> ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cd.lake%40surrey.ac.uk%7Ca65df5d9208e4e8c4c9c08d8b952a23d%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637463111853058334%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=8DZAk6UEZdQG0QEBN%2FsVRdAfejYMB31yHI%2FB2opsN0U%3D&amp;reserved=0

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jan 2021 14:58:16 +0100

Le 15/01/2021 à 14:39, David Lake a écrit :
> - Making Music;

Making music is a good example that illustrates the need of latency
criteria when evaluating communication systems.  I remember a virtual
piano was among the first tools to talk about below 10ms latencies in
MIDI systems to guarantee a feel to the user akin to that of a real piano.

Such latency in interactions through data networks can also be
illustrated by tele-operated driving use-cases for cars: the operator
should have a feeling of immediacy between the movement of a joystick
and the image of a car moving as displayed by a screen.  This involves a
number of latencies in the network (sending the command but also
receiving the video feed).

Another vehicle use-case is the following: to enjoy more the image of
one's automobile one would like it displayed in real-time on one's
dashboard; the image of the automobile should be captured by cameras
along the road and sent to the automobile instanteously.  So when the
driver turns right immediately the image of the dashboard displayed car
turns right.  That might enhance the pleasure of driving.

To a more complete picture, one might imagine a tele-presence, or
immersion, by using more capturing devices (not just a joystick or a
piano keyboard, but also a glove, a helmet, an exoscquelette, a haptic
surface, and many more) and more preojection devices (not just a screen,
but maybe a digital twin in a doublerobotics.com device and more).
There is a case of a virtual meeting with multiple parties, in which the
parties couldnt make a difference between that meeting being virtual or
real.

To make it real for the end user, the use of a latency criterion is
important.

> the UK body that represents Amateur Music Making. They represent the
> 2.5 million people who take part per-week in some kind of amateur
> music making in the country. - ABCD, the Association of British
> Choral Directors, the body that represents both amateur and
> professional choirs across the UK for their peer-reviewed journal
> Choral Research Directions.
> 
> What I've noticed in the course of the pandemic is a fundamental 
> shift in how we are using the Internet - pre-pandemic it was mostly 
> to consume content (TV, media, etc).  During pandemic it has been to
>  interact with people in real-time which current technology does do 
> particularly well as I'm sure we all witness daily...

I think the Internet use during pandemic might have growned somehow, be
it interactive or pure consumption, together.

The real-time interactions have been augmented; this can be noticed by
the large number of new tools for visioconferencing, like Google Meet,
but a full list I maintain.  Some offer better latencies than others.

Alex

> 
> David
> 
> -----Original Message----- From: Stewart Bryant 
> <[email-masked]> Sent: 15 January 2021 12:39 To: Lake, 
> David (PG/R - Elec Electronic Eng) <[email-masked]> Cc: Stewart
>  Bryant <[email-masked]>; Toerless Eckert <[email-masked]>;
>  [email-masked] Subject: Re: [6gip] 6G in 3GPP?
> 
> David
> 
> This is a real use case. People can argue about the economics, but 
> the inability of the existing Internet as it is deployed to deliver 
> this real service requirement is well stated in your note. If you had
> stated this a year ago, this would have been considered ultra niche,
> but like many things the pandemic has changed the way we live work
> and play, and I am sure that if this service was available there
> would be many other uses, but those uses are currently suppressed
> because people simply think it is not possible.
> 
> Why not write this up as an ID, even an RFC if there are other cases,
> so it is on record as a referenceable requirement.
> 
> - Stewart
> 
> 
> 
>> On 15 Jan 2021, at 11:26, David Lake 
>> <d.lake=[email-masked]> wrote:
>> 
>> Toerless (and all)
>> 
>> In fact, yesterday afternoon I was duetting with a friend 20 miles
>>  away (two pianos - Richard Rodney Bennett's Four Piece Suite for 
>> two pianos).  My playing partner, Louise, is in Reigate; I'm in 
>> Crawley.   That's about 10 miles. Her DSL provider is TalkTalk, 
>> mine is Zen.   RTTs directly between us vary from 20 to 50ms. Ugh.
>> 
>> We're using JackTrip (RaspberryPI with HiFiBerry and direct wired 
>> Ethernet connections - WiFi is so compromised that it is unusable).
>> It is MUCH better for us to use a common shared server in London
>> (~9ms each) as the rendezvous point than it is to go 
>> point-to-point.   We're getting air-to-air latency of between 18 
>> and 22ms (that is sound going in to microphone at one end, coming 
>> out at the other into headphones - btw that is VERY good compared 
>> to PC ADC/DAC which can be 5-10ms alone before packetisation).
>> 
>> That isn't good enough.  If we had two pianos in the same room, the
>> maximum we would hit would be about 6ms and even that can be 
>> difficult (10ms = 10ft in free air) and the last thing you want is
>>  any variation in the latency - that throws ensemble playing 
>> (especially in fast passages).
>> 
>> So, what I'd like to be able to do is contact my and her ISP and 
>> say "for all the packets involved in our music, guarantee that they
>> will arrive 6ms after they are sent."   Detnet on speed, if you
>> will... (I'll take a look at Detnet now!!!!)
>> 
>> Your point about "IP" is EXACT - I don't actually care about how 
>> the bits are arranged on the wire in any way.  What I care about is
>> that my service is delivered in the way that I want and pay for and
>> that I have the ability to define a required outcome.  There is
>> nothing on today's public network that allows me to associate value
>> with my application and have that delivered end-to-end.  I do worry
>> that transporting my room thermometer data (2 bytes sent every
>> minute) over cellular involves at least 4 sets of IP headers and a
>> GTP tunnel.   That seems like a VERY bad information:overhead ratio
>> - I wonder what the cost of processing each bit is in terms of
>> power, minerals, production costs, shipping costs, etc...
>> 
>> "IMHO the better approach is to focus on research into virtualizing
>> often only a bunch of VMs/containers in edge-DCs, the actual
>> forwarding plane in metro-router/switches could become programmable
>> to customers such as "advanced-QoE-slice-operators" that are also
>> owning/developing the actual solutions/applications (such as
>> interactive city-wide music)."
>> 
>> Good idea, but I'm not sure as a consumer I have enough of a view 
>> into the network to be able to do that.   Given that we have 150+ 
>> ISPs plus 25+ M(v)NOs, the complexity involved in brokering a QoE 
>> between any multiple end-points is vast.  We did a quick straw poll
>> of one of my choirs recently - we have 140 members all within a 20
>> mile radius and there are over 40 different ISPs in use, each with
>> their own anchor points.  My packets travel about 140 miles north
>> to break out - my next door neighbour on a different ISP travel
>> about 100 miles west.  The only common point between them despite
>> his house being 30ft away is via an IXP.   I think we've made the
>> Internet SO disjointed that trying to do anything other than ship
>> packets from interface to interface is very difficult (or as you
>> correctly say very high-level MPLS-TE paths between SPs). Not that
>> we shouldn't try and solve it - in fact I think if we were to try
>> to build a proper supply-chain model it would be fundamental that
>> we associate value/contract/outcome.  This is as-much an economic
>> problem as it is an engineering problem but like you I see little
>> appetite I the IETF at the moment to look at the Internet in these
>> terms.
>> 
>> So my question is if we couldn't abstract the totality of network,
>>  application, service to a broker and set contracts through the 
>> broker.   And I think given that this is a commercial service we 
>> HAVE to think about how people make money and how the transaction 
>> is settled including penalties for non-delivery against the SLA. 
>> But we still hit the same anchored-architecture issues and that 
>> doesn't change in 5G because it is still the same technology as 
>> GPRS in the core.
>> 
>> To my mind if "6G" is anything it is the ability to stop thinking 
>> about the access method and start thinking about service delivery.
>> 
>> BTW, I'm using my trivial music pursuits as an example - project 
>> this to the issue of real-time interactive education on-line and 
>> you can see why it is of societal interest (or at least should be 
>> IMvHO).
>> 
>> David
>> 
>> -----Original Message----- From: Toerless Eckert <[email-masked]> 
>> Sent: 14 January 2021 18:49 To: Lake, David (PG/R - Elec Electronic
>> Eng) <[email-masked]> Cc: Alexandre Petrescu 
>> <[email-masked]>; Flinck, Hannu (Nokia - FI/Espoo) 
>> <[email-masked]>; [email-masked] Subject: Re: 
>> [6gip] 6G in 3GPP?
>> 
>>> 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.
>> 
>> More fundamentally, i have severe doubts that 3GPP has the 
>> expertise or desire to attempt to redefine the wired underlay where
>> low latency is "created"/ They simply expect that to come from some
>> "transport service", which AfAIK could either be delivered by IEEE,
>> IETF or some other SDO (in a standard fashion). Given past decade
>> history, my bet is on IEEE when it comes to managing wired latency,
>> unless IETF wakes up to the challenge. Right now, DetNet is not
>> really at the forefront of innovation, but rather at the
>> knocklehead tailend of converting TSN into MPLS and considering IP
>> en-passant. Which isn't meant to blame DetNet, but rather a matter
>> of catchup from where IEEE is, and being limited in what it can do
>> when it can not really redefine the IP protocol stack to better
>> suit innovaive latency management goals.
>> 
>> Would be lovely if detnet could consider working on an rfc8578bis 
>> to add even more (such as your) details of all those use-cases we 
>> can't built with IP today (i don't think section 2. captures what 
>> you described well, but check it out). I also remember use cases of
>> large-scale venue audio distribution and accoustic beats if phase
>> offsets couldn't be suynchronized to speed of sound in the air
>> between speakers (theme parks or the like..).
>> 
>>> 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).
>> 
>> I wish i could say you are too negative and that i have seen a lot
>>  of what i consider leading edge innovation to originate from 
>> IETF/IETF through work or tracking of areas such as Multicast, LISP
>> or MPLS and autonomic networking,  but alas, it seems that 
>> especially these days, there is a lot more focus on rejection 
>> politics and less on innovative standards engineering in the areas
>>  that would need improvements to better manage latency at the 
>> network layer.
>> 
>> If IETF/IRTF goes back operating on innovative research and 
>> engineering principles that has marked most of its history, i think
>> it would be the best place to create collaboration for research and
>> later standardize these type of innovations.
>> 
>>> 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.
>> 
>> At the risk of boring everyone through repetition (i think i 
>> haven't said this on this mailing list though): IP to me is like an
>> ice-berg: 90% of its deployments are below the water line in what
>> we used to call controlled networks, and what rfc8799 now calls
>> "limited domains". Only 10% is "the Internet". SRv6 in a service
>> provider is for example a limited domain, as is any IP residential
>> access into an SP.  The Internet is just one of many services
>> tunneled across it.
>> 
>> When i get "Internet access" today at an SP that comes with IP 
>> Multicast IPTV, that particular service itself is not part of "The
>>  Internet" service i get. Its just multiplexed into my Internet 
>> service through the same instance of IP. In the same way i could 
>> multiplex future better latency managed services into what then 
>> still looks like the same old "Internet" service to the 
>> subscriber.
>> 
>> Aka: IP (NOT THE INTERNET) IMHO would be perfectly capable to be 
>> expanded into what i think we would need to better manage latency.
>>  IMHO, we just need to think beyond rfc8200, in the same way we 
>> would have needed to think beyond rfc8200 if lets say IP multicast
>>  wouldn't have been invented before rfc8200.
>> 
>>> 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?
>> 
>> IoT with IPv6 today lives primarily through a lot of header 
>> compression and state created for that compression. If we would get
>> away from the mantra that all future addresses of record have to be
>> 128 bit there would be a lot of more flexibility and simplification
>> in the picture for IoT.
>> 
>>> 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.
>> 
>> This is actually a core point: Service providers will only offer 
>> better than "Best Effort" IP services when they can figure out how
>>  to make more money from this. Beside VoLTE, IP Multicast for their
>>  own IPTV service is another example of how this mostly happens: 
>> primarily for application services owned by the SP. The exception 
>> to this rule are transport services such as L2VPN/L3VPN, where the
>>  QoE is not tied to an SP application service itself.
>> 
>>> 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."
>> 
>> Yes. that's one option. I personally find the complexity of trying
>>  to persuade marketing people in service provider into introducing
>>  new QoE services into "network/transport" offerings and then 
>> succeed in wholesaling those - to be mindboggling.
>> 
>>  by the actual customer. In the same way as 4G/5G cores are 
>> nowadays often only a bunch of VMs/containers in edge-DCs, the 
>> actual forwarding plane in metro-router/switches could become 
>> programmable to customers such as "advanced-QoE-slice-operators" 
>> that are also owning/developing the actual solutions/applications 
>> (such as interactive city-wide music).
>> 
>> Certainly, programmable forwarding plane to enable this, would 
>> today by a research, not a standardization yet, but i can not think
>> of a better place to draw expertise from than IETF/IRTF to do
>> this.
>> 
>>> 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."
>> 
>> Cheers Toerless
>>>  Behalf Of Alexandre Petrescu Sent: 14 January 2021 08:45 To: 
>>> Flinck, Hannu (Nokia - FI/Espoo) 
>>> <[email-masked]>; [email-masked] Subject: Re: 
>>> [6gip] 6G in 3GPP?
>>> 
>>>> 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.
>>> 
>>>> 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.
>>> 
>>> 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
>>>> 
>>>> <[email-masked]> Sent: Wednesday, January 13, 
>>>> 2021 10:40 AM To: Flinck, Hannu (Nokia - FI/Espoo) 
>>>> <[email-masked]>; [email-masked] 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?
>>>> 
>>>>> I am involved quite a bit in 3GPP as well as in 6G research 
>>>>> and I am not aware of any of such discussion.
>>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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
>>>> 
>>> 
ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cd.lake%40surr
>>> e 
>>> y.ac.uk%7Ca3cd5fe4075e416ff7ea08d8b8bd18a6%7C6b902693107440aa9e21d894
>>>
>>>
>>>
>>> 
4
>>> 6a2ebb5%7C0%7C0%7C637462469605680996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>>>
>>>
>>>
>>> 
M
>>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
>>>
>>>
>>>
>>> 
s
--
>>> 6gip mailing list [email-masked] 
ietf.org%2Fmailman%2Flistinfo%2F6gip&amp;data=04%7C01%7Cd.lake%40surr
>>> e 
>>> y.ac.uk%7Ca3cd5fe4075e416ff7ea08d8b8bd18a6%7C6b902693107440aa9e21d894
>>>
>>>
>>>
>>> 
4
>>> 6a2ebb5%7C0%7C0%7C637462469605680996%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
>>>
>>>
>>>
>>> 
M
>>> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
>>>
>>>
>>>
>>> 
s
--
>> --- [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 15 Jan 2021 15:11:56 +0100

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

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

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

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

   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.

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

Alex

> Behalf Of Alexandre Petrescu Sent: 14 January 2021 20:10 To: Rex
> Buddenberg <[email-masked]>; [email-masked] Subject: Re: [6gip]
> 6G in 3GPP?
> 
> 
> 
>> False equivalence.  Compounded by using  marketing terms which
>> have sloppy definitions.
>> 
>> 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
> 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.
>

---

From: David Lake <[email-masked]>
Date: Fri, 15 Jan 2021 19:51:15 +0000

Alex

<DL> in-line </DL>

David

-----Original Message-----
From: Alexandre Petrescu <[email-masked]> 
Sent: 15 January 2021 14:12
To: Lake, David (PG/R - Elec Electronic Eng) <[email-masked]>; Rex Buddenberg <[email-masked]>; [email-masked]
Subject: Re: [6gip] 6G in 3GPP?

Le 15/01/2021 à 11:50, David Lake a écrit :
> "network" layer as IETF understands it (i.e. Layer 3) remains static.
> 
> levels of quality conferred by different numerologies which have known 
> propagation properties over-the-air.
> 
> guaranteed bit rate over-the-air and very tight packet-loss, bandwidth 
> and latency parameters.
> 

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

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

> less common but many operators choose not to deploy VoLTE so as not to 
> burden themselves with this).

Yes.

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>

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>

> once you leave the packet core, there is very little onward-mapping of 
> QoS other than the super-aggregated MPLS-TE bundles Toerless 

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 need some kind of central controller monitoring all the possible 
> connections and allocating resources as-needed.

<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

3GPP also uses tunnels.

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

>> switching. LTE is a packet switch technology.
> more allowing smartphones to talk directly to each other without going 
> y.ac.uk%7C4b8e2ee2147d4d17ff7b08d8b95f866a%7C6b902693107440aa9e21d8944
> 6a2ebb5%7C0%7C0%7C637463167213724943%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> data=pcgPe7xjaWUcsk9cHeOHv%2Fv9g2QlImebWd%2FxqmPRSl0%3D&amp;reserved=0
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 15 Jan 2021 15:25:09 -0600

Hi John,

On Thu, Jan 14, 2021 at 11:42 AM John Grant <[email-masked]> wrote:

> releases are (and were always planned to be) further phases of 5G, so 5G is
> not done yet.
>
> It is planned to have three kinds of service: (1) faster mobile broadband
> (2) IoT with huge numbers of very simple and low-powered devices (3)
> "ultra-reliable low latency" supporting applications such as robots in
> factories, automated vehicles, and remote surgery. There are also big
> changes to the architecture of the mobile operators' fixed networks, mostly
> in Release 16. The first "5G" services the mobile operators have rolled out
> are basically just faster mobile broadband using New Radio with a 4G core.
>
>
Yes, some operators are rolling out 5G with only NR.
I think that cloudization is going on very fast.
Maybe they will add the services you mentioned.
 But the point in mail was that operators do not follow strictly to deploy
every new release 3GPP comes up.
Maybe as you say, they try to add services that they think will be
commercially good for them
Overall, 5G is here. It will only get better and more widely available.

Behcet

> +44 1223 862599 and +44 1223 511455http://www.ninetiles.com
>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> Virus-free.
> www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
> <#m_-5588332369584467896_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> --
> 6gip mailing list
> [email-masked]

---

From: John Grant <[email-masked]>
Date: Sat, 16 Jan 2021 12:45:13 +0000

On 15/01/2021 19:51, David Lake wrote:
> <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).
Quite. There's no need for the endsystem to have a contract with every 
entity involved in delivering the service.

End-to-end reservation does scale; on any link divide the maximum 
throughput by the granularity of the reservation and that tells you the 
maximum number of flows there can be. And any node only needs to have a 
conversation with its neighbours, not with everything else in the network.