Re: [5gangip] Soliciting Ideas in Direction in 6G - remote surgery use-case

Luca Muscariello <muscariello@ieee.org> Fri, 17 July 2020 13:41 UTC

Return-Path: <muscariello@ieee.org>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 060243A0932 for <5gangip@ietfa.amsl.com>; Fri, 17 Jul 2020 06:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ieee.org
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 Gg1IgAO0_as8 for <5gangip@ietfa.amsl.com>; Fri, 17 Jul 2020 06:41:31 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EB743A0930 for <5gangip@ietf.org>; Fri, 17 Jul 2020 06:41:30 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id b6so11129110wrs.11 for <5gangip@ietf.org>; Fri, 17 Jul 2020 06:41:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JLY0Dde4RrjGgBdg/F/GzEWtiejtUxMNvJP08Ryee7o=; b=JLe3v3keKMioC7Hgmi28ZT4CZGzQyARmsGhpVMotu4aJFvdqpLrDeQ+6toITFDc6NH qSiHUnVB0h/6IEGvNwUqbQXX/vpmVtgN/eLHfUqkH150QmkKx6fdXfAVZhR1HTBrbmUX lVtg/q1Xjm7cmhindctwxae0MuLSws3a7Hm0s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JLY0Dde4RrjGgBdg/F/GzEWtiejtUxMNvJP08Ryee7o=; b=RfYayotLcsrS5UMYABvJiw8BGIWxSPTsWYtW0UWHhIv9oYvKpjPHcmR/JeipRIZ3TY dXdWYqedyun7kKi6zRQCNhyh7mvdbk+BXLtF2EFFlCcWum5wQAMzJuNjWgzz44wNuVEy LEJYvJX7fkM41q9W6fEE534BVckoILfKQFZMu1wIZqulY/N78BeQrfcfMHOtRZU3iANH D4kixQE2ir+7nJPw1FXO8oDJdPEF01jt9o2nhC2+lR5VbWDbof7+MLMn8o6wVxon5bYH qyahdbQac/XxX0bR1AR865b0SvEDXY/JBfMPDIq7YTytDqAJrLHgi9MU4mVe1X75NFmY uelA==
X-Gm-Message-State: AOAM533UEHD47vD2jbFlTITXHe3jvxwRE01TZipYTlTLHrvJw1I8U74o T9kMjR+hWet9yNODXV+5jbzgBnbEgzdFeqZhl99fHg==
X-Google-Smtp-Source: ABdhPJyaP+9OG5FKUPI2pez9I+z90iVw3Aq5N+r69S/K8rLlEgddBtHFUhD5wxFCmDBsAPn/KFqVkgv4NV89xAMcPrA=
X-Received: by 2002:a5d:43d0:: with SMTP id v16mr10935822wrr.296.1594993289239; Fri, 17 Jul 2020 06:41:29 -0700 (PDT)
MIME-Version: 1.0
References: <CAC8QAcd8FbzngiNDpU+S2mOvqHkzmPeMvE7_1OcRXuaJRG6fZQ@mail.gmail.com> <CAC8QAccV8C6UHsdk7fZmL4fyP47nRmd5jCf3KqFtff1eY3f3uw@mail.gmail.com> <d5fc9c55-492d-496d-5651-74c17edf6b35@gmail.com> <d6608f55-da3a-1e60-c18f-83c6c3476841@gmail.com> <4BCAD542-947A-4AEA-A2D4-3D82BB7C253D@cisco.com>
In-Reply-To: <4BCAD542-947A-4AEA-A2D4-3D82BB7C253D@cisco.com>
From: Luca Muscariello <muscariello@ieee.org>
Date: Fri, 17 Jul 2020 15:41:17 +0200
Message-ID: <CAH8sseTdYx2q6zBqavEeYQEaWAan5isDqyWsV=k-DB1a0z037Q@mail.gmail.com>
To: "Aeneas Dodd-Noble (noblea)" <noblea=40cisco.com@dmarc.ietf.org>
Cc: Alexandre Petrescu <alexandre.petrescu@gmail.com>, "5gangip@ietf.org" <5gangip@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006cc83205aaa3503f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/fkSxJf7QekUeiEOsy5b4H18VzEQ>
Subject: Re: [5gangip] Soliciting Ideas in Direction in 6G - remote surgery use-case
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jul 2020 13:41:34 -0000

On this topic, it is worth having a look at the LoLa project
https://lola.conts.it that provides software as well as hardware
requirements to
perform music interactions from remote. It addresses the application
latency for this use case and it has been used essentially
over Internet2, Geant and Garr networks serving college/conservatory of
music, music halls.

https://www.youtube.com/watch?v=c0eagE2Gzgg
great video

Luca

On Fri, Jul 17, 2020 at 3:16 PM Aeneas Dodd-Noble (noblea) <noblea=
40cisco.com@dmarc.ietf.org> wrote:

