Print

Print
Some questions/ comments

1. I kind of assume that latency requirements are an area of uncertainty in terms of what will turn out to be the largest demands from applications. Unfortunately a content distribution model of how to solve this (less popular held deeper in the network, most popular nearest the edge, flexible rebalancing on what is most popular at a particular locality) doesn't work. Low latency needs to be at least "near enough" to the edge. What would be the best topology to maximise flexibility?
2. Alternatively, as already partially commented on by David, could the edge be at the devices (i.e. somewhere in the home/ building/ car)? It would be worth looking at some kind of 'hub' that is a versatile processing platform for many envisaged apps that comes as a kind of future gateway for advanced new services. And that would affect equipment choices and architecture within the network. It would potentially sit in the home, office (possibly as a distributed function), or even the car. It obviously opens up a new market for manufacturing. It needs to be relatively small and cheap. Roaming brings another set of considerations to this picture. What happens when I am not in my home locality or country? What happens when I am on foot?

John
----Original message----
From : [log in to unmask]
Date : 17/03/2019 - 23:22 (GMT)
To : [log in to unmask], [log in to unmask]
Subject : Re: Architectural developments for 5G?

Mostly from an algorithm-land perspective, we’ve tried to approach the issues raised by John and Ning in a number of papers:

- from a resource allocation angle based on markets, auctions and spot prices in [1],
- trying to emulate past works on caching (static) content to caching active instances of (mobile) functions in [2].

Our rough (and rather expected) conclusion is that it’s relatively easy to find ways to optimise performance (from a resource allocation point of view) based on metrics, but it’s quite challenging to find/set these metrics :) E.g., best-effort won’t work for autonomous vehicles, but prioritising based on market approaches will be exclusive to some applications.

The architectural and security issues that Jon raised are also not easy to tackle. Some thoughts (and more papers) on migrating named functions here: https://www.ee.ucl.ac.uk/~ipsaras/ddec.html 

Any feedback very welcome!

Cheers,
Yiannis.

[1] FogSpot: Spot Pricing for Application Provisioning in Edge/Fog Computing, IEEE Transactions on Services Computing, Jan 2019, https://www.ee.ucl.ac.uk/~ipsaras/files/fogspot-tsc18.pdf 
[2] On Uncoordinated Service Placement in Edge-Clouds, IEEE CloudCom 2017, https://www.ee.ucl.ac.uk/~ipsaras/files/cloudcom17-uncoordinated-service-placement.pdf 

On 16 Mar 2019, at 12:53, JOHN ADAMS <[log in to unmask]> wrote:

I hope you don't mind, Ning, but I have forwarded your comments on my questions to the group.

John
----Original message----
From : [log in to unmask]
Date : 16/03/2019 - 11:41 (GMT)
To : [log in to unmask], [log in to unmask]
Subject : Re: Architectural developments for 5G?

Hi John, David:
  Regarding edge computing, well to put in simple words it is to put boxes (to be more precise - network functions) at the edge in order to achieve localisation. There are various 5G-oriented apps that conceptually require this feature, but certainly things need to be optimised in particular by taking into account delay and response time requirements as well as scalability issues etc.. For instance the more you move MEC to the edge, the shorter delay you can gain but the service coverage of each box (or network function instance) become more limited. In the opposite direction of course you can't push the box too deep into the network as this might affect delay and scalability. Coming to AI running at the edge that's even a wider topic, it can be used either for autonomic network resource management, or for specific OTT 5G applications. In both cases IMO the biggest challenge is how to achieve distributed AI based on edge computing rather than relying on centralised computing infrastructure.
  Coming to David's comments, just to clarify that (1) ITU  2030 and Richard Li's activities are positioned BEYOND 5G era, and (2) the focus is in the area of future Internet rather than the evolution of "x-Gs" so they are not positioned to be something like 6G.
  Regards,
Ning 


From: JOHN ADAMS <[log in to unmask]>
Sent: Saturday, March 16, 2019 10:23 AM
To: [log in to unmask]
Cc: Wang, Ning Prof (ICS)
Subject: Re: Architectural developments for 5G?
 
Thanks David,

It seems to me that, if you take some visionary statements into account (there are many, ranging from automated cars to AI-based IoT for your home), questions/ studies like what I am asking about are needed rather than some of the simplistic statements that are going around that seem to assume the addition of edge processing is merely a case of adding the right number of boxes to your network. The possibnle scale implications are huge.

John
----Original message----
From : [log in to unmask]
Date : 16/03/2019 - 09:54 (GMT)
To : [log in to unmask]
Cc : [log in to unmask]
Subject : Re: Architectural developments for 5G?

Hello John,

Have you spoken to Andy Sutton about this? I recall he told me about 5G requirements on the architecture that he and Richard Li worked on. Also, the new-ish Network 2030 initiative started within ITU may be looking at these questions, even though it’s not explicitly on 5G.

I’m copying Ning to see if he can add to this, or contradict me ...

Best rgds,
David

On 15 Mar 2019, at 17:26, JOHN ADAMS <[log in to unmask]> wrote:

Dear all,

Just a thought for today. An interesting talk last year at Coseners on the realities of 5G.
Is the research community looking at local processing needs (or, rather, future needs) for applications that develop on the back of 5G? By 'local' I mean within the decision time frame required by the application and hosted somewhere on the network and replicated probably at or near the edge. The questions I have in mind are practical realisations that scale. There are several views on what that level of scale might evolve towards and what latency requirements of applications might drive the preferred solution and I don't wish to comment on every scenario. There are some open questions (I would guess) on an architecture for best scaling.

Regards,

John

To unsubscribe from the NGN list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1





To unsubscribe from the NGN list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1




To unsubscribe from the NGN list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=NGN&A=1