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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 15 January 2021 14:12 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: 6gip@ietfa.amsl.com
Delivered-To: 6gip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772203A07C8 for <6gip@ietfa.amsl.com>; Fri, 15 Jan 2021 06:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.407
X-Spam-Level:
X-Spam-Status: No, score=0.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.262, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFf7tz6GH99i for <6gip@ietfa.amsl.com>; Fri, 15 Jan 2021 06:11:59 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1573A046B for <6gip@ietf.org>; Fri, 15 Jan 2021 06:11:59 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 10FEBvJB044189; Fri, 15 Jan 2021 15:11:57 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 2ED0621002D; Fri, 15 Jan 2021 15:11:57 +0100 (CET)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 1DC49210019; Fri, 15 Jan 2021 15:11:57 +0100 (CET)
Received: from [10.14.4.183] ([10.14.4.183]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 10FEBuxU010475; Fri, 15 Jan 2021 15:11:56 +0100
To: David Lake <d.lake@surrey.ac.uk>, Rex Buddenberg <buddenbergr@gmail.com>, "6gip@ietf.org" <6gip@ietf.org>
References: <HE1PR07MB3386A43B4B32BF2CE5DC48C79BAA0@HE1PR07MB3386.eurprd07.prod.outlook.com> <248399ab-7dc1-ee13-928c-751568ea58e5@gmail.com> <HE1PR07MB3386A19851BFFF1ED5DDECAE9BA90@HE1PR07MB3386.eurprd07.prod.outlook.com> <CAC8QAccaYy7hKAdz9Y79wMrE0UFBa_=PsERyeGpiMmYpWESLLw@mail.gmail.com> <HE1PR07MB3386B9F18A356F64A0B6DD359BA80@HE1PR07MB3386.eurprd07.prod.outlook.com> <2281d844-ae2c-ecdd-9cf7-e9e130af3739@gmail.com> <1610654118.14219.268.camel@gmail.com> <85a003a1-f833-ad5f-6f1f-a8e26cbc0039@gmail.com> <DB7PR06MB47925677D30E281EAEFC39A9B5A70@DB7PR06MB4792.eurprd06.prod.outlook.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <b52b3d34-f389-b38c-1098-85fe52da83c1@gmail.com>
Date: Fri, 15 Jan 2021 15:11:56 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <DB7PR06MB47925677D30E281EAEFC39A9B5A70@DB7PR06MB4792.eurprd06.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6gip/aJdgaCZkrs9fIpxNzSHZcPy0nNY>
Subject: Re: [6gip] 6G in 3GPP?
X-BeenThere: 6gip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IP Issues in 6th Generation Mobile Network System \(6gip\)" <6gip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6gip>, <mailto:6gip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6gip/>
List-Post: <mailto:6gip@ietf.org>
List-Help: <mailto:6gip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6gip>, <mailto:6gip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Jan 2021 14:12:01 -0000


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

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

They are not subject to tight admission control.

> 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


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