> At MWC 2019, there was a demo of remote band playing with singer in one
> location and guitar in another.  The singer was connected over 5G and the
> latency was definitely low, but the largest contribution to the latency was
> the signal processing of the voice and rendering – 20ms.
>
>
>
> Remote surgery would have the same problem and the speed of light is
> finite so any physical/routing distance from doctor to patient would also
> be an issue.   6G Radio is not going to solve this.
>
>
>
> Better application performance and true MEC will be needed.  5G and 6G
> cannot address the application latency but we can look at better network
> topologies to make applications really take advantage of proximity.
>
>
>
> *From: *5gangip <5gangip-bounces@ietf.org> on behalf of Alexandre
> Petrescu <alexandre.petrescu@gmail.com>
> *Date: *Friday, July 17, 2020 at 5:42 AM
> *To: *"5gangip@ietf.org" <5gangip@ietf.org>
> *Subject: *Re: [5gangip] Soliciting Ideas in Direction in 6G - remote
> surgery use-case
>
>
>
> This morning in the news again (last time it was Mobile World Congress
>
> of 2019) there is talk about remote surgery use case, with a
>
> demonstration in Italy.  The presenters claim the use of 5G.
>
>
>
> However, it seems the use of 5G is related to streaming a video of
>
> what's happening, and really not the surgeon's gesture per se.
>
>
>
> There is talk of 200ms latency, which is ridiculuously high, reminding
>
> more of 3G rather than 4G or 5G claims of 1ms.
>
>
>
> It seems the realized surgery operation is still on fiber and Ethernet.
>
>
>
> So, to be clear, the current state-of-the-art of 5G for remote surgery
>
> operations is really more of a false claim, apparently made by promoters
>
> of 5G rather by the technology inclined.
>
>
>
> This makes wonder whether the remote surgery use-case is relevant for 6G?
>
>
>
> Would one allow her or his body to be subject to an intrusion based on
>
> technology like cellular technology, or like IP, which has no guarantee
>
> of packet delivery?
>
>
>
> Or is it more like a father on video, remotely assisting to a birth
>
> event via his smartphone on 6G?  We have seen such a gluing well during
>
> the initial COVID crises, but it was skype on WiFi.  Not sure 6G would
>
> have anything to bring in here.
>
>
>
> Alex
>
>
>
> Le 15/07/2020 à 14:52, Alexandre Petrescu a écrit :
>
>
>
>
>
> Le 13/07/2020 à 18:27, Behcet Sarikaya a écrit :
>
>
>
>
>
> On Fri, Jul 3, 2020 at 10:14 AM Behcet Sarikaya
>
> <sarikaya2012@gmail..com <mailto:sarikaya2012@gmail.com>
> <sarikaya2012@gmail.com%3e>> wrote:
>
>
>
> Hi all, Please check this out:
>
>
>
> http://jultika.oulu.fi/files/isbn9789526226842.pdf
>
>
>
>
>
> Regards,
>
>
>
> Behcet
>
>
>
>
>
>
>
> Hi all, thanks for good comments on the above white paper. Now we
>
> need to identify some directions, possible one for us that most of
>
> the people in the list would be happy about.
>
>
>
> Some inspiration could be obtained from the ongoing discussions
>
> about Horizon Europe programme.
>
>
>
> Here are my comments relayed to IETF about what could become a call
>
> for proposals in Cluster 4.
>
>
>
> 6G and foundational connectivity technologies
>
>
>
> Expected impacts addressed: #19 (Green), #20 (Data), #21
>
> (Industrial leadership and autonomy), #22 (Digital and emerging
>
> enabling technology sovereignty)
>
>
>
> Objective: develop a strong supply chain for connectivity,
>
> increase European competitiveness and sovereignty in core Internet
>
> infrastructures, and to contribute to a reduction of the growing
>
> effect of the Internet on the global energy consumption with the
>
> aim of achieving a climate neutral Internet.
>
>
>
> Current status: today European suppliers of connectivity systems
>
> are well placed with around 40% of global 5G market share, but with
>
> high competitive pressure from Asian and US players. In terms of
>
> technology, first 5G standards are available since end of 2017
>
> enabling Gigabit/s speeds and ~millisecond latencies. Trusted
>
> industrial services based on 5G technology are at very early
>
> stage.
>
>
>
> Achievements sought / targets:
>
>
>
>
>
> •    Reinforce European leadership in connectivity, devices and
>
> service infrastructure, with European capabilities in shaping
>
> future connectivity (6G) standards, keeping a strong position in
>
> the network supply market and seizing opportunities ofintegration
>
> with new value chains such as cloud and edge computing as well as
>
> components and devices beyond smartphones. The target is EU
>
> industry holding at least 40% of the global market of future
>
> connectivity (6G) systems •    Enable a massive digital and green
>
> transitions towards low carbon footprint of conventional (vertical)
>
> industries such as automated factories, connected cars, energy
>
> grids, agriculture, smart healthcare by managing the exponential
>
> increase of connected devices and objects (speed, latency, energy,
>
> intelligence). The target is to contribute to vertical sectors
>
> keeping a carbon emission levels of 2015 (Global e-Sustainability
>
> Initiative (GeSI) objectives). •    Enable networks to deliver
>
> advanced real-time sub-millisecond latency applications that are
>
> competitive, secure and
>
>
>
> Sub-millisecond would be about above-Gbit/s bandwidths.
>
>
>
> To that, I would add that volume is important as well.  Many sources
>
> of 6G ambitions talk in terms of volume of data transmitted.  That
>
> volume is probably more important than mere bandwidth.
>
>
>
> privacy-preserving, in areas such as autonomous driving,
>
> manufacturing and farming.
>
>
>
> There should be carefulness about this.
>
>
>
> In the same line of thought I also saw mentioned 'remote surgery' for
>
>   future 5G and for 6G.
>
>
>
> But remote surgery was already mentioned many years ago.  I remember
>
>   VDSL was one such context.  I have also seen and played with some
>
> dentist surgeon's devices that could be used for training, and could
>
>   communicate on the Internet.
>
>
>
> However, it does not materialize.  Remote surgery is not something to
>
>   put into someone's smartphone.  Or maybe we dont really understant
>
> surgery.
>
>
>
> The same applies to manufacturing, farming and to a certain context
>
> to autonomous driving.
>
>
>
> For example, 5G is claimed to offer so perfect network communication
>
>   that one tele-operate a self driving car on 5G.  But the initial
>
> trials of tele-operation encounter so many other problems than the
>
> network communication system that it might be that 5G is outdated
>
> when all these other problems are solved.
>
>
>
> Manufacturing: it is typically factory floors.  It's very east to
>
> bring reliable Ethernet and fiber there.  Why would one put a glitchy
>
>   smartphone-specific 6G in there?  Do we really understand what
>
> manufacturing and Industry 4.0 needs?  (Industry 6.0 maybe).
>
>
>
> The target is > 10 million connected objects/km² for Smart City
>
> scenarios •    Enable trusted and energy-efficient network
>
> infrastructures
>
>
>
> Yes, I fully agree with the energy-efficiency aspect.
>
>
>
> This is a matter of responsibility and Ethics.
>
>
>
> I heard people complaining about jet planes polluting the Earth and
>
> then the manufacturers of said jets complained about energy-hunger
>
> underground data centers that would not exist if there were no
>
> smartphones.  All these complaints are valid.
>
>
>
> delivering critical services as well as a dynamic multi-vendor
>
> supply market through new radio technologies, new architectures and
>
> open network and service paradigms such as Terahertz
>
> communications, versatile spectrum technologies, zero touch network
>
> automation, AI,
>
>
>
> In the zerotouch network automation there is also this Let's Encrypt
>
> and ACME which constitute a significant step towards better security
>
> in the Internet.
>
>
>
> blockchain and EMF aware networks. An average decrease of network
>
>
>
> I suspect EMF aware networks (EMF: Electro-Magnetic Field) would
>
> reply to citizien's health worries about 5G, which is good.
>
>
>
> consumption by a factor of 10 is targeted, as well as new classes
>
> of applications beyond 5G capabilities and an Internet of Sense.
>
>
>
> Internet of Sense?  It is new.
>
>
>
> I suggest the following target too: - 4G and 5G networks achieve a
>
> form of use of IPv6, but there is still no full native IPv6 deployed
>
> in 5G networks.  GRE still runs on IPv4 and 5G smartphones still need
>
> translation functions in order to run IPv6. In 6G, there should be a
>
> requirement of full native IPv6 usage.
>
>
>
> Means/links: An institutionalised partnership (‘Smart Networks and
>
> Services’) is currently proposed to enable European industrial and
>
> academic stakeholders to design and implement common roadmaps in
>
> significantly research-intensive areas. Foundational technologies,
>
> long term, very high risk and disruptive concepts on radio and
>
> full optical networks as well as new IoT real-time concepts are
>
> addressed outside of the proposed Smart Networks and Services
>
> partnership.
>
>
>
> Yes, this partnership is advancing.
>
>
>
> But there is need of more collaboration worldwide.
>
>
>
> Alex
>
>
>
> The direction should be different than  NMRG (network management
>
> research group) which discusses AI and machine learning aspects,
>
> and COINRG (computation in the network)
>
>
>
> Also consider that improvements to IPv6 is an IETF subject and
>
> radio link technologies are out of scope.
>
>
>
> But still some directions in network virtualization and/or slicing
>
> could be OK.
>
>
>
> In short, we need to be a bit specific on what we want to do.
>
>
>
> Regards, Behcet
>
>
>
> _______________________________________________ 5gangip mailing
>
> list 5gangip@ietf.org
>
> https://www.ietf.org/mailman/listinfo/5gangip
>
>
>
>
>
> _______________________________________________ 5gangip mailing list
>
> 5gangip@ietf.org https://www.ietf.org/mailman/listinfo/5gangip
>
>
>
> _______________________________________________
>
> 5gangip mailing list
>
> 5gangip@ietf.org
>
> https://www.ietf.org/mailman/listinfo/5gangip
>
>
> _______________________________________________
> 5gangip mailing list
> 5gangip@ietf.org
> https://www.ietf.org/mailman/listinfo/5gangip
